Start with an inventory, not a provider
Before choosing a provider or a target architecture, list what you actually run:
- Applications, with their business owner, criticality and users.
- Infrastructure: servers, databases, storage, network appliances, licences.
- Dependencies: which application calls which, shared databases, file transfers, scheduled jobs, hard-coded IP addresses.
- Data: volumes, sensitivity, retention rules, where it may legally reside.
- Operations: how each system is backed up, monitored, patched and supported today.
Dependency mapping deserves time. Network flow data and interviews with the people who run the systems usually reveal integrations that no document mentions — a nightly export to the accounting system, a printer queue, a partner's SFTP account.
Choose a strategy per application
There is no single migration approach. The common taxonomy, popularised by AWS, has seven options:
| Strategy | What it means | When it fits |
|---|---|---|
| Retire | Switch it off | Nobody uses it, or another system already does the job |
| Retain | Leave it where it is, for now | Recently upgraded, hard constraints, or not worth moving yet |
| Rehost | Move as is ("lift and shift") | Speed matters, the application is stable, change is risky |
| Relocate | Move the virtualisation platform as a whole | Large VMware estates with a compatible cloud target |
| Replatform | Move with targeted changes, such as a managed database | Clear gains with limited code change |
| Repurchase | Replace with a SaaS product | A standard package now covers the need |
| Refactor | Re-architect for cloud-native services | The application is strategic and its constraints block the business |
The answer is per application, and it can change over time. A common path is to rehost first to leave a data centre on schedule, then replatform or refactor the applications that matter most. For large, critical systems, refactoring is best done incrementally — the strangler fig pattern explains how.
Build the landing zone first
The landing zone is the foundation every migrated workload will live on: account or subscription structure, network design, identity and access, logging, encryption, backup and baseline security controls. Built once and described as code, it means each new application inherits the same controls instead of reinventing them.
This is also where data residency and key management are decided, in line with your sovereign cloud rules. Changing them after fifty workloads have landed is expensive.
Migrate a pilot end to end
Pick a first application that is real but not critical, and migrate it completely: infrastructure, data, monitoring, backup, runbooks, support handover. The pilot tests the landing zone, the tooling and the team, and it produces the template — checklists, scripts, test plans — that the next migrations reuse.
Then group the remaining applications into waves, ordered by dependencies and business calendar. Applications that talk to each other constantly should usually move together, to avoid latency and data transfer costs across the boundary.
Data migration and cutover
Data is usually the hardest part. The approach depends on volume and on how much downtime the business accepts:
- Offline copy: stop writes, copy, verify, restart in the cloud. Simple, but downtime grows with the volume.
- Continuous replication: copy the bulk in advance, keep source and target in sync, then switch over in a short window.
Whichever you choose, write the cutover plan as a runbook with named owners and timings, and include explicit go/no-go criteria and a rollback path. Rehearse it at least once on a copy of production. Verify data after migration with counts, checksums and business checks — totals that the finance team recognises are more convincing than technical logs.
Operations and cost after the move
A migrated application is only finished when it is run properly in its new home:
- Monitoring and alerting connected to the people on call.
- Backups tested by actual restores.
- Automated deployments, so that changes no longer depend on manual steps on a server — see our notes on CI/CD and small increments.
- Cost control: tagging every resource by application and owner, budgets with alerts, right-sizing after a few weeks of real usage, and switching off non-production environments outside working hours.
Cloud costs are variable by design. Without ownership and regular review they drift; with them, they become a lever the business can see and steer.
Where to start
Complete the inventory, choose the strategy for each application, build the landing zone and migrate one pilot end to end. Our cloud and cybersecurity service follows this sequence, with each step documented so that your team can run what we build.