The 2027 Switching.

For two decades, European hospitality has run on software that was sold once and renewed forever. Front-desk systems installed in the early 2000s still ring up tonight's check-in. Nobody stays because they love the software. They stay because leaving means a hundred small frictions, none of them a dealbreaker on its own, and together they add up to never leaving.

That lock-in has an expiry date: 12 January 2027.

On that date, the final phase of the EU Data Act's cloud-switching regime kicks in. Since January 2024, Article 29 has required vendors to limit switching charges to the costs they actually incur in a migration: no profit margin, no penalty fees dressed up as 'professional services'. From 12 January 2027, even those cost-recovery charges become unenforceable. The provider absorbs the cost of letting a customer leave. Together with the broader portability obligations of Articles 23 through 31, this removes the legal machinery that has let a generation of hospitality vendors price the door shut. After 12 January, the cost of switching is the actual work of moving — and most of that work, as we'll get to, is retraining people.

The hospitality stack that was built to never be left

To see why this date matters, look at what an independent European hotel currently runs. A 40-room boutique typically pays for: a property management system; a separate channel manager; a payments gateway with its own contract; an accounting system; an F&B point-of-sale; a spa booking system that doesn't quite integrate; a housekeeping app one of the staff downloaded; a business-intelligence dashboard sold to the owner; a CRM the marketing assistant uses; an email tool; a phone system; a website maintained by a vendor whose URL nobody can remember.

Twelve separate vendors, none of them built for how the property actually runs, connected to each other (when they're connected at all) by brittle middleware, manual exports, and the habits of the night auditor. We've been on the owner's side of this stack: paid the renewals, kept the binder with the twelve support numbers. What follows isn't market research.

This is not an accident. It is the design of the market. Each of those twelve vendors prices its switching cost at zero in the sales deck and at five figures in renewal negotiations. Moving any one of them is bearable. Moving more than one at a time is not. So nothing moves, and the stack sits there for another year.

The stack wasn't designed this way because anyone planned it. It emerged through years of acquisitions, integrations, point solutions and incremental upgrades. Each component solved a local problem. Together they created something harder: an operation spread across dozens of systems, ownership boundaries and data models. Humans learned to bridge those gaps. Software never did.

That mattered less when software was mostly a system of record. It matters enormously once software starts making decisions: the more intelligence you ask of a system, the more every boundary inside it costs you. A decision is only as good as the context behind it — and each of those boundaries is context the software never sees.

The vendors understand this perfectly. The industry's last fifteen years have followed one script: consolidate around the top vendor, partner instead of build, and eventually sell the consolidated platform to a private-equity buyer who optimises the existing rents rather than rebuilding anything. What gets sold to that buyer is the lock-in itself.

What the Data Act actually breaks

The Data Act attacks this in two ways.

First, the legal switching cost goes to zero. Vendors can still charge for genuine extras: accelerated migration, custom data conversion, a longer retrieval window on the old environment. But the baseline switch is free. The vendor's lawyers know this. The customer's lawyers know this. By 2027, every contract renewal happens in the shadow of a market where the customer can simply leave.

Second, the data becomes portable. The wider switching regime under Articles 23 through 31, in force since September 2025, requires vendors to hand over customer data in standard, machine-readable formats, within commercially reasonable timeframes, with equivalent functionality on the receiving side. The proprietary databases, the encrypted exports, the 'incompatible with our schema' replies that protected the legacy stack: all of it is now explicitly disallowed.

And 'standard' means more than it sounds like. Article 30 requires compatibility with common specifications based on open interoperability standards, published in a central Union repository; once a category's specification is out, vendors have twelve months to comply. So an export from Vendor A won't just be readable. It will be structurally compatible with an import into Vendor B. The migration that follows is, in effect, one engineering project applied 150,000 times.

Both effects land on the same date. No soft transition, no preview window. On 12 January 2027 the market is one structure; on 13 January it's another.

What the export won't tell you

We just said the migration wave is one engineering project applied 150,000 times. That's true for the file formats. It's false for what's inside them.

Anyone who has actually looked inside a twenty-year-old PMS database knows the data isn't clean. It isn't even wrong in a consistent way. Twenty years of front-desk staff have worked around every limitation the system had. The same guest exists four times under three spellings, and a note on the second one says which one is real. The booking remark reads "NOT the Mr. Huber from Linz, the other one." Room 112's recurring heating problem lives in a housekeeping memo from 2019 that everyone knows to check and no report has ever surfaced. The data model stopped describing the hotel years ago. The truth lives in note fields, naming conventions, and the night auditor's head.

A machine-readable export carries all of that across faithfully: duplicates, workarounds, tribal shorthand and all. Readable was never the hard part. Understanding what the hotel meant is.

The challenge is bigger than moving records between databases. Modern hospitality software is rarely a single system; it is a collection of systems that learned to coexist — guest data in one place, revenue in another, staff in a third, stitched together by integrations that each carry their own assumptions about timing, ownership and meaning. The export moves the records. It does not move the relationships between them.

A reservation is not just a reservation. It is a sequence of decisions: a booking created, a room assigned, a rate adjusted, a guest upgraded, a complaint resolved, a refund issued. The data survives the journey; the context often does not. A person rebuilds that context from experience. AI doesn't reason over screens; it reasons over context — and an operation recorded as disconnected transactions is a fundamentally different thing from one recorded as a coherent sequence of events.

So that's where we're putting our work: migration agents that read twenty years of notes the way a new colleague would, ask the front desk the questions a good trainer would ask, and turn workarounds back into structure, flagging what they're unsure about instead of guessing. The Data Act opens the door. Someone still has to carry the meaning through it.

The cost everyone forgets

Lawyers focus on the contract. Engineers focus on the data. Anyone who runs a building full of staff knows there's a third cost, bigger than both: retraining people.

A property management system is muscle memory for the people who sit in front of it eight hours a day. A receptionist who has worked the same screens for fifteen years can resolve a complex check-in in twenty seconds. The same receptionist, on day one with a new system, takes four minutes and apologises three times. Multiply that across the front desk, housekeeping, F&B, and the owner who needs to sign reports. The real cost isn't the trainer's invoice; it's a measurable drop in service quality that lasts a season.

For most independents, this is what has actually kept them where they are, since long before the Data Act. Legal lock-in protected the bad products. Training lock-in protected all of them.

This is where AI-native systems matter, though not in the way most vendors have marketed them. A chatbot grafted onto a thirty-year-old interface doesn't reduce training cost. It increases it: now staff have to learn the old interface and the bot. Cutting training cost for real takes a system you can operate in plain language, one that can walk a new user through any workflow the first time they meet it, in their own language, whatever their colleagues happen to speak.

You can't bolt that on. Either the system was built this way from day one, or it can't do it at all.

The window opens

So: on 12 January 2027, legal lock-in ends and the data becomes portable. Training lock-in falls for any vendor whose onboarding genuinely works in the staff's own language. For the first time in two decades, an independent hotel can leave without absorbing a quarter of operational pain.

What happens next is a rebuild cycle. Analysts have spent a decade asking when European hospitality SaaS would consolidate. Wrong question. What 2027 unlocks is replacement: property after property migrating off twelve-vendor stacks built in 2008, onto whatever the operating system of the next decade turns out to be.

Across the EU, EEA, UK and Switzerland there are roughly 150,000 independent and boutique hotels, 700,000 mid-market restaurants, maybe 30,000 standalone spas and 25,000 campsites. Add the rest of the operating layer (staffing, payroll, compliance, marketing, web presence, AI agents) and European hospitality is worth somewhere around €10 billion a year in mature recurring revenue. Essentially none of it runs on a system built for the conditions of 2027.

The first vendor that shows up in 2027 with a real alternative to the twelve-vendor stack doesn't have to win every property. Winning the ones that move first is enough, and a property that has spent twenty years not moving has a long backlog of reasons to move now.

What gets built for the world after

The conditions of the new market dictate the shape of the answer.

It has to be AI-native. Operating costs in hospitality run at 50% of revenue. Expanding that margin means AI doing work that humans currently do, not AI helping humans do the same work slightly faster. That takes a system where the AI is the operator and the human reviews, not the other way around.

It has to record decisions, not just changes. The EU AI Act requires meaningful human oversight of AI in regulated contexts: an immutable record of what the AI did, what it knew when it did it, and what the human overrode. You can bolt change-capture onto a CRUD-era PMS and replay every row that ever changed. What you can't replay is why. A row diff doesn't distinguish an AI decision from a manual correction, and it never saw the options the AI rejected. That record has to be written at the moment of decision, in the vocabulary of decisions. It's why we built event-sourced from day one.

It has to be sovereign by location and multilingual by design. EU data-residency expectations rule out vendors that route customer data through the US by default. And staff in a single European property routinely work across four or five languages: with guests, with each other, with regional vendors. Translation can't be an integration. It has to live inside the messaging layer.

It has to collapse the twelve-vendor stack into one. The economics of the post-2027 market are blunt: customers will leave for any vendor that can replace three of the twelve. The vendor that can replace eleven of them owns the migration wave.

Where we stand

We've been quietly building the system we wished we'd had. Most of it runs on AWS today. A complete virtual hotel exercises the whole stack around the clock: synthetic guests booking and complaining, synthetic staff calling in sick and getting rescheduled. Pilot properties in Austria and Sweden go live in late 2026, in time for the window.

We're not pretending we'll be the only entrant. As far as we know, we're the first to build specifically and exclusively for the world that arrives on 12 January 2027. The largest current cloud hospitality vendor recently raised $300 million to evolve its existing platform into an AI-native one — a transformation measured in years, not quarters, on an architecture that wasn't designed for it. We started from the AI-native architecture, and we're proving it in a live virtual hotel. By the time their version ships, the rebuild cycle will be half over.

The bet is simple, and we may be wrong about the pace but not about the direction: two decades of lock-in expire on 12 January 2027, and the vendor ready to serve the rebuild when the window opens owns the next decade of European hospitality software.

We built for the world that arrives after.