What to Check Before a Cloud Migration

A small business plans to move an internal application from an ageing server. The application itself starts successfully in the new environment. Then a daily export fails, staff cannot retrieve attachments and a supplier stops receiving an expected file.

In this illustrative scenario, the software depended on a local folder, a scheduled task and an account that nobody included in the migration plan. Moving the visible application did not move the whole service.

Start with the work people perform and follow the supporting dependencies. Ask how information arrives, where files are held, which scheduled jobs run and which external systems receive the result.

AWS’s portfolio-discovery guidance connects application dependencies with business criticality. For an SME, the useful deliverable is a concise record of the service and its important relationships.

Combine technical inspection with conversations. Monitoring may reveal network connections, while an employee can explain the monthly process that has not run during the observation period. Neither source alone necessarily provides the complete picture.

The migration plan should describe the service the business needs afterwards, not just the machines it intends to relocate.

The record should help the team decide whether a workload is ready to move and what must happen first. Keep it focused on evidence that changes the plan.

Include the business owner, technical owner, users, operating hours and consequences of interruption. Identify the application components, data stores, file locations and external dependencies. Record how access is granted and which credentials or certificates the service requires.

Then add the migration-specific questions:

Mark unknowns clearly. “To be confirmed” is more useful than an assumption disguised as a completed check, provided it has an owner and a decision deadline.

Pay attention to infrequent work. Month-end reports, periodic imports and renewal tasks may not appear in an ordinary day’s usage. A migration can seem successful until one of those events occurs.

Store the record where both business and technical participants can review it. Its purpose is shared understanding before cutover, not a technical inventory that nobody outside the engineering team can interpret.

Discovery may reveal that some workloads should not move in their current form. An unused application can be retired. A standard capability may be better served by an existing managed product. A fragile component may need repair before relocation.

AWS’s migration-strategy guidance includes several approaches, including retaining, retiring and replacing. Apply the choice at workload level instead of assuming that one strategy suits the entire estate.

Consider the reason for moving. If the business needs a supportable platform, a straightforward relocation may not resolve an unsupported dependency. If the problem is slow data access, the new location may change network behaviour without improving the query itself.

Google’s discussion of cascading failures includes the effects of infrastructure and configuration changes. A migration can alter the conditions under which the application consumes resources, so test the relevant behaviour in the target environment.

Avoid expanding the project into a complete redesign without a clear reason. Separate essential readiness work from improvements that can follow later. This keeps the migration deliverable while addressing the constraints that could make it fail.

Record the selected treatment and its rationale for each workload. That decision will help explain the sequence, estimate and acceptance criteria.

Migration waves should reflect dependencies and business continuity. Moving a component independently may be sensible when it can operate across the temporary boundary. In other cases, several components need to move together.

Identify the temporary arrangement between old and new environments. Which records are written where? How does the application reach a dependency that has not moved? What latency or access assumptions change?

Choose an initial workload that offers useful learning with manageable consequences. It should exercise relevant tooling, access and validation without exposing the business to avoidable risk. A trivial system that shares none of the difficult dependencies may provide little preparation for the next wave.

Plan the timing with the business. Consider customer commitments, reporting periods, supplier availability and staff capacity to validate the result. A technically convenient weekend may be unsuitable if the necessary business owner cannot participate.

Define entry conditions for each wave. Required access, validated backups, resolved dependencies and agreed acceptance should be ready before the cutover starts.

A migration becomes manageable when every wave leaves the business with a service it can use and support.

Make that condition visible in the plan. “Server transferred” is a technical step; “the team can complete the agreed operating tasks” is the milestone the business needs.

Use a representative rehearsal to test the migration procedure, data transfer and validation. Record timings and the points where manual judgement is required.

Decide how changes made during the transfer will be handled. Some services can pause writes for a defined period. Others need a more complex synchronisation approach. The plan should match the actual operating requirement and the tools available.

Reconcile the result. Check important values, relationships and attachments as well as record counts. Validate the tasks people perform, including an exception or correction where it matters.

Write a rollback decision before the live event. State what would cause the team to stop, who can authorise that decision and how the business would return to an acceptable state. Consider transactions created in the new environment before reversal.

Communicate the expected interruption and support route to affected users. Give them a clear way to report a problem after cutover and enough context to distinguish planned changes from failures.

Check security and access in the target environment using the roles people will actually hold. A successful administrator test may conceal permissions that prevent normal users from completing their work.

After cutover, monitor the service through relevant daily and periodic activity. Keep the people who understand the migration available through the agreed validation period.

Confirm ownership of alerts, backups, costs and support. A cloud account does not remove these responsibilities. Document the configuration and the procedure for making future changes.

Resolve the status of the old environment. It may need to remain available temporarily for rollback or records access, but that period should have an owner and an end condition. Retire access, infrastructure and supplier commitments when the necessary checks are complete.

Review actual cost and performance against the planning assumptions. The move may introduce different billing or operating patterns that need attention even when users are satisfied.

A cloud migration engagement should include discovery, transition and the ability to operate the result. The useful outcome is a service whose dependencies are understood and whose new environment supports the work the business intended to preserve or improve.