When choosing a PMS, do not end the room-move demonstration after dragging a booking across a calendar. Ask to see the former room’s final status, the destination room’s suitability, the remaining nights and any change to the amount charged. A useful buying tool is an acceptance checklist: run the same fictional record through four situations and compare the expected outcome with what was actually demonstrated.
Define the test boundary
This test concerns a checked-in guest moving between rooms within one property. Extensions, transfers between properties and new bookings require separate tests. Oracle’s public room-move and available-room-search documents provide product-specific context. They do not establish how another PMS behaves or which buttons it offers. Ask each candidate supplier to show its own current scope. Request a demonstration environment that does not contact real guests or sales channels. Fictional record A arrives on 17 October and leaves on 20 October. Assume a move on 18 October: the nights of 18 and 19 October remain. These dates are example assumptions. Record the original room, destination, room category and existing total together so that the effect of each change remains clear.
First situation: a ready room in the same category
Set the destination to the same category, available for both remaining nights and ready under your property’s definition. After the move, inspect the reservation and both rooms. Have the dates or total changed? What is the former room’s final status? Can housekeeping identify any new work? Is the destination linked to the correct record for the remaining stay? Write your expected result before the demonstration. For example: dates and price stay unchanged, and both room states are clear. This is a proposed acceptance criterion, not a universal software feature. Keep a supplier’s verbal explanation separate from an observed result. Repeat the test with the same starting conditions when comparing candidates.
Second situation: an unsuitable destination
Create a fictional restriction on the destination. Specify whether it awaits cleaning or is unavailable for maintenance; these are different conditions. Ask what happens when the user selects it: a warning, a blocked action or a different outcome with particular permission? Record the demonstrated behaviour rather than assuming a safeguard exists. After an unsuccessful attempt, check that the valid assignment remains understandable and that no incorrect occupancy appears on the target room. Dismissing a warning is not proof that the move finished. If staff cannot establish the result, leave that scenario open in the buying record. A successful move into a clean room cannot substitute for this exception test.
Third situation: a different category without a price change
Use a higher room category for a fictional complimentary upgrade. Ask the supplier to distinguish the physical room category from the basis of the charge. Compare totals before and after, including any approval and explanation shown to the user. Do not presume that changing category automatically changes the amount or necessarily preserves it. A deliberate price change can then be tested separately. Keep it out of the complimentary-upgrade result: one test expects the current amount to remain; the other expects an explicitly approved new amount. The focus is the visible reservation outcome. This guide makes no claim about payment processing or a particular product’s commercial capabilities.
Fourth situation: history and follow-up work
After completion, ask to see the visible history. Can another employee identify the former and destination rooms, understand when the move completed and find the owner of outstanding work? These are evaluation questions, not requirements for a particular technical architecture. Run a separate correction for a wrongly selected destination. Restate its starting conditions and check whether the second change hides essential context from the first. If integrations or physical keys are outside the demonstration, retain them as open follow-up questions with a responsible team; do not mark them completed.
An acceptance checklist for the decision
Mark each line “demonstrated”, “partly demonstrated” or “not demonstrated” and add the observed result. Another attractive screen cannot close a critical gap. Use the [housekeeping demo guide](/en/blog/pms-kat-hizmetleri-oda-durumu-ariza-demo) for room states and the [outage and recovery demo](/en/blog/pms-kesinti-geri-donus-demo-is-surekliligi) for uncertain transaction outcomes. The [Oracle room-move](https://docs.oracle.com/en/industries/hospitality/opera-cloud/25.1/ocsuh/t_arrivals_in-house_moving_an_in_house_reservation.htm) and [available-room-search](https://docs.oracle.com/en/industries/hospitality/opera-cloud/25.1/ocsuh/t_front_desk_available_room_search.htm) documents were opened on 17 October 2026. Confirm the candidate product’s current scope before deciding.
- Ready destination, same category: were dates, total and both final room states shown together?
- Unsuitable destination: is the result clear, with the valid assignment still understandable?
- Complimentary category change: were the physical move and price outcome verified separately?
- History and correction: can staff find the context, outstanding work and follow-up owner?