PMS data migration: what to move, check and leave behind

PMS data migration is the planned transfer of a hotel's live records, future reservations, deposits, open accounts, allotments, group blocks and rate plans from an old system into a new one, plus the decision about what stays read-only for audit and what is deleted. Rehearse it, reconcile counts and balances, then switch.

Two weeks before go-live, someone asks whether the deposits in the new system match the deposits in the bank. Nobody in the room has the number. Asked early enough, that question is the whole migration project. This guide gives you the buckets to sort your data into, the codes to map, the tests to run before the switch and the questions to ask a vendor while you can still walk away.

What is PMS data migration, and what is it not?#

It is a planned transfer of a defined set of records into a new system, plus an explicit decision about what stays behind. It is not a copy of the old database.

A PMS (property management system, the software that holds reservations, the front desk, bills and reports) stores records with very different lifetimes. A reservation has a future. A closed folio has a past. A guest profile has neither until someone states a purpose for it. Migration is selection and translation, not backup: the new system models rooms, rates and charges differently, so each record has to be re-expressed in the new model rather than dropped in as it was. If you want more background on how the core hotel systems fit together, read that first.

Sort every data set into three buckets: move, keep read-only, leave behind. Anything you cannot place in a bucket is a decision you have not made yet. Give each data set one owner: finance owns balances, invoices and city ledger; reservations owns blocks and allotments; revenue owns rate plans; the hotel, as data controller, owns every decision about personal data.

The old system is not switched off on go-live day. It becomes a read-only archive for a defined period, with restricted access and no new entries. Write the inventory before you talk to vendors: it becomes the scope document, the acceptance test and the reason you can say no to a change request later. Expect the inventory to be uncomfortable. It is the first time anyone has listed what the hotel actually holds.

What data must move to the new PMS?#

Everything that still has an effect after the switch date: future reservations, deposits, open accounts, allotments, group blocks and rate plans. Anything that only has a past stays where it is.

Future reservations means every booking with an arrival after cutover, from every source, carrying the confirmation number the guest is holding. A guest who calls on the first morning must be findable under the number they were given. Deposits and prepayments move as a liability attached to the reservation, never as a payment received on the arrival date. Re-entering them as new payments breaks the bank reconciliation and the guest's bill at the same time.

Open accounts arrive with their charges to date, so check-out continues the bill instead of restarting it. A folio that arrives at zero and then gets charged again is a double charge waiting to happen. Group blocks and allotments arrive with release dates, pickup counts and the contract reference: a block that arrives without its release date either holds rooms forever or releases them too early, and both cost money. Rate plans arrive with inclusions, cancellation terms, minimum stays and the market segment and booking source they post to, because a rate plan without its posting codes produces a month of reports nobody can read.

What does not move: closed periods, historic folios, issued invoices and old daily guest lists. They are not lost, they are archived, and the next section explains why.

If you are still choosing a system, these are also questions to ask a PMS vendor before you sign.

How do you map the old codes to the new ones?#

Build a written crosswalk: every old room type, rate code, market segment, booking source, outlet and payment type gets a named counterpart in the new system, or an explicit decision that it retires.

The two systems rarely have the same grain. One old room type may split into two in the new system, and two old rate codes may merge into one. Splits are safe; silent merges destroy the reporting history you are migrating for. Market segment and booking source codes drive every channel and production report, so map them loosely and the first month's numbers will be wrong in a way nobody can trace back. Map tax codes, payment types and outlet definitions with the accountant, not by guesswork: these decide how a charge appears on a fiscal document after the switch.

Retire codes with no future use instead of mapping them all into a catch-all bucket. The catch-all becomes a permanent drawer that nobody cleans and every report inherits. Keep the crosswalk after go-live; it is the document that explains why this year's report does not look like last year's. Test the mapping by pushing a known period of old data through it and comparing the totals with the report the old system produced for the same period. One rule for the whole project: no mapping exists until it is written down and someone has signed it.

For example, a crosswalk might look like this:

What stays read-only, and for how long?#

Closed periods, issued invoices, old folios and daily guest lists stay in the old system as a read-only archive, because tax and commercial law require the hotel to keep them and to be able to produce them.

Two separate duties apply. Türkiye's Tax Procedure Law (Vergi Usul Kanunu, Law No. 213) requires lodging places to prepare daily customer lists showing each guest's name, room number and room rate, and requires those who keep books to retain books and documents for five years counted from the start of the calendar year after the year they relate to (Articles 240 and 253), per the consolidated text on mevzuat.gov.tr (opens in a new tab). Türkiye's Commercial Code (Türk Ticaret Kanunu, Law No. 6102, Article 82) requires every merchant to keep its commercial books and the documents behind its entries for ten years, per the consolidated text on mevzuat.gov.tr (opens in a new tab). The periods differ by record type, so confirm the ones that apply to your hotel with your accountant.

The commercial rule is not only about keeping the file. Records may be held as images or on data carriers provided they match the originals when made readable, can be reached at any time during the retention period, and can be made readable within a reasonable time. A backup tape in a drawer does not meet that description. So the old system must stay queryable, or its data must be exported into a readable, indexed format where a search on guest name, date or room number still works.

Test the archive before you switch: pick one folio from two years ago and one issued invoice, and find them without help from the person who used to run the old system. Freeze it properly: no new entries, named read-only accounts, a written list of who can look and why. Do not migrate old folios into the new system just to have everything in one place; they pollute current reports and they add personal data to a system that has no purpose for it. Accounting and e-document continuity are a separate conversation with your accountant and your e-document integrator, and they belong in the cutover plan, not in the data migration.

Which guest profiles should you move?#

Move only the personal data the hotel still needs for a stated purpose and is allowed to keep. Summarise the rest into statistics, and delete what has no purpose left.

Türkiye's Personal Data Protection Law (Kişisel Verilerin Korunması Kanunu, Law No. 6698, Official Gazette 7 April 2016, No. 29677) requires data to be processed lawfully and fairly, kept accurate, processed for specified, explicit and legitimate purposes, limited and proportionate to those purposes, and kept only as long as the law or the purpose needs (Article 4). When the reasons for processing no longer exist, the controller deletes, destroys or anonymises the data, on its own initiative or at the person's request (Article 7), per the consolidated text on mevzuat.gov.tr (opens in a new tab). A migration is the moment these principles are actually tested, because every record you move is a record you decide to keep.

What revenue and front office usually need from old history is aggregate: room nights by market segment, average rate by month, repeat ratio by source. That can travel as summary statistics with no name attached, and it answers most of the questions a profile was being kept for.

Check what the old system holds before you copy anything. In Principle Decision 2025/2120 of 6 November 2025, published in the Official Gazette on 9 December 2025 (No. 33102), the Personal Data Protection Board found that recording name, surname and T.C. identity number is lawful and that checking the identity card is lawful, but that photocopying the card and keeping the copy is excessive processing; copies taken before the decision must be destroyed, per the Official Gazette (opens in a new tab). If the old system stores scanned identity documents, that is a deletion task, not a migration task.

Deletion and anonymisation are operations that must be recorded, under the Regulation on the Deletion, Destruction or Anonymisation of Personal Data (opens in a new tab) (Official Gazette, 28 October 2017), and a hotel that keeps a personal data retention and destruction policy destroys at fixed intervals set in that policy. Whether your hotel needs such a policy depends on its obligations, so confirm it with counsel. The KVKK's data security guide also says archive data that is rarely accessed should sit in a more secure environment, and that security requirements belong in the decision to procure a new system, including checks that stop bad input corrupting data. Put both in the vendor questions. For the day-to-day side of these duties, see handling guest data requests at the front desk.

How do you clean the data before moving it?#

Clean in a copy, decide every merge in writing, and keep a list of what you dropped and why.

Duplicate guest profiles are the largest single cleanup: the same person under three spellings, two nationalities and an old email address. Merge on a stable key where you lawfully hold one, otherwise on name plus date of birth plus contact, and log every merge. Unused codes, rate codes nobody has used in two years, market segments created for one campaign, outlets that closed, should be retired rather than carried into a system that will keep offering them in dropdowns for a decade.

Stale profiles, with no stay, no open balance, no consent and no stated purpose, are a deletion decision under the previous section, not a mapping decision. Orphaned records, charges with no reservation, blocks with no group, deposits with no booking, are each a finance question first and a data question second, so send them to the accountant before the migration, not after. Test and training records must never cross: find them by name pattern and by date, and delete them at source.

Clean in a staging copy while the old system is still live, so the front desk keeps working. Only clean the source itself if the old system is already frozen. Keep the drop list. It is the answer in month three when someone asks why a booking is missing.

How do you rehearse and reconcile the migration?#

Run at least one full test migration into a test environment, then compare counts and balances on both sides until every difference is explained.

Counts to compare: reservations by arrival date, room nights by month, group blocks with their pickup, allotments with release dates, rate plans, open folios, and deposits by currency. Balances to compare: open folios and city ledger to the kuruş, and deposits against the bank statement. A balance that is close is a balance that is wrong.

Every count has a named owner who signs it off. Finance signs the balances, reservations signs the blocks, revenue signs the rate plans. An unsigned count is an opinion. Treat every difference as one of two things: a mapping error to fix, or a record that should never have moved. There is no third category called acceptable.

Run the rehearsal a second time after the fixes. The second run is what tells you the process is repeatable rather than lucky. Time the rehearsal, too: the duration is what the cutover plan needs in order to decide when the front desk stops taking new entries in the old system. The final load on the night, the freeze window and the rollback decision belong to the cutover checklist for the night you switch systems.

What to do next#

Start with two documents this week, before you sign anything: a data inventory that puts every record in the move, read-only or leave-behind bucket with a named owner, and a written crosswalk from old codes to new ones. Everything else in a system change, the rehearsal, the counts, the balances and the night itself, follows from knowing exactly which records have a future and which have a past. If you are still choosing the system, ask the vendor to show you their migration and reconciliation process before you ask about features.