Cloud migration readiness: a practical checklist before you move

What does cloud migration readiness mean?

Cloud migration readiness is the ability to move a workload while maintaining the business outcomes it supports. A server inventory alone cannot establish readiness: you also need owners, dependencies, access controls, recovery requirements and people who can operate the destination. AWS describes a migration readiness assessment as a way to identify strengths and gaps and develop an action plan. Its guidance is AWS-specific, but the question it raises is useful across providers: what must change before the organisation can operate effectively in the cloud? [1]

This guide provides a suggested assessment process for growing organisations. It is not a claim that every application should move or that migration automatically reduces cost. Treat each checkpoint as a decision supported by evidence, with a named owner responsible for resolving gaps.

1. Start with business services and dependencies

Choose a business service, such as customer onboarding, and trace the applications, databases, file shares, identity systems and external connections behind it. Record how information moves between them. A lightly used application can still be critical if it produces the only daily file that another department needs.

Build a workload register containing a business owner, technical owner, operating system, software support status, data classification, normal and peak demand, and dependent services. Ask users about end-of-month processing and other unusual workloads that a short monitoring window could miss. Record assumptions explicitly so they can be tested during the pilot.

• Which systems must remain reachable during a connectivity outage?
• Are there fixed IP allowlists, hardware dependencies or licence restrictions?
• Who can authorise a cutover and verify that business transactions still work?

2. Choose a strategy for each workload

AWS groups migration approaches into seven strategies: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. These are planning categories rather than a universal sequence. Rehosting moves an application with relatively limited changes; replatforming introduces targeted platform changes; refactoring changes the application architecture more substantially. [2]

For your own decision register, document why a strategy fits the workload. An obsolete report may be retired after its owner confirms there is no retention or operational dependency. A specialist application may remain where it is while an unsupported integration is replaced. For a customer portal, a managed database might be worth evaluating, but compatibility and recovery behaviour should be demonstrated before committing.

3. Define security and recovery before provisioning

Prepare an access matrix that separates everyday work from administrative tasks. Identify which identities belong to people and which belong to services. For each integration, specify the minimum permissions needed and the process for rotating credentials. Make logging, backup access and emergency access part of the initial design rather than a later housekeeping task.

Ask business owners to agree two separate targets: how long a service can be unavailable, and how much recent data the business could tolerate losing. Those targets should inform architecture and backup choices. Test a recovery path with representative data and record the actual time achieved. A backup job reporting success does not by itself demonstrate that the complete business service can be restored.

4. Compare the full operating cost

Create a cost model with normal, peak and growth scenarios. Include compute, storage, backups, network transfer, monitoring, software licences, support and the internal effort needed to operate the service. Keep one-off migration spending separate from recurring costs so that the business can understand both the transition budget and the steady-state bill.

Assign ownership of each budget and define what should happen when a forecast is exceeded. A useful pilot measures cost per business unit, such as a completed order or active customer, alongside the monthly total. This helps distinguish healthy growth from waste. Do not commit to a savings percentage until the baseline and destination measurements support it.

5. Pilot, rehearse and hand over

Choose a pilot that is bounded but representative: it should exercise identity, networking, data movement, monitoring and support. Write pass criteria before testing. Include a normal user journey, a failed external dependency, a restore test, a peak-load scenario and a request from an unauthorised account.

For cutover, specify the last safe rollback point, who makes that decision, how data written after migration will be reconciled, and how users will receive updates. A rollback that restores servers but discards new orders is not a complete rollback plan. After launch, hold an operational acceptance review covering alerts, runbooks, escalation contacts, ownership and measured costs.

Your readiness decision

Use three outcomes for each checkpoint: ready with evidence, ready subject to a named action, or not ready. Avoid averaging away a critical issue: an unresolved data dependency or untested recovery process deserves its own decision. This produces a roadmap that is easier to defend than a single overall readiness score.

Evo’s Cloud Solutions service covers design, migration, governance and optimisation. Bring your workload register and business constraints to an assessment; the next step is to turn them into a prioritised migration plan with clear acceptance criteria. Where connectivity is a constraint, involve Network Infrastructure planning before choosing the migration window.

Frequently asked questions