A Good System, Badly Implemented, Is Still a Failure: Why Hotels Shouldn’t Migrate Their Tech Stack Alone

After more than twenty years working in hospitality technology and implementing tech stacks at 50+ hotels, I can tell you that the most expensive line item in a system migration is rarely the software. It’s the rollback.

I want to walk through a pattern I see far too often, because the story I’m about to describe isn’t unusual. It’s the rule, not the exception. The names and details don’t matter. The shape of the problem is what matters, and the shape is almost always the same.

The Pitch That Got Politely Declined

A hotel we spoke to last year was running an ageing on-premise property management system. We were invited in, presented a full-stack proposal (booking engine, PMS migration to Cloudbeds, POS, accounting integration, OTA management, a new website), and structured it as a commission-only deal. There was no upfront systems cost. No retainers. No risk to the property if we didn’t perform.

They declined.

The reasoning, fairly enough, was that they preferred to focus on offline agents and didn’t believe digital marketing was the right priority for their property. They wanted to keep the old on-premise PMS in place. That’s a legitimate strategic choice and one I genuinely respect. Not every property’s growth comes from the same direction, and a hotel owner who knows their distribution mix is a hotel owner I’m always going to listen to.

What happened next is where the lesson lives.

The Quiet Pivot

A few months later, we heard through the industry grapevine that they had decided to migrate the PMS after all. To Cloudbeds, specifically. The system we had recommended. They had decided the advice was sound. They just preferred to implement it themselves.

This isn’t a complaint. It’s actually a fairly common decision, and I understand the logic completely. A hotel owner looks at a software migration and thinks, how hard can it be? The vendor provides training. They have a support team. We have a capable operations manager. We’ll save the implementation fee and do it ourselves.

That’s a reasonable thought process. It just turns out to be wrong almost every time.

What Happened Next

Some months later, after paying for the system, going through the onboarding training the vendor provides, and attempting to cut over from the old PMS, the implementation failed. The property rolled back to the original on-premise system. The Cloudbeds licence had been purchased. The migration had been attempted. The team had been trained. And none of it stuck.

The financial cost of that exercise (software licences paid for, staff hours invested, the operational chaos of a partial cutover and rollback) is significant. But it’s not even the biggest cost. The biggest cost is the loss of confidence. After a failed migration, the team becomes deeply sceptical of any future tech project. The old system becomes safer in the team’s mind, even when it’s actively losing the property money. The opportunity cost of staying on legacy infrastructure for another two or three years is rarely calculated, but it dwarfs the implementation fee they were trying to avoid.

A good system, badly implemented, is still a failure.

Why This Keeps Happening

I want to be clear about something. Cloudbeds is an excellent product. So is Mews. So are Opera and Shiji depending on the property type. The product wasn’t the problem. The product is almost never the problem. The problem is that hotel teams treat system migration as a software problem when it’s actually three problems at once:

It’s a configuration problem: Every hotel charges differently. Room types, rate plans, packages, allotments, channel mappings, derived rates, restrictions, blackouts, deposit policies, cancellation policies, tax setups, currency rules, group blocks. Every one of these has to be modelled correctly in the new system before a single booking flows through. A generic vendor training session covers the buttons. It doesn’t cover the decisions, and the decisions are where everything breaks.

It’s a data problem: Reservations in flight, historical guest data, loyalty members, supplier rates, accounting reconciliation back to the old system, channel inventory parity during cutover. Get any of this wrong and the property finds itself in front of a guest at check-in with no record of their booking. That happens once and the GM loses faith in the new system instantly.

It’s an integration problem: A modern hotel doesn’t run a PMS in isolation. It runs a PMS, a channel manager, a booking engine, a CRM, an accounting system, a POS, possibly a revenue management tool, and a reporting layer. Every one of those needs to talk to the new PMS correctly. Vendor training does not cover what to do when your channel manager and your new PMS disagree about a derived rate at three in the morning during a high-season weekend.

That third one is where most self-managed migrations die. The hotel team is competent. The systems are competent. The integrations are competent. But nobody owns the gaps between them, and the gaps are where revenue leaks out.

The Job Hoteliers Are Actually Paid To Do

Here’s the part I find most uncomfortable about watching this pattern repeat.

Running a hotel is one of the most operationally demanding jobs in any industry. A GM is managing a property, a team, a brand, guests, complaints, suppliers, owners, regulators, and a P&L, often simultaneously. Asking that same person to also project-manage a multi-system technology migration, on top of their day job, isn’t reasonable. It isn’t a question of capability. It’s a question of bandwidth and specialisation.

When I worked in hotels myself, including a decade as e-commerce & revenue manager for a Phuket group overseeing tech, I made every mistake in this list at least once. I migrated booking engines without proper rate parity testing. I switched channel managers and watched inventory go out of sync for forty-eight hours. I assumed vendor training was sufficient and found out, in production, that it wasn’t. Every one of those mistakes cost money I didn’t have to lose, and every one was avoidable if I’d had someone next to me who had done it a hundred times before.

That’s the entire reason The Percentage Company exists. We’ve done these migrations dozens of times. We know which questions to ask in week one that prevent disasters in week six. We know what generic vendor training leaves out. We know how to configure Cloudbeds for a Thai boutique hotel differently from how we’d configure it for an apartment-style property in Bangkok or a beach resort in Krabi.

What “Doing It Alone” Actually Costs

Let me try to put numbers on this, because the hidden cost of a failed migration is almost always larger than the visible cost of a specialist-led one.

A typical failed self-managed PMS migration costs a property somewhere between three and six months of operational disruption, software licences that were paid for and abandoned, staff time absorbed into the project rather than into the property, and (this is the one that hurts most) the opportunity cost of staying on the old system for another two to three years because nobody on the team wants to try again.

For a property doing THB 30 to 50 million a year in revenue, staying on an inadequate PMS for an extra two years can quietly cost millions in lost direct bookings, missed yield opportunities, manual reconciliation errors, and the kind of operational drag that prevents a property from scaling at all. Across our active hotel client portfolio, we’re collectively saving over THB 57 million a year in OTA commissions that would otherwise be flowing to platforms. That figure isn’t possible without a properly migrated, properly integrated, properly configured tech stack underneath it.

The implementation fee a property pays a specialist isn’t an additional cost. It’s the cost of avoiding a much larger one.

What a Proper Migration Actually Looks Like

I’m not going to turn this into a checklist, because the value isn’t in the checklist. The value is in the judgement of when to apply each part of it. But the broad shape of how we approach a system migration is worth describing, because it makes the gap visible.

Before any system goes live, we model every rate, every package, every restriction, and every integration touchpoint. We test in parallel with the old system running. We migrate data in stages, not in a single cutover weekend. We train the team on the specific configuration we’ve built (not on generic vendor documentation). We sit alongside the property for the first thirty days, watching for the integration edge cases that vendor support won’t catch. And critically, we own the outcome. If something breaks at three in the morning during a high-season weekend, that’s our problem to fix, not the GM’s problem to discover at six.

That kind of work is genuinely hard to do well. It’s also genuinely hard to value before you’ve experienced what happens without it.

The Honest Truth

I’m not writing this to gloat about a deal we lost. I’m writing it because the property in question is now back on its old PMS, the team is exhausted, the trust in their own ability to migrate has been damaged, and they’re further away from a modern operating stack than they were before they tried. That’s a worse outcome for them than either choice (staying put or partnering with specialists) would have been.

The version of this story I’d genuinely have preferred is the one where they said no, and the old system kept working perfectly well for them for another five years. That would have been a fine outcome. The version that actually happened (a half-finished migration, a forced rollback, a more sceptical team, and a return to a system that was already failing them) is the worst of every possible world.

The decision to migrate or not migrate is yours. That part is entirely up to the property and the owner. The decision to do a migration alone, without someone in the room who has done it before, is the decision I’d push back on every time.

A Final Thought

The hotel industry has a habit of underestimating systems work because the work itself is invisible when it’s done well. A guest never notices that the rate parity between Booking.com and the direct website is perfect. They never notice that their reservation flowed cleanly from the channel manager into the PMS into the CRM. They never notice that the night audit ran clean. They notice when those things break. They never notice when they work.

That invisibility is what makes the work easy to undervalue, and easy to attempt alone. It’s also what makes it the single highest-leverage investment a property can make in its commercial future.

At The Percentage Company, we’ve built our business around doing this work properly, so that hotel owners can focus on what they’re actually paid to do, which is run a brilliant property and look after their guests. Our commission-only model exists for a specific reason: it means we only win when the property wins, and we absorb the cost and the risk of the implementation up front. If a migration fails, we wear that cost, not the property.

If you’re looking at a system migration, considering moving off legacy infrastructure, or simply trying to work out whether your current stack is holding the property back, we’d be happy to have a conversation. There’s no obligation, and no pressure. Just a candid view from people who’ve done this dozens of times.

The systems are the easy part. Getting them to work together, properly, in a real hotel, with real guests, is the part that takes specialists. We’d rather help you get it right the first time than meet you again on the other side of a rollback.