Make the objective explicit
Clarify why change is needed: resilience, deployment speed, capacity, lifecycle risk, or cost transparency. Priorities can conflict, so agree on the order of importance. Define constraints such as data residency, dependencies, and business continuity.
Understand the application estate
Inventory applications, infrastructure, owners, dependencies, and criticality. Current usage and operational effort matter as much as technical age. Missing ownership and undocumented dependencies are migration risks that architecture diagrams alone cannot solve.
Choose per workload
Retaining, retiring, rehosting, replatforming, and refactoring are different decisions. Rehosting may be sensible for a constrained move; refactoring may help a changing product, but adds engineering effort. Compare options against the workload’s actual needs.
Build operations into the design
Identity, observability, backups, recovery testing, network controls, and support ownership belong in the target design. Reliability objectives should inform architecture. Include a rollback plan and evidence of readiness before production transitions.
Make cost accountable
Track costs by workload or accountable team. Review utilization and commercial assumptions, including data transfer and managed-service charges. Optimization is an ongoing operating practice, not a one-time migration milestone.
These are general planning considerations, not a substitute for an assessment of your specific business, regulatory, and technical requirements.
Explore related consulting expertise