Hotel PMS Migration Checklist
Switching property management systems is mostly a sequencing problem. Do it in the wrong order and you lose future bookings, break your OTA connections, or go live with a guest ledger that does not balance. Here is the order that works.
Before You Start: Three Decisions
A PMS migration succeeds or fails on three decisions made before any data moves: when you cut over, how much history you carry across, and what happens to bookings that straddle the switch. Get those right and the rest is administration. Get them wrong and you will be reconciling by hand for weeks.
1. Pick the cutover date deliberately
Choose your lowest-occupancy window, and avoid month end. Cutting over mid-month lets the old system close a clean accounting period behind you, and low occupancy means fewer in-house guests straddling two systems. Avoid the week before a major event or peak season entirely — the migration will take attention away from the front desk exactly when you cannot spare it.
2. Decide how much history to carry
You rarely need every historical booking in the new system. What you genuinely need is future reservations, current guest profiles, and enough financial history to satisfy your accountant and any statutory retention rules in your market. Older detail can stay as an export, archived somewhere safe and readable. Trying to migrate five years of folio history is the most common reason a switch drags on for months.
3. Plan for bookings that straddle the cutover
Guests who check in before the switch and out after it are the awkward case. The usual approach is to keep them in the old system until they check out, running a small manual overlap, rather than splitting a folio across two systems. Count how many of these you will have before choosing the date — sometimes shifting the cutover by a few days reduces it to almost none.
The Export Checklist
Do this while you still have access. The single most expensive migration mistake is cancelling the old subscription first.
Your leverage disappears the moment the old contract ends. Some vendors restrict export functionality on cancelled accounts, and some charge for a data extract once you are no longer a customer. Export everything you might conceivably want before you give notice.
That last row is the one people forget. Channel mappings usually cannot be exported at all, and rebuilding them from memory is how room types end up mapped to the wrong OTA listing — which sells the wrong room at the wrong price, quietly, until a guest arrives.
The Migration Sequence
Order matters. Each step assumes the one before it is finished and verified.
- Build the static configuration first: rooms, room types, rate plans, taxes, policies, fees. Nothing else can be correct until this is. Verify a test booking prices exactly as it would have in the old system.
- Load guest profiles, so that future reservations attach to the right guests rather than creating duplicates.
- Migrate future reservations, then reconcile the count and the total value against the old system. Do not proceed until the numbers agree — a discrepancy here becomes a guest with no room.
- Rebuild and verify OTA channel mappings, room type by room type, before opening any inventory. Push a test availability update and confirm it appears correctly on each channel.
- Open inventory on the new system and close it on the old one, in that order, in a single short window. Both open means double bookings; both closed means lost sales.
- Run a parallel period. Keep the old system readable — not writable — for a few weeks so you can check anything that looks wrong rather than guessing.
- Close the old account only after your first clean month end in the new system.
Go-Live Day and the First Week
What to verify before you trust the new system.
- Today’s arrivals list matches what the old system showed. Check the count and spot-check five bookings end to end, including rate and deposit.
- Availability is correct on every channel. Look at your own listings as a guest would, on each OTA, not just inside the channel manager.
- The guest ledger balances. In-house folios should total what the old system said they did.
- A test booking flows through end to end: made on an OTA, appearing in the PMS, closing the dates on the other channels.
- Someone senior is on site and not rostered to a normal shift. Migration day needs a person whose whole job is answering questions.
In the first week, expect rate and restriction issues rather than catastrophic failures. The common pattern is a rate plan that was subtly different in the old system — a weekend supplement, a minimum stay, a tax inclusion — surfacing when a guest books at a price you did not expect. Check your first dozen bookings line by line and the rest of the year takes care of itself.
If your new vendor offers migration support, use it and ask specifically who does what. The useful question is not "do you help with migration" but "who rebuilds the channel mappings, and who verifies the future bookings reconcile."
Frequently Asked Questions
How long does a hotel PMS migration take?
For an independent property with straightforward configuration, two to three weeks from first export to a verified go-live is realistic: a few days of setup, a few days for data and channel mapping, then a parallel period. Migrations stretch to months mainly when operators try to carry across years of historical folio data that could have stayed as an archived export.
What data should I export before switching PMS?
Future reservations, guest profiles with consent flags, rate plans and restrictions, invoices and folio history covering your statutory retention period, and your tax configuration. Also screenshot every OTA channel mapping — those usually cannot be exported and rebuilding them from memory is how room types get mapped to the wrong listing.
When is the best time to switch hotel PMS?
Your lowest-occupancy window, mid-month rather than at month end. Low occupancy means fewer guests straddling both systems, and a mid-month cutover lets the old system close a clean accounting period. Avoid the run-up to peak season or a major local event, since migration takes attention away from the front desk precisely when you need it there.
What happens to bookings that straddle the cutover date?
The usual approach is to leave guests who check in before the switch in the old system until they check out, running a short manual overlap rather than splitting a folio across two systems. Count how many of these you will have before fixing the date — moving the cutover by a few days often reduces it to almost none.
Will I lose my OTA connections when I switch PMS?
Connections have to be rebuilt against the new system, which means remapping each room type to each channel listing and reconnecting the channel manager. Do this and verify it with a test availability push before opening inventory. The risk is not losing the connection but mismapping it, which sells the wrong room at the wrong rate without any visible error.
Should I run both systems at the same time?
Yes, but asymmetrically. Keep the old system readable rather than writable for a few weeks after cutover so you can check anything that looks wrong. What you must avoid is having inventory open on both systems simultaneously, which causes double bookings — close the old one and open the new one in a single short window.
Migrate With Someone Who Has Done It Before
Frontdesko onboards independent hotels every week — future bookings reconciled, channels remapped and verified, and the PMS free forever once you are live.
Related Guides
Before, during and after the switch