1. Start with a workload inventory
For each application, record the business owner, purpose, users, current hosting, data stores and supporting services. Include scheduled jobs, file transfers, identity systems and integrations that may not be visible in an architecture diagram.
Map dependencies before grouping applications into migration waves. Moving an application without a service it relies on can change latency, connectivity or authentication. Google Cloud’s planning guidance begins with workload discovery, dependency mapping and a suitable cloud foundation. Read the migration-planning overview.
A practical inventory row contains: workload name; business and technical owners; dependencies; data size; busiest usage periods; recovery needs; proposed destination; and unresolved questions. Mark estimates as estimates so they are not mistaken for measured facts.
2. Choose an approach for each workload
A cloud programme does not require the same treatment for every application. AWS describes seven migration strategies, including retaining, retiring, rehosting, replatforming and refactoring a workload. Review AWS’s migration strategies.
- Move with limited application change
- Consider when the immediate goal is changing the hosting environment. Identify compatibility checks and the operational work that still remains after the move.
- Adopt a different managed platform
- Consider when it addresses a specific operating problem. Check runtime, database, licensing and service limitations before committing.
- Change the application architecture
- Consider when there is a clear business reason for the extra development and testing. Separate essential migration work from optional redesign.
- Retain, replace or retire
- Keep these choices visible. A system with little remaining value or a difficult dependency may not justify immediate migration.
Write down the reason for each decision and the information that could change it. This makes later scope changes easier to evaluate.
3. Agree interruption and data-recovery limits
Ask the business owner how long the workflow can be unavailable and how much recent data loss is acceptable. These are different questions. Record the agreed recovery time objective and recovery point objective, then check whether the proposed migration and recovery method can meet them.
Specify how data will be copied, whether ongoing writes need replication or a controlled pause, and how completeness will be checked. Microsoft’s migration-planning guidance covers data transfer choices, migration sequencing and workload preparation. Read the Azure migration-planning guidance.
A useful decision to make early
If users create new records after cutover, how would those records be handled during a return to the old system? Agree a reconciliation or recovery method before accepting “we can switch back” as a plan.
4. Budget for the complete operating environment
Compare options with the same workload and availability assumptions. Include production and non-production compute, storage growth, backups, network transfer, licences and the people needed to operate the system. Document the pricing assumptions and keep one-time migration work separate from recurring costs.
Assign owners for identity, access reviews, patching, monitoring and restores. Define useful alerts and the person expected to act on each one. A dashboard without an operational response is an incomplete handover.
Choose a small, representative first wave. Record what the rehearsal teaches you about transfer time, missing dependencies and the support effort before planning subsequent waves.
5. Turn the plan into a cutover checklist
Use named owners and observable checks. A task such as “test the application” is less useful than “the business owner completes the agreed order-entry and reporting scenarios on the target environment.”
- Source data and configuration backups are available, with the relevant restore steps tested.
- Target connectivity, access permissions and application dependencies are verified.
- Data completeness and critical business workflows pass agreed checks.
- The change window, communication plan and go/no-go owner are confirmed.
- Recovery triggers and handling of post-cutover writes are documented.
- Monitoring, cost review and post-migration support ownership are in place.
Keep the old environment until the agreed acceptance and retention conditions are satisfied. Decommission it deliberately, including access, data and recurring charges. The end of a data copy is not, by itself, the end of a migration.