Insights / Checklist / Cloud migration and infrastructure evaluation
ChecklistCloud migration readiness checklist
A cloud migration goes well when you know what you run, what depends on what and what must not break. This checklist covers the groundwork.
Cloud migrations rarely fail because of the cloud. They fail because the organisation did not fully know what it was moving. An application turns out to depend on a file share nobody mentioned. A nightly batch job breaks because it ran on the old server’s clock. A licence does not permit cloud hosting. Each surprise costs time, money and confidence.
A migration goes well when you know what you run, what depends on what and what must not break. Work through this checklist before committing to a migration plan, and keep it current as the work proceeds.
Inventory applications and data
Start with a complete picture. List every application, its owner, data, users and dependencies. Include the small tools and scheduled jobs; they are the ones most often forgotten.
- Every application and service is listed, including scripts, scheduled tasks and file shares.
- Each has a named business owner and a technical owner.
- Users and usage patterns are recorded: how many, where, when and how critical.
- Data held by each application is described, including volume, sensitivity and retention rules.
- Current hosting, operating system, database and version are noted.
- Licence terms have been checked for cloud hosting rights.
Map dependencies
Applications rarely stand alone. They share databases, call each other’s interfaces, read the same files and rely on common services such as authentication and printing. Moving one without its dependencies can break several.
- Interfaces between applications are listed, with direction, frequency and method.
- Shared databases, file locations and network services are identified.
- Latency-sensitive connections are flagged, especially to systems staying on premises.
- External connections to partners, banks, suppliers and customers are recorded.
- Applications are grouped into move groups that must migrate together.
Rate readiness
Not every application belongs in the cloud, at least not yet. Mark each as ready, needs change or not suitable for cloud, and record why.
- Ready: runs on supported platforms, has no blocking dependencies and can move largely as is.
- Needs change: requires an upgrade, re-platforming or redesign before or during the move.
- Not suitable: blocked by regulation, latency, licensing or hardware dependency, or due for retirement.
- Applications nearing end of life are considered for retirement or replacement with SaaS instead.
- Each rating has been reviewed with the business and technical owners.
Agree the order
Sequence matters. Move low-risk systems first to build experience. Early moves teach the team about networking, security, monitoring and cost behaviour in the new environment, without putting critical operations at risk.
- First wave includes low-risk, low-dependency applications such as test environments or internal tools.
- Business-critical systems are scheduled after the team has completed successful early moves.
- Each wave avoids peak business periods, such as month end, seasonal peaks or audits.
- Downtime windows are agreed with business owners in advance.
- A rollback plan exists for every move, with a clear decision point.
Prepare the foundations
Before the first application moves, the landing environment needs to be ready. Gaps here tend to surface at the worst moment, in the middle of a cut-over.
- Identity and access management is designed, including single sign-on and privileged access.
- Network connectivity between cloud and on-premises sites is in place and tested.
- Security controls, logging and monitoring are configured to agreed standards.
- Backup and disaster recovery arrangements are defined and tested.
- Cost tagging, budgets and alerts are set up from day one.
- Operations staff are trained to run and support workloads in the new environment.
Decide what success looks like
Agree the measures that will show whether the migration has worked: cost, performance, availability, recovery time, or the retirement of ageing hardware. Measure the starting point before you move, so the comparison is fair.
Where to begin
Run the inventory first. Even a spreadsheet built in a fortnight with application owners will reveal dependencies, licensing questions and retirement candidates that change the plan. With that in hand, the ratings and migration order follow naturally.
Treat the checklist as a living document rather than a one-off gate. After each migration wave, add what you learned: the dependency you missed, the licence clause that caused a delay, the monitoring gap that showed up on the first weekend. A typical organisation finds that the second and third waves go noticeably faster than the first, largely because these lessons are captured and applied rather than rediscovered. Share the updated checklist with application owners before their systems are scheduled, so they can prepare in good time.
Source: Intelliversal analysis.
