Key takeaway
Identify workload and data owners, dependencies and success criteria first. Test migration and rollback with a low-risk pilot; schedule critical systems in waves only after validation.
Choose a strategy for each workload
One strategy does not fit every application. Consider business value, technical debt, compliance needs, change risk and expected operating cost. Some systems can move, modernize, be replaced or remain where they are.
Rehost · move with minimal changes
Move the application largely unchanged. It can be a first step under time pressure, but legacy architecture and operational issues may move with it.
Replatform · make targeted changes
Replace selected components with managed services or adjust configuration to gain benefits without fully rewriting the application architecture.
Refactor · redesign
Change the application code and architecture substantially to use cloud services. This takes more effort and risk, so choose it for suitable workloads with a clear objective.
Repurchase, retain or retire
Replace the application with SaaS, retain it where it is, or retire it if no longer needed. Record why a workload stays and when that decision should be reviewed.
Move from discovery to migration
Migration is a change program coordinating dependent systems, not a single technical operation. Assign owners and measurable decision points between stages.
Inventory and dependencies
Inventory applications, servers, databases, data flows, users, integrations and licenses. Identify components that must move together and name each system owner.
Goals and target environment
Agree on the business objective, acceptable downtime, data location and compliance needs, target architecture and success measures. These decisions shape security, network, identity and cost plans.
Pilot and cutover plan
Exercise tools and procedures on a low-risk workload. Document data replication, application tests, DNS and traffic cutover, user checks and rollback conditions in advance.
Waves, validation and optimization
Move related systems in agreed waves, checking application behavior, data integrity, security controls and cost after each one. Decommission the old environment only after owner approval and retention requirements are checked.
Choose tools by their purpose
Choose tools based on your estate, source platform, target service, scale and licensing needs. Tools can address different tasks such as assessment, server replication or application analysis; one tool does not replace a full migration plan.
AWS Transform MGN
A replication and migration service for rehosting physical, virtual and cloud servers to AWS. Source inventory, application dependencies and cutover tests still need separate planning.
Azure Migrate
A hub for discovery, assessment and migration tools for Azure. Assessments can analyze readiness, target sizing and estimated cost; their results do not replace project-specific validation.
Google Cloud Migrate to Virtual Machines
Google Cloud Migrate to Virtual Machines supports moving VMs from on-premises and cloud sources to Compute Engine, with replication, test clones and cutover. Check source support and compatibility for your environment.
Red Hat Migration Toolkit for Applications
Analyzes application code, APIs and technologies to help plan modernization and migration. It is not a server replication tool; it focuses on application readiness.
Validate security, rollback and outcomes
Review identity, data and workload controls during and after migration. Establish the responsibility boundary for each target service; do not assume a migration tool provides ongoing monitoring, secure configuration or compliance approval.
Downtime and rollback
Define the downtime window, final sync, failed-cutover criteria and steps to return to the source system. Plan how to preserve data written in the target after cutover; it may not replicate back automatically. Test rollback during the pilot.
Data integrity and compliance
Check data classes, retention and location requirements, encryption in transit and access. Review accounts and temporary copies after migration.
Operational and cost measures
Compare application latency, error rate, availability, backup recovery, resource utilization and monthly cost. Update scaling and cost assumptions against actual use.