PMS migration stalled mid-rollout

The new system is picked on the basis of a demo, a price or a recommendation. What the property actually needs — half board, groups, multiple languages, interfaces — is written down nowhere. The gaps only surface after go-live.

Before any demo, write a list: what the system must do, what would be nice, what does not matter. Derived from your own operation, together with the team. Every demo is checked against the list, not against a gut feeling.

Guest records with duplicates, rates full of exceptions, bookings for the next twelve months, tour operator contracts — all inside the old system and in no shape to be moved. What travels and what stays was never decided.

Clean the data before the switch: merge duplicates, simplify rates, drop legacy baggage. Decide what gets migrated and what gets archived. A clean base makes the move half as hard.

The migration is scheduled when pressure peaks — shortly before or during the season. There is no window for parallel operation, training or fixing mistakes.

Migrate in the quietest phase, on a fixed schedule: data move, parallel operation, training, cut-over date. Agree a fallback option. If the window is too short, postpone — do not compress.

Management picks the new system and shows it to the team on a single training day. Reception, who uses it every day, was never asked. Resistance is the logical result.

Involve the users early: requirements, demos, test phase. One person from the team as the internal point of contact who knows the new system before everyone else. The migration succeeds when the team wants it.