How to Avoid PMS Migration Chaos Once Execution Begins

The fastest way to create migration chaos? Treat your data as the final step of your PMS implementation.

Execution is the phase where the plan meets the hotel’s real data. By the time you discover an unmapped code, unexpected data issue or slow downstream system during the final migration, a small problem can become a major delay. This article covers what to check, who to involve and which questions to ask early in execution, so that the final migration does not become the place where problems surface.

My advice? Treat migration as a project within the project: give it a clear owner, prepare and test it early, and give it enough time. The sections below cover the three areas where execution most often goes off track: mapping and testing, hotel-side ownership, and connected vendors.

Before you migrate, check the mapping one more time

Legacy PMSs often contain years of old codes, including some the hotel may no longer actively use. But if those codes still appear in the data, the new PMS needs to know what they mean and where they belong. An unmapped code discovered during migration can mean additional work or even rerunning part of the migration.

So before go-live, I would ask:

• Are all the codes in the data we’re migrating actually mapped?

• Are old or inactive codes still attached to records?

• Who can explain an unfamiliar code if we find one?

• What happens when there is no direct equivalent in the new PMS?

For any code with no direct equivalent, agree the rule before migration rather than on the day: for example, map it to the closest equivalent or archive it, and record who signed that decision off.

Take a reservation rate. Does it include VAT, city tax or breakfast? Is it net, base or gross? A reservation may migrate successfully while the value is interpreted differently in the new PMS. That’s why I wouldn’t ask only “Did the reservation migrate?” I would ask “Does it mean the same thing in both systems?”

Compare a sample of real reservations and guest profiles between the two systems, in three steps. First, choose a sample that includes reservations with old or inactive codes, rates with different inclusions, incomplete profiles and duplicates. Second, check each rate and its components in both systems. Third, if something doesn’t match, identify why, correct it and test again with the same sample.

Treat migration as a project within the project: give it a clear owner, prepare and test it early, and give it enough time.

Emanuel Arancibia, Global Consultant, PMS

Someone from the hotel needs to own the migration

One of the clearest differences I see between migrations is the availability of the hotel team. Ideally, I want somebody at the hotel specifically looking after the migration. If the size and resources of the hotel allow more than one person to be involved, even better.

The challenge is that these people normally still have their day jobs. The person supporting the migration might also have operational responsibilities in the hotel, so they cannot necessarily be available whenever the migration team has a question. That is why I would not stop at assigning a project contact.

I would establish:

• Who is responsible for the migration on the hotel side?

• Who can make a decision when we encounter an issue?

• Which stakeholders need to be available for specific questions?

• If the main person is unavailable, who else can answer?

This reflects a broader reality with modern PMS projects: technology alone does not remove the need for strong process alignment, organizational readiness and people involvement. That is why ownership, decision rights and a backup contact should be settled before execution begins, not when the first question goes unanswered.

Ask your other vendors one very specific question: what will happen to this data?

Integrations introduce another consideration. The hotel does not stop operating while we migrate its PMS. During the migration itself, the property may still be working in its old PMS.

Where I pay particular attention to third-party vendors is when another system also contains customer data. Suppose that system already contains guest profiles. We migrate the hotel’s profiles into the new PMS, and afterwards information begins flowing to that connected system.

What happens?

• Does the connected system recognize that a profile already exists?

• Does it update that profile?

• Does it create another one?

• Could the hotel end up with duplicates?

These are questions I want answered by the relevant vendor before migrated data begins flowing into its system.

And then I ask something else: How long will you take to process the volume we’re going to send you? That can have a much bigger operational impact than people expect.

Imagine a vendor takes one second to process each profile. One second sounds insignificant, but 200,000 records at one second each is 200,000 seconds; more than two days during which that system may be working with data that has not yet been updated. Knowing that in advance lets us plan around it.

The point isn’t that every vendor takes one second or that every hotel has 200,000 records. Those figures are an example. The point is that processing time per record has to be considered together with the hotel’s actual data volume.

If we know a connected system will need a substantial amount of time to process migrated information, we can account for that when planning the migration. Discovering it once the data is already moving is very different.

Questions I would ask every relevant vendor

If I were the hotel project lead, I would ask:

• Do you already hold the same customer information we’re migrating?

• How will your system identify an existing profile?

• Will incoming information create, update or otherwise affect existing profiles?

• What happens if the system cannot match a record?

• How long will you need to process our expected data volume?

• What happens to the information in your system while that processing is taking place?

Those are much more useful questions than simply asking whether the integration is ready. Get each vendor’s answers before migration starts, and use the processing time they give you together with the hotel’s real data volume to plan the migration. Any questions a vendor cannot answer yet stays open on the checklist below.

Give migration the same importance as integration, configuration and training

Migration happens relatively late in a PMS implementation, and I think that can create a false sense that it is something we can address later.

Hotels naturally spend a great deal of attention on integrations. They want to know whether their connected systems will work. They focus on configuration. They prepare training. All of those things matter.

But migration requires preparation too. If we postpone that preparation because migration itself happens toward the end of the project, we risk arriving at the final phase with unresolved mapping, testing or data-quality questions. And the final phase is exactly when we have the least room for that kind of uncertainty.

So I would treat migration as its own workstream from much earlier in the implementation, even though the production migration itself comes later.

My practical pre-migration checklist

Before I considered the hotel ready for the migration phase, these are the questions I would want the project team to be able to answer.

Mapping

• Do the values contained in our migration data have an agreed mapping?

• Have we checked old or less frequently used codes?

• Do we know who can explain an unfamiliar legacy value if one appears?

Testing

• Have we tested how migrated reservations appear in the new PMS?

• Have we checked what rates actually represent, including relevant taxes or inclusions?

• Have discrepancies been resolved and tested again?

Profiles and source data

• Does the source data contain information that does not satisfy requirements in the new PMS?

• Have duplicate profiles been considered?

• Do we know how those cases will be handled before migration?

People

• Who at the hotel owns the migration?

• Who can make decisions during execution?

• Are the right stakeholders available when we need them?

Connected systems

• Which vendors will subsequently receive migrated information?

• Do they already contain the same guest profiles?

• Do we know how they will treat existing versus incoming records?

• Do we know how long they will take to process the expected volume?

Use this checklist as a gate. If any question has no clear answer or no named owner, the hotel is not yet ready for the migration phase, and that is the item to resolve first.

A smooth migration isn’t one where nothing unexpected happens

There are many moving parts in a PMS migration, and expecting every migration to follow the original plan perfectly is unrealistic.

What makes execution manageable is preparation.

If a code is missing, we need to know who can identify it. If a reservation looks wrong, we need enough testing to find out why. If an external system will receive thousands of profiles, we need to understand how it will handle them and how long that will take. And when a decision is required, somebody at the hotel needs to be available to make it. That is what ultimately prevents complexity from turning into chaos.

A successful migration is not about hoping everything goes perfectly. It is about doing enough work beforehand that, when something needs attention, the team already knows what to check, who needs to decide and how to move forward. A good place to start is the checklist above: any question your team cannot answer today is the one to resolve before migration begins.

Watch the full episode: