Let me be straight with you about something. Most of what gets written about PMS migrations is written by vendors. It's polished, it's optimistic, and it describes a version of events that doesn't match what actually happens in your building during the weeks before and after go-live.
I'm not a vendor. I was the Reservations Manager and Systems Specialist at PUBLIC Hotel NYC when we moved the entire property from Oracle OPERA to Stayntouch. I was inside that migration — managing the data, running the staff training, fielding calls at 2am when something broke, and dealing with the fallout of every decision that was made too fast or not made at all.
This is what that actually looked like.
Why hotels move off OPERA in the first place
If you're running on a legacy version of OPERA, you already know the frustrations. The interface hasn't meaningfully changed in years. Your front desk team navigates it with function keys. It's slow. It requires physical servers on-site. And when something breaks — which it does — you're at the mercy of Oracle's support queue.
The appeal of Stayntouch is real. It's cloud-native, which means no servers on-site and no expensive hardware refresh cycles. It's mobile-first, which means your front desk team can work from a tablet. The guest profile system is genuinely good — detailed, accessible, and built for the kind of personalized service independent properties need to compete on. And compared to OPERA, the interface feels like moving from a 1990s desktop to a smartphone.
That appeal is legitimate. The migration to get there is where things get complicated.
What the vendor's project plan actually covers
When you sign with a new PMS, you get a project plan. It'll have phases, milestones, and a go-live date. It'll look thorough. What it covers is the vendor's side of the work — system configuration, data import templates, training sessions, technical support contacts.
"The vendor's project plan tells you what they're going to do. It does not tell you what you're going to discover."
What it doesn't cover is the operational reality on your end. The data cleanup that has to happen before anything can be imported. The integration dependencies you didn't know existed. The staff behaviors that are built around how your old system worked and have nothing to do with how the new one does. The decisions nobody made during the project that surface at go-live because there was no one accountable for making them.
These aren't edge cases. They are the normal experience of a PMS migration. And they're the part nobody budgets time or energy for.
The data problem — and it's bigger than you think
Your legacy data is messier than you know
OPERA has been accumulating data in its own structure for however many years your property has been running it. Guest profiles, rate codes, room type categories, corporate accounts, travel agent IATA numbers, group block structures — all of it exists in a format that made sense inside OPERA and doesn't automatically make sense anywhere else.
When vendors say "data migration," they typically mean the transfer of that data. The transfer is largely automated. The cleanup, the mapping decisions, and the exception handling — that's not automated. That's manual work, and it has to happen before the transfer, during it, and after it.
At PUBLIC, we discovered guest profiles that were duplicated across years of manual entry. Corporate accounts that had been set up differently by different people over time. Rate plans with logic that made sense in OPERA but didn't translate cleanly to how Stayntouch structures availability. None of this was a system failure. It was just the accumulated reality of years of human operation.
Rate mapping is where migrations quietly fall apart
Your rate structure in OPERA has its own logic. Room types, rate plans, restrictions, linked packages — all of it is mapped to how OPERA thinks about inventory. Stayntouch thinks about inventory differently. The gap between those two architectures is where rate mapping errors live, and they're subtle enough that they often don't surface until a guest calls about a discrepancy weeks after go-live.
You need someone who understands both systems well enough to build the mapping correctly the first time, and who knows what to look for when testing it. Testing rate mapping before go-live is not optional. It's the work.
The integration problem nobody flags until it's too late
Your PMS is not a standalone system. It talks to your channel manager. It talks to your booking engine. It may talk to your POS, your payment processor, your door lock system, your revenue management tool. Every one of those integrations needs to be tested — not just confirmed as "compatible" in a vendor spec sheet, but actually tested with real data flowing in both directions.
Compatible means the API connection exists. Working means the right data is being passed, in the right format, with the right logic on both ends. Those are different things.
We found integration dependencies during our migration that weren't on anyone's initial list. Not because the vendor missed them — because no one had done a complete audit of every system the PMS touched. That audit should happen before a project plan is signed. In practice, it almost never does.
The staff training problem
Most PMS training covers the interface. It shows your team where things are in the new system. That's necessary, but it's not sufficient.
The harder training problem is behavioral. Your front desk team has been working in OPERA for years. They have muscle memory. They have workarounds. They have habits that are tied to how OPERA handles things — check-in flows, folio management, rate modifications, reservation modifications during high-occupancy nights.
When you go live on a new system, those habits don't automatically transfer. What transfers is anxiety. Your team is now handling real guests, in real time, on a system they've used for two weeks. The margin for error is zero, and the pressure is high.
We trained over 50 staff members at PUBLIC before go-live. The key wasn't hours of classroom training — it was scenario-based practice. We built exercises around the specific situations that break at the front desk: the guest who calls to modify a package after check-in, the group block that needs to be split, the late checkout during a compression night. Train your team on those, not just the interface.
The cutover — when everything becomes real
Go-live day is the highest-risk moment in the entire project. Every decision that wasn't made during the project surfaces now. Every integration that wasn't fully tested either works or doesn't. Every staff member either has enough training to handle what's in front of them or they don't.
Most properties schedule cutover during a low-occupancy period. That's the right instinct — but low occupancy still means guests in house, real reservations, and a front desk that needs to be fully operational from the first minute. There is no warm-up period.
Have a clear escalation path for every category of problem that can happen during the first 72 hours. Who calls the PMS vendor? Who handles a guest complaint that's linked to a system error? Who has authority to make a call on the spot when something unexpected happens? If those answers aren't documented before go-live, you'll figure them out under pressure — which is the worst time to do it.
Post go-live: the problem that silently compounds
Here is the thing that almost nobody talks about. Once you're live and the immediate pressure subsides, the project is declared a success. The vendor closes out the implementation. Your team settles into the new system. Life moves on.
And then, quietly, things drift. Rate restrictions that were set as temporary during go-live get left on. Channel manager settings that were configured "for now" become permanent by default. The integration that was mostly working starts producing small errors that nobody catches because there's no process for catching them.
I'd argue the 60 days after go-live are as important as the 60 days before it. You need someone accountable for a post-go-live audit — checking rate configuration, integration performance, channel parity, staff compliance with new workflows. Not because the migration failed, but because drift is normal and catching it early is far cheaper than catching it after a guest complains or a revenue report doesn't add up.
What I'd do differently — and what I'd do the same
If I were starting the PUBLIC migration over again with everything I know now, I'd start the data audit earlier. Not two weeks before go-live — two months before. I'd map every system integration before signing the project plan, not after. And I'd build the post-go-live review into the project timeline before anyone could declare it done.
What I'd keep the same: the decision to move. OPERA to Stayntouch was the right call. The cloud-native architecture, the mobile-first design, the guest profile system — all of it delivered on what it promised. The migration was hard, but the system we landed in was genuinely better for the property and the team.
The work of getting there is just more involved than vendors make it look. And that gap — between what the sales deck says and what the project actually requires — is where most migrations run into trouble.
If you're planning a PMS migration and want to talk through the specifics of your situation, that's exactly what the Revenue Diagnostic is for. Forty-five minutes. No pitch. We look at where you are, what you're moving to, and where the real risks are for your property specifically.