PMS cutover plan: a checklist for the night you switch systems

A PMS cutover plan is the written sequence that moves a hotel from one property management system to another across a single business-day boundary: freeze changes, close and save the old system's last night audit, load and sign off data, re-point interfaces, carry in-house guests and open folios, and agree a rollback point before the first morning.

The last night audit closes in the old system at 03:10. At 03:25 a guest arrives with a confirmation for a room that exists in neither system, because the booking arrived while the channel manager was between the two. The cutover plan is what decides whether that takes four minutes or four hours. After reading this, you will be able to write that plan as one page: date, freeze, reconciliation, interface tests, carry-over list and rollback point.

What is a PMS cutover plan, and how is it different from migration?#

A cutover plan is the timetable and the checks for the night the hotel stops using one property management system (PMS, the system that holds reservations, rooms, bills and guest records) and starts using another. Migration moves the data; cutover moves the hotel.

Cutover is a business-day boundary, not a software installation. The old system must close its last night audit, the new one must open its first, and no business day may go unclosed in either. The plan is written, dated and owned by one named person, with a named deputy who can make decisions at 03:00 without a phone call.

It has three phases: preparation over the preceding weeks, the night itself, and the first morning plus the week after, where most of the real problems appear. It is not a test of the vendor's software. It is a test of the hotel's own decisions about what counts as correct, and those decisions must be written before the night. The working rule: anything you cannot check, you cannot sign off. If the plan has no way to verify a step, the step is not in the plan.

If you are still choosing the system, the questions to ask a hotel PMS vendor before you sign (post:a016) are the cheapest place to prevent cutover pain.

How do you choose the cutover date?#

Choose a date when the hotel has the fewest moving parts and the most staff attention available, then freeze every change that could alter what the data means.

Prefer a low-demand, mid-week window. Avoid public holidays, the first days of a new rate season, and month-end or quarter-end when the accounts team is closing. Check the date against your accountant's calendar as well as the hotel's: open items and balances must be reconcilable on both sides of the boundary.

Set a change freeze with a written start and end: no new rate codes, no room-type renames, no package changes, no profile merges, no channel mapping edits between the freeze and the sign-off. Each change after the final load makes the reconciliation wrong, and you will not know which side is wrong. Send the freeze dates to reservations, sales, revenue, housekeeping and the accountant, not only to the project team.

Confirm the date with the channel manager, the door-lock supplier, the till supplier and the e-document integrator, not just the PMS vendor. Each has its own lead time and its own test. Keep a buffer day after the switch, so the first full business day in the new system is not also a full-house day. Plan by milestones, not by hours: how long the night takes depends on property size, the number of interfaces and the state of the old data, so treat any promised hour count as an estimate, never as a commitment.

What must be closed and saved in the old system before the last night audit?#

Close the old system cleanly and export the reports you will need months later to prove what the position was on the last night.

Run the last night audit in the old system and let it complete. A night audit stopped halfway leaves the business day open and the balances unclear in both systems. Export in formats you can open without the old system: PDF for reading, spreadsheet for checking. A report that only opens inside a system you are leaving is not an export. Store the copies outside the old vendor's environment, with a named owner, a storage location and a retention date written next to them.

Retention is not optional. Article 240 of the Tax Procedure Law (Law No. 213) requires lodging places to prepare daily customer lists with consecutive serial and sequence numbers, following their room and bed plans and showing each guest's name and surname with the room number and room rate, and taxpayers who keep books retain books and documents for five years, counted from the start of the calendar year after the year they relate to (mevzuat.gov.tr, 2026-07-01 (opens in a new tab)). The Commercial Code (Law No. 6102, Article 82) sets ten years for commercial books, inventories, financial statements and the documents behind the entries, and allows most of them to be kept as images or on data carriers provided they match the originals and can be made readable during the retention period (mevzuat.gov.tr, 2026-09-23 (opens in a new tab)). Record who exported what, when, and where it is stored; on the night, that log is the only thing that tells you whether the export actually finished.

For the audit itself, the order of steps matters as much as the exports; see the night audit checklist: closing the hotel business day in order.

How do you sign off the final data load?#

Sign off by comparing counts and money between the old system's last state and the new system's first state, until the only differences left are the ones you have written down and accepted.

Agree the reconciliation list before the load, not after: number of future reservations, room-nights, guest profiles, companies and agencies, rate codes, and the total of all open folio balances. Compare totals first, then check a sample by hand. Pick ten future reservations and ten open folios and compare them field by field: dates, rate, room type, balance, cancellation policy.

Money is the strictest test. The total open balance in the old system must equal the total carried into the new one, or the difference must be explained on paper and signed. Keep an exception log: every reservation, folio or profile that did not load cleanly, with the reason, who fixed it and when. An empty exception log is a claim; a filled one is evidence.

Two signatures: one from the hotel (front office manager or general manager) and one from the vendor's implementation lead. Neither signs alone, and neither signs a blank sheet. The sign-off freezes the data. After it, no further load from the old system without a new reconciliation, or the two systems will disagree and nobody will know which one is right. For what to move in the first place, see PMS data migration: what to move, check and leave behind.

Which interfaces must be re-pointed and tested before the first booking?#

Every system that reads from or writes to the PMS must be moved to the new one and tested with a real transaction before the hotel depends on it.

The channel manager comes first: re-point it, push availability and rates, then pull a test booking through and confirm it lands in the new PMS with the right room type, rate and cancellation policy. A connection that is re-pointed but untested is a guess. Test with a real booking that you then cancel, where the channel allows it; a simulated message proves the connection exists, a real one proves it works.

The door-lock encoder needs a test key for a test room, including the departure time and the room-move behaviour, because a key that stops working at the wrong hour is a guest complaint at the worst moment. Outlet tills in the restaurant, bar and spa must post charges to the right folio with the right tax treatment; check one charge end to end. Confirm that the payment terminal's pre-authorization, capture and refund still behave as the front desk expects, and that the e-document integrator accepts the new system's invoice data. Ask the integrator in writing what happens to documents in flight during the switch.

The gap is the danger: bookings can arrive while the channel manager sits between two systems. Capture them from the extranet after the switch, check each one against the new PMS, and keep the list until every one is confirmed. For how these systems relate to each other, see the hotel technology stack: how the core systems fit together.

How do you carry in-house guests, open folios, KBS and e-documents across the switch?#

Carry them by hand, one at a time, and agree in writing with your integrator and your adviser how identity notifications and fiscal documents continue across the boundary.

In-house guests and open folios#

Walk the in-house list room by room against housekeeping status, and confirm each guest's departure date, rate and balance in the new system before the first morning. Re-issue keys for every occupied room and note which old keys no longer work, so the front desk is not discovering it at midnight.

Move open folios with both the balance and the charge history. A folio that arrives with a balance but no charges is a dispute waiting to happen at check-out. Brief the front desk on what to say if a guest asks why the bill looks different, and keep the old system's folio printouts reachable for the first week.

Identity notifications and fiscal documents#

Identity notifications are a legal duty, not a software preference. Law No. 1774 (Kimlik Bildirme Kanunu) requires the responsible operators of hotels, motels, pensions, holiday villages and similar lodging places to keep identity and arrival-departure records of every guest, Turkish or foreign, day by day, on computer, and to report them instantly to the general law enforcement by connecting to its computer terminals; the law also sets administrative fines for failures (mevzuat.gov.tr, consolidated text, 2025-12-05 (opens in a new tab)). Confirm amounts and your own case with an adviser.

On the fiscal side, e-Fatura and e-Arşiv are electronic invoices, and a licensed integrator issues them. Taxpayers whose own systems are not sufficient can send and receive e-invoices through a special integrator authorised by the Revenue Administration. Fiscal documents must be issued according to current GİB regulations, so confirm dates, penalties and your own case with an accountant or legal adviser. Ask your integrator in writing what happens to documents in flight during the switch, and keep the answer.

If the plan cannot guarantee that no business day passes without an identity record and without a fiscal document, move the date. That is the one condition that outranks the calendar.

Who is on shift, what is the rollback point, and what do you check the first morning?#

Name a trained super-user on every shift, write down the exact state you would return to if the switch fails, and check the same short list every morning for the first week.

Super-users: at least one trained person per shift, including the night shift, with the vendor's escalation contact and the authority to pause the process and call the owner. The rollback point is a written statement, not a feeling: the last consistent state (for example, the old system's closed business day plus the exported reports), what would be lost by returning to it, and who has the authority to call it.

Decide in advance what counts as failure, in numbers: how many unmatched bookings, how large an unexplained balance difference, how many hours without a working channel connection. Rollback is not free. Bookings taken in the new system after the point would have to be re-entered, and a message already sent to a guest cannot be recalled.

Keep a daily log for the first week: what broke, who fixed it, what changed. Hold a short review at the end of day one and day seven, and close the change freeze only when the review says so.

What to do next#

Write the plan as one page before you book anything: the date, the change freeze window, the reconciliation list, the interface tests, the carry-over list for in-house guests and open folios, the rollback point and the name of the person who can call it. Then get the PMS vendor, the channel manager and your accountant to read the same page. The pieces fit together in one order: the date and the freeze protect the meaning of the data, the last night audit and the load sign-off prove the position, the interfaces and the carry-over keep each guest whole, and the rollback point is what makes the whole night safe to attempt.