Switching PMS: keep bookings and operations under control

Define what has to survive the move

Write a migration inventory that covers upcoming and in-progress stays, property identifiers, blocks, rates, restrictions, message rules, team permissions, and records you need to retain. Ask both providers which items can be exported or imported and which need manual work.

Do not cancel access to the old system before understanding those requirements. A spreadsheet of reservation dates may be useful for reconciliation, but it does not by itself establish that payment arrangements, guest conversations, documents, or scheduled tasks will be carried over.

• List every active connection and the system currently responsible for it.
• Identify future stays, ongoing stays, and unresolved reservation changes.
• Capture the settings and templates you need to recreate.
• Confirm export options, retention needs, and the old account’s end date.

Agree on the cutover sequence

Airbnb documents a provider change as disconnecting listings, removing the previous provider’s account access, and connecting the replacement. It advises prompt reconnection, or temporarily unlisting or snoozing when the new connection is not ready. Prepare before beginning that sequence.

Ask the new provider to confirm how its instructions fit your current connection. Name the person making changes and another person checking results. Choose a window in which the people needed for support are actually available; the calendar should reflect your operating constraints rather than an arbitrary deadline.

Documentation: Airbnb: How do I switch to a new software?

Reconcile the old stays and the new connection

Compare the future-reservation inventory against the replacement system, property by property. For each stay, verify dates, property, status, and where changes will be made. Ask how bookings created before the new integration should be handled, rather than assuming they behave like newly created bookings.

Keep an exception list with a named owner. A stay that appears in two systems is not necessarily duplicated, and a stay that appears once is not necessarily complete. The goal is to understand which record controls each action and whether your operating team can follow that rule.

Prevent overlapping operations

Review scheduled messages, cleaning notifications, pricing tools, and access workflows on both sides of the handover. Do not leave two systems independently sending the same operational instruction. Disable or retain each old workflow deliberately and note the moment responsibility changes.

Keep team members informed about where to work during the transition. If a guest changes a stay while you are reconciling it, record that change in your exception log and verify it in the intended destination. A cutover checklist should account for activity happening while the move is underway.

Define the fallback before you need it

Decide what would make you pause the move: unexplained availability, unmatched future stays, inaccessible records, or uncertainty about guest instructions. Agree with the providers on a supported recovery path instead of assuming reconnecting the old account will restore every prior state.

Only retire the old setup when the essential checks are complete and retained records are accessible. Keep the migration notes available for the team’s next unusual reservation. They should explain what changed, which exceptions remain, and whom to contact—not simply record that someone clicked “connected.”