A Practical Cloud Migration Checklist for Mid-Size Enterprises
Every cloud provider will happily show you a migration diagram with four tidy arrows. Reality is messier, especially for a mid-size company with a decade of accumulated systems: undocumented dependencies, licences that behave differently in the cloud, a database nobody has patched since the person who installed it left. The migrations that go smoothly aren't the ones with the best tooling. They're the ones with the most honest preparation.
What should a cloud migration checklist include?
A cloud migration checklist should cover three phases. Before the move: inventory every system, map dependencies, classify each workload, baseline cost and check licences. During the move: migrate in waves, keep a rollback path and test restores. After cutover: right-size, show teams what they spend, automate, and revisit disaster recovery.
What follows is the working checklist our cloud practice uses, organised around those three phases, because that's where projects are actually won or lost.
Before the move: discovery and decisions
- Inventory everything, then map dependencies. The application list is easy. The surprise is always the connections: the reporting job that reads a database directly, the shared folder three departments quietly rely on.
- Classify each workload: rehost, replatform, refactor, retire, or retain on-premise (see the table below). Resist the urge to refactor everything. Pick your battles.
- Baseline current performance and cost. Without a before picture you can't prove the after, and finance will ask.
- Check licences and compliance early. Some enterprise licences aren't portable to cloud VMs, and regulated industries may have data-residency rules that decide your region on day one.
- Decide your landing zone before the first workload moves: account structure, network layout, identity, tagging standards and guardrails. Retrofitting governance later is far harder.
The dependency map is the project
If we could give one instruction to every migration team, it would be this: the dependency map isn't documentation, it's the project plan. Cut migration waves along dependency boundaries, so tightly coupled systems move together and loosely coupled ones move on their own. Most mid-migration emergencies trace back to a dependency nobody drew.
Rehost, replatform or refactor: which should you choose?
| What it means | Choose it when | |
|---|---|---|
| Rehost | Lift and shift the server as it is | You need out of a data centre fast, or the application is stable and rarely changes |
| Replatform | Small changes, such as moving a database to a managed service | A few targeted changes remove real maintenance work without a rewrite |
| Refactor | Rearchitect the application for the cloud | The application is core to the business and its current design is holding it back |
| Retire | Switch it off | Nobody can name an owner or a user who would miss it |
| Retain | Leave it on-premise for now | Licensing, latency or regulation make moving it more trouble than it's worth |
During the move: execution discipline
- Move a low-risk, representative workload first and treat it as a rehearsal. Validate the runbook, the rollback and the communication plan, not just the technology.
- Keep a rollback path for every wave. Blue-green cutover with continuous data replication costs a little more and removes most of the fear.
- Freeze scope during each wave. Migration is the worst possible moment to also upgrade the application.
- Test restores, not backups. A backup that has never been restored is a hope, not a strategy.
- Tell business users about cutover windows even when you expect zero downtime. Surprises destroy trust faster than outages do.
After cutover: the first 90 days
The migration isn't done at cutover. The first ninety days in the cloud decide whether you get the benefits that justified the project. Cloud bills are shaped by behaviour, and behaviour only changes with visibility and ownership.
- Right-size after four to six weeks of real usage data. Initial sizing is always conservative and usually 30 to 40% over.
- Put cost visibility in front of the teams who create the cost. Tag-based dashboards by product or department change behaviour within weeks.
- Automate what the data centre never let you: patching windows, scaling schedules, shutting down test environments outside business hours.
- Revisit disaster recovery. Cloud makes warm-standby DR affordable for mid-size firms, so take the option your old infrastructure never gave you.
A migration that lands workloads but not operating habits just relocates your problems, at a different monthly price.
— Aptivix Technologies cloud practice
How long does a cloud migration take?
It depends far more on dependencies than on server count. Moving a single application, or your accounts team's Tally, can be done in days. A decade of interlinked systems moves in waves over months. The honest way to estimate is to run the rehearsal wave first: how long it really took, and what it uncovered, tells you more about the rest of the schedule than any upfront plan.
Treat the checklist as a floor, not a ceiling. Every environment adds its own items: a factory with shop-floor systems, a lender with regulator notifications, a retailer with a peak-season freeze. The constant across all of them is sequencing. Honest discovery, disciplined waves and a deliberate first ninety days are what make the cloud deliver what the brochure promised.
Planning a move? Our cloud migration services cover AWS and Azure end to end. If you only need a few business servers run well, managed cloud servers are the quicker route, and if accounting is the first thing to move, start with Tally on Cloud. Once you're there, zero trust security is the right way to lock it down.