A PMS consultant's playbook: why data migration deserves its own owner

A single unmapped legacy code, discovered on migration day, can force a hotel to rerun part of its PMS data migration. That's the core warning from Emanuel Arancibia, global PMS consultant at Shiji Group, whose technology platform serves more than 91,000 hotels worldwide, including the largest chains.

His argument is simple: hotels over-prepare integrations, configuration and training, then treat migration as a late-stage chore. "Treat migration as a project within the project: give it a clear owner, prepare and test it early, and give it enough time," Arancibia said. Execution is the phase where the plan meets the hotel's real data — and where small problems become major delays.

Where does execution actually go wrong?

Arancibia points to three failure points: mapping and testing, hotel-side ownership, and connected vendors.

Legacy PMSs carry years of old codes, some no longer in active use. If those codes still sit in the data, the new PMS needs to know what they mean. For codes with no direct equivalent, the rule — map to the closest equivalent or archive — should be agreed before migration, with a named person signing off the decision.

Rate data is the subtler trap. A reservation may migrate successfully while its value means something different in the new system. Does the rate include VAT, city tax or breakfast? Is it net, base or gross? Arancibia's test isn't "did the reservation migrate?" but "does it mean the same thing in both systems?"

His recommended method: compare a sample of real reservations and guest profiles across both systems in three steps:

• Pick a sample that includes old or inactive codes, rates with different inclusions, incomplete profiles and duplicates.
• Check each rate and its components in both systems.
• Where something doesn't match, identify why, correct it and retest with the same sample.

Who owns the migration on the hotel side?

Availability of the hotel team is what separates smooth migrations from chaotic ones, Arancibia said. The person supporting the migration usually keeps operational duties, so they can't always answer when the migration team has a question.

He wants hotels to settle four things before execution begins:

• Who is responsible for the migration on the hotel side?
• Who makes decisions when an issue appears?
• Which stakeholders must be reachable for specific questions?
• Who is the backup if the main person is unavailable?

Technology alone, he notes, doesn't remove the need for process alignment and people involvement.

What about connected vendors?

The hotel keeps operating during migration, and third-party systems may already hold guest profiles. When migrated profiles start flowing in, the vendor's system could update an existing record, create a duplicate, or fail to match. Arancibia wants those answers before data moves, not after.

He also asks every vendor one deceptively small question: how long will you take to process our volume? His example: a system that takes one second per profile, facing 200,000 records, needs more than two days of processing — two days during which that system may work with stale data. The figures are illustrative; the principle is that per-record processing time must be planned against the hotel's actual data volume.

A gate, not a checklist

Arancibia's pre-migration checklist covers mapping, testing, profiles and source data, people, and connected systems. His instruction is to use it as a gate: if any question has no clear answer or no named owner, the hotel is not ready for the migration phase.

"A smooth migration isn't one where nothing unexpected happens," he writes — it's one where the team already knows what to check, who decides, and how to move forward. For hotels planning a PMS switch, the practical first step is running the checklist today: any unanswered question is the item to resolve first.