Cloud migration for a law firm is a reasonably well-understood project. A few file servers, an email platform, a line-of-business app or two, a handful of laptops, and a plan that can happily absorb a weekend of downtime. Cloud migration for a hospitality group is a different animal. Your workloads include a real-time EPOS estate, site-level networks that cannot go dark, integrated hardware from printers to payment terminals to KDS screens, and a trading calendar that does not forgive maintenance windows. You cannot take a Friday night off to cut over.

This post is for hospitality IT leads and operations directors who are staring at an ageing on-site estate - a cupboard full of servers under the bar, a domain controller that has not been rebooted since the refit, a backup tape drive nobody has tested in eighteen months - and wondering what a realistic migration looks like in 2026. It is architectural rather than step-by-step. The goal is to give you a defensible plan, a sense of what genuinely belongs in the cloud and what genuinely does not, and a view on where groups usually go wrong.

What is already in the cloud (whether you planned it or not)

Most hospitality groups are further into the cloud than they think. If you took an honest inventory of your current estate, you would almost certainly find that the following already live off-premise:

  • Email and productivity - Microsoft 365, or occasionally Google Workspace. For nearly every group we take on, this is a finished migration.
  • Reservation platforms - SevenRooms, OpenTable, ResDiary, Design My Night. All SaaS, all cloud, all running without a server on your side.
  • EPOS back-office and reporting - modern EPOS vendors (Lightspeed, Toast, Tissl, Tevalis and others) keep configuration, reporting and analytics in their own cloud. The till itself is on-site; the back-office is not.
  • PMS for hotels - increasingly cloud-native. Mews, Cloudbeds, Opera Cloud and their peers are displacing locally-hosted PMS at pace.
  • HR, rota and payroll - Fourth, Harri, Planday, Deputy. All SaaS.

If you already run these well, you are genuinely further along than you might feel when you look at the server cupboard. The question is rarely “do we need to go to the cloud” - it is “what is left on-site, and does it belong there?”

What still lives on-site (and probably should)

The honest answer for a trading venue is that plenty of things still belong in the building. The workloads that are hardest to move, and often should not be moved at all, share a common property: they need to keep working when your broadband does not.

  • EPOS front-end (the till itself). The hardware sits on the bar. The local EPOS database sits on a machine in the back office or on the till itself. Good EPOS platforms handle offline trading gracefully precisely because connectivity in trading venues fails.
  • Kitchen printers and KDS. These talk to the till over the local network. They do not want to be round-tripping via the cloud.
  • CCTV and access control. Recording and retention are typically local, with cloud as a management plane rather than a storage destination. Retention requirements (often 31 days at minimum, longer for licensed venues) make pure cloud expensive.
  • Guest and staff Wi-Fi controllers. Cloud-managed, yes - cloud-dependent for the data plane, no. You want the network to keep forwarding packets if the management tunnel drops.
  • PMS, sometimes. If you are running a locally-hosted PMS that has not yet been replaced, the migration target is usually the vendor’s cloud product, not a lift-and-shift of your existing install.

Hybrid is not a dirty word in hospitality. It is the right answer for the workloads that keep the venue trading.

The three realistic migration targets

Strip away the hype and there are really three migrations worth having on the roadmap for a hospitality group. Most of the value sits in the first two.

1. Email and productivity to Microsoft 365

If you are not already on Microsoft 365, this is the first move and it is not optional. Mail, calendars, Teams, SharePoint, OneDrive. Business Premium for anyone with a managed device, so you get Intune, Defender and conditional access in the bundle. There is no defensible case for running your own Exchange in 2026, and not much of one for Google Workspace in a Microsoft-centric estate.

2. File servers to SharePoint and OneDrive

The second move is retiring the on-site file server. For most groups this is the single most satisfying migration because the file server is the thing that fails most visibly - the backup that did not run, the permissions nobody can unpick, the disk that fills up on a Saturday night. SharePoint for shared content, structured around sites and functions; OneDrive for personal work in progress; and an honest conversation about what actually needs to be migrated versus what can be archived and walked away from.

Done properly, this project also fixes the sprawling permissions problem that on-site file servers accumulate over years. Do not lift and shift folder structures verbatim - use the migration as the excuse to redesign.

3. Back-office line-of-business apps to Azure or the vendor’s cloud

The third target is the back-office LoB estate - finance systems, procurement, BI and reporting, bespoke apps, the SQL databases that management reports run from. For each of these there are three plausible destinations:

  • The vendor’s own cloud, if they have one. Usually the right answer, usually the cheapest over three years, almost always the least risky.
  • Azure IaaS or PaaS, if the app has to keep running and the vendor has no cloud product. PaaS where possible (Azure SQL rather than SQL Server on a VM), IaaS only where you must.
  • Retirement, if the app is no longer earning its keep. A surprising proportion of on-site servers are running things nobody actually uses any more. A migration is an excellent moment to find out.

Where groups get this wrong

Across the migrations we have done and the ones we have been called in to rescue, the same handful of mistakes recur.

Lift-and-shift with no re-architecture. Taking a ten-year-old Windows Server 2016 box and dropping it into Azure IaaS unchanged. It works, more or less, but it is more expensive than the on-site equivalent, it does not benefit from any PaaS capability, and it inherits every patching and performance problem the original had. Cloud is a chance to re-architect. If you are not going to take it, leave the workload where it is until it can be properly replatformed.

Cloud-hosting EPOS databases without a resilient connection. We have been asked, more than once, to help move an EPOS database into the cloud because “everything should be in the cloud now.” If your venue runs on a single broadband line and you put the till’s database at the other end of it, you have taken an offline-capable, resilient system and made it fragile. The front-of-house till should trade offline through an outage. Moving its database to the cloud usually breaks that.

Migrating data but not identity. Moving files to SharePoint without moving authentication to Entra ID, so users end up with two sets of credentials and no conditional access. Or migrating a LoB app to Azure without bringing it into single sign-on. The identity layer is the migration - the data is the easy part.

Forgetting backup. On-site backup, whatever state it is in, is at least visible. Cloud workloads need a deliberate backup strategy - native Microsoft 365 backup for SharePoint, Exchange and OneDrive; Azure Backup or a third party for Azure IaaS and PaaS. “It is in the cloud, so it is backed up” is not true and has never been true.

Ignoring the site network. Migrating workloads to the cloud raises the stakes on the broadband circuit at every venue. If you move your back-office to Azure and your site still has a single 80/20 VDSL line with no failover, you have concentrated risk in the weakest part of the estate. Resilient connectivity - dual circuits, 4G/5G failover, SD-WAN where it is justified - is part of the migration, not an afterthought.

The phasing that actually works

A defensible cloud migration plan for a hospitality group is sequenced, not parallel. The order we recommend, and run for groups we work with as part of our IT support for hospitality, is:

  1. Email and productivity first. Microsoft 365, properly licensed, with MFA and conditional access from day one.
  2. Files second. Retire the on-site file server to SharePoint and OneDrive. Redesign the information architecture rather than lifting folders across.
  3. Identity and device management alongside. Entra ID as the single source of truth, Intune on managed devices, joiner/mover/leaver automation wired into your HR or rota system.
  4. BI, reporting and analytics third. Move reporting out of on-site SQL and into Azure SQL, Fabric or Power BI or the vendor’s own analytics product.
  5. Back-office LoB apps fourth. Replatform or replace, taking each app on its own merits.
  6. Retire the on-site servers last. Only when everything that matters has moved. Keep a minimal on-site footprint for the things that genuinely belong there - EPOS, printers, CCTV, network.

Phased over twelve to eighteen months for most groups. Quicker is usually a warning sign; slower is usually drift.

Security in the migration

A migration is the best opportunity you will get to raise the security floor of the estate. The non-negotiables are the same ones we push on every hospitality group:

  • MFA for everyone, without exceptions, with number matching.
  • Conditional access gating admin roles, blocking legacy authentication, and requiring compliant devices for privileged actions.
  • DLP across Exchange, SharePoint and endpoints for card data, supplier bank details and employee information.
  • Endpoint management via Intune on every managed laptop, with Defender reporting somewhere that is actually watched.
  • A real backup strategy for the cloud workloads, tested at least quarterly.

If the migration lands without these in place, it has not really finished. We cover the wider hospitality threat picture in our cyber security work, and it is the lens we migrate through.

Cost: TCO, not capex

The honest cost conversation in hospitality cloud migration is about total cost of ownership, not capex. Yes, you will stop buying servers on a five-year cycle. Yes, the server cupboard will shrink. But you will pay monthly for Microsoft 365 licences, for Azure consumption, for vendor cloud subscriptions, for backup, and for the managed service that keeps it all running. The honest numbers usually show a modest increase in monthly run-rate and a meaningful decrease in risk, downtime and capital spend. Anyone who promises you the cloud is cheaper is selling you something.

What the cloud is, reliably, is more resilient and more maintainable - provided the migration is done well and the estate is run well afterwards.

The CloudMatters view

We are a Microsoft Solutions Partner working almost exclusively with London hospitality. We have done these migrations enough times to know where the sharp edges are, and enough times to know which workloads belong in the cloud and which should stay on the bar. Our default is a phased, architectural migration that gets email and files right first, wires identity and security in as part of the move, and leaves a deliberate on-site footprint for the things that keep the venue trading.

If you are looking at an ageing on-site estate and trying to work out where to start, we would rather help you plan it than help you recover from it. Our managed cloud service covers the design, the migration and the ongoing run - and if you are not sure whether your current plan holds up, we are happy to take a look at it before anything moves.