Plan your cloud migration in four phases: assess what you have, pilot with one low-risk workload, migrate in dependency order with a rollback plan, then optimise costs once you have landed. Most migration failures are not technical — they come from skipping the assessment, migrating without a pilot, or discovering the bill after the fact.
Phase 1 (assess and inventory), Phase 2 (pilot), Phase 3 (migrate in waves), Phase 4 (optimise), the five failure modes, and a migration checklist — in that order.
Still deciding whether the move pays off at all? Start with our cloud migration guide for small businesses — it covers when migration pays and how to plan it, before you commit to the four phases below.
Phase 1: assess and inventory
You cannot migrate what you have not mapped. Build an inventory of every application, database, file share and integration: what it does, who owns it, what it depends on, how much data it holds, and any compliance requirements (customer data residency, financial records). Then classify each workload with the "6 Rs" — the industry's standard strategies, in plain English: Rehost ("lift and shift") — move the server as-is to a cloud VM; fastest, but keeps old inefficiencies. Replatform — move with small optimisations, e.g. lift the database to a managed cloud database; the sweet spot for most SMBs. Repurchase — replace with SaaS (move off that creaking on-premise mail server to Google Workspace). Refactor — re-architect for cloud-native (containers, serverless); most powerful, most expensive. Retain — deliberately leave it where it is (that ancient accounting system nobody dares touch). Retire — switch it off; migrations routinely discover systems nobody uses. For a small business, expect mostly rehost and replatform, a little repurchase, and almost no refactor — refactor is a rewrite wearing a migration costume, and it should be budgeted as one. Write the classification down per workload in a simple table — application, strategy, owner, data size, cutover window — and get sign-off from each owner before the pilot starts; that table becomes the migration's source of truth.
Phase 2: pilot with one workload
Never migrate everything at once. Pick one workload that is low-risk but representative: non-critical, with real data and real users, touching the network and database patterns your other apps use. A company blog, an internal tool, or a secondary application are classic pilots. The pilot validates four things: cost — run it for a month and compare the actual bill against the estimate (this is where bill shock gets discovered cheaply); performance — is it actually faster, and where are the latency surprises; team skills — can your people (or vendor) operate this confidently; and process — deployment, monitoring, backup and restore, all rehearsed on something that does not matter. Document everything learned; the pilot's runbook becomes the template for every later wave. If the pilot struggles, that is success — it struggled cheaply and taught you what to fix.
Phase 3: migrate in waves
Order the migration by dependency: infrastructure services first (DNS, identity, monitoring), then databases, then the applications that use them — migrating an app before its database is live is a classic self-inflicted outage. Data migration deserves its own plan: measure data volumes, estimate transfer times honestly (a terabyte over a business broadband line takes days, not hours — consider physical transfer or seeding), and plan for the cutover window when data must be frozen or synced. Choose a cutover strategy per workload: big bang (switch everything at a quiet hour — simple, but the rollback window is short) or phased (run old and new in parallel, migrate users gradually — safer, more work). Either way, write the rollback plan before you need it: what triggers a rollback, who decides, and the exact steps to revert. A migration without a tested rollback plan is a hope with a budget.
Phase 4: optimise after landing
Migration is not the finish line; it is the starting line for cost control. In the first month post-migration: rightsize everything — the VMs you specced generously "to be safe" are now measurable; shrink them to actual usage. Kill the orphans — test instances, old snapshots, unattached storage from the migration itself. Apply discounts — sustained-use discounts (automatic on Google Cloud) or Savings Plans (AWS, needs commitment) for the steady-state baseline you can now see clearly. Set billing alerts and budgets if you have not already — the migration estimate is now replaceable with real data. Review monthly for two quarters: cloud bills drift upward through small, reasonable decisions unless someone watches. Teams that do this typically find 15–30% in waste in the first review — found money that funds the next phase of work.
For honest price bands and the hidden costs buyers usually forget, see our cloud hosting cost guide for businesses.
The five failure modes
- Lift-and-shift bill shock. Moving inefficient on-premise servers as-is to pay-per-use cloud converts capital waste into a monthly bill. Replatform the obvious wins during migration, not after.
- No billing alerts. The number-one cause of horror-story invoices is not prices — it is nobody watching. Alerts on day one, no exceptions.
- Skipped testing. "It worked on-premise" is not a test plan. Performance, failover, backup restore and security groups all need verification in the new environment.
- DNS and cutover chaos. Low TTLs set days in advance, a written cutover sequence, and one person owning the checklist — migrations fail socially more often than technically.
- No rollback plan. Covered above; worth repeating because its absence turns every problem into a crisis.
Your migration checklist
- Inventory: every app, database, dependency, data volume and owner documented.
- Each workload classified (6 Rs) with a named strategy.
- Cloud provider chosen (see our AWS vs Google Cloud comparison) and billing alerts configured.
- Pilot workload migrated, measured and documented.
- Data migration plan with transfer times estimated and tested.
- Cutover strategy per wave (big bang or phased) with rollback plans written.
- DNS TTLs lowered in advance; cutover checklist with a single owner.
- Security groups, access control and backups verified in the new environment.
- Team trained (or vendor contracted) for ongoing operations — migration without operations is just relocation. See our support and AMC guide.
- Post-migration optimisation review scheduled for 30 days after landing.
If your starting point is traditional hosting rather than on-premise servers, our hosting comparison helps you decide whether you need full cloud at all — sometimes a VPS is the right destination.
FAQ
How long does a cloud migration take?
A single application: days to weeks. A small business's full estate: typically 1–3 months including assessment and pilot. The assessment phase is what people skip and what determines whether the estimate holds — budget two to four weeks for it and the rest gets easier. Rushing assessment to "save time" is the most expensive shortcut in the whole migration.
Will there be downtime?
Planned, brief, and scheduled — not accidental. Phased cutovers with parallel running can achieve near-zero downtime for most workloads. The downtime disasters come from big-bang cutovers attempted without a rehearsed plan, which is a choice, not bad luck.
Should we lift-and-shift or refactor?
Lift-and-shift (or light replatforming) for almost everything in a first migration. Refactor only the workloads where cloud-native architecture pays back clearly — usually customer-facing apps with spiky traffic. Refactoring everything is how migrations double in cost and timeline.
Do we need a consultant for this?
For a handful of standard workloads, a competent developer or small agency suffices. Bring in specialist help when there is significant data, compliance requirements, or complex dependencies — and keep the runbook they produce, because operating the cloud afterwards matters more than the migration itself.
Planning a migration? Contact us with your inventory for a phased migration plan and estimate.