Every deferred cloud migration we encounter is deferred for the same reason. Not cost, not complexity: fear of breaking the thing that currently works. The ageing server in the cupboard is slow and expensive, but it is a known quantity, and "known" beats "better" in most risk-averse decisions.
That fear is rational when a migration is planned as one big weekend. It evaporates when a migration is planned as a sequence of small, individually reversible moves. Here is the playbook we run.
Step one: inventory everything, especially the embarrassing things
You cannot migrate what you do not know exists. The inventory covers servers, applications, databases, file shares, scheduled tasks and integrations, plus the embarrassing layer every business has: the Access database finance secretly depends on, the label printer that only talks to one machine, the licence dongle plugged into the server itself.
Migrations do not fail because of the ERP. They fail because of the dongle nobody documented. Surface it all now, while it is a planning item rather than a 2am incident.
Step two: map dependencies before choosing an order
Systems hold hands. The job tracker reads the file share, the file share authenticates against the directory, the directory syncs to email. Move things in the wrong order and you break a chain you did not know existed.
The dependency map decides the migration sequence, and it almost always produces the same shape: move the leaf nodes first (things nothing depends on), and the trunk last. It also tells you what can move independently, which is what makes a staged, low-drama migration possible at all.
Step three: decide lift-and-shift vs re-platform, per workload
Two honest options for each workload:
- Lift and shift: move it as-is. Faster, cheaper upfront, and the right call for stable systems near end-of-life anyway.
- Re-platform: rebuild on cloud-native services, for example a database server becoming a managed database. More effort now, lower cost and maintenance forever after.
The trap is ideology in either direction. All-lift-and-shift recreates your old problems on rented hardware at a higher monthly bill. All-re-platform turns a migration into a year-long transformation program. The boring per-workload judgement call is the actual skill.
Step four: stage the cutovers, each with a rollback
This is the step that removes the fear. Every workload moves in its own window, and no cutover proceeds without a written rollback procedure: if validation fails by the agreed time, we revert, and Monday morning looks identical to Friday.
In practice that means parallel running where it matters: the new environment is built and tested while the old one keeps serving. Data syncs across, validation happens against real workloads, and the final cutover is a small switch rather than a leap. Most users should learn the migration happened from an email, not from an outage.
A migration with rollbacks is a series of decisions. A migration without them is a bet.
Step five: validate, harden, hand over
Go-live is not the finish line. Three things close a migration properly:
- Validation: performance benchmarks against the old environment, integration checks, restore tests of the new backup regime.
- Hardening: cloud defaults are not secure defaults. Identity, access policies, encryption and monitoring are configured deliberately, ideally mapped against the Essential Eight while the environment is fresh.
- Handover: runbooks, architecture diagrams and training for your team. If your business cannot operate the new environment without the people who built it, the migration created a dependency, not an asset.
What this means for the cupboard server
The honest economics: an on-premise server replacement is a five-figure capital hit every few years, plus power, patching and the single point of failure in the cupboard. A well-architected cloud environment converts that to a predictable operating cost with redundancy your cupboard will never have. The migration pays for itself; the question is only whether it happens in a planned window or after the hardware forces the issue.
Our Cloud Migration Blitz runs exactly this playbook: assess, plan, migrate, validate, with rollback procedures on every cutover and full documentation at handover. If you want to know what your migration would actually involve before committing to anything, book a health check and we will map it with you.
