Cloud migration readiness: what to assess before moving

Assess the workload as a business service

An application inventory tells you what exists. It does not tell you what must keep working during a move. Start with a business transaction and trace the systems behind it, including authentication, scheduled jobs, reporting and external connections.

Microsoft’s migration guidance covers workload sequencing, dependency groups and tested rollback plans. It is a useful reference for translating a cloud strategy into an execution plan. See Microsoft’s migration planning guidance.

Prepare a readiness record for each migration wave

• Business owner: identify who accepts the migrated service and which business events constrain the schedule.
• Dependency map: record upstream and downstream connections, credentials, batch jobs and network assumptions.
• Data validation: specify reconciliations, sampling rules and ownership of exceptions.
• Recovery: document the decision to stop, the rollback procedure and the people authorised to invoke it.
• Operations: assign monitoring, incident response, backups and access administration after cutover.
• Commercial baseline: include temporary parallel running, licences, transfer costs and ongoing support.

Treat a rehearsal as a decision point

For an illustrative order-reporting workload, checking that the dashboard opens would be insufficient. The rehearsal could compare order totals, late-arriving records, user permissions and overnight refresh behaviour. The business owner should see the results before approving the production move.

Record unresolved findings with owners and dates. “Known issue” is not the same as accepted risk. A cutover meeting should distinguish issues that block release from those that have an agreed workaround and a bounded business impact.

Make the rollback decision concrete

Our recommendation is to write down observable triggers rather than relying on “if something goes wrong”. Examples include a failed reconciliation, an unavailable critical integration or an exceeded service threshold. Agree who makes the call when teams disagree.

Also consider what happens to new transactions created after cutover. Restoring an old environment without a data reconciliation plan can introduce a second problem. The right recovery method depends on the application and should be rehearsed against realistic activity.

Do not confuse migration with modernisation

A move to a new hosting environment does not automatically simplify an application or lower its total cost. Decide explicitly which improvements belong in the initial migration and which need a separate business case.

Finish the readiness review with a written go/no-go record. It should show what was tested, who accepted the result, the outstanding actions and the ownership model after launch. That record becomes the starting point for the next migration wave.