Building blocks
Design goal
Assign each application a migration strategy with a clear rationale so migration waves reflect business outcomes and application boundaries rather than server inventory alone.
Success criteria
- Classify workloads consistently
- Avoid defaulting every workload to rehost
- Connect strategy decisions to migration waves and business outcomes
Architecture
Use application discovery and business context to select one of seven treatments, then sequence workloads into migration waves.
Architecture flow
- Inventory applications and dependencies
- Assess business and technical drivers
- Select the most suitable migration treatment
- Group workloads into waves
- Validate outcomes after migration
Architecture decisions
Decide per application, not per server
WhyMigration strategy should follow application boundaries and dependencies rather than treating each virtual machine independently.
Trade-offApplication-level decisions align migration with business outcomes, but require dependency mapping and ownership data that take more effort than server-by-server classification.
Retain and retire are valid outcomes
WhyA good assessment can conclude that some workloads should stay where they are or be removed instead of migrated.
Trade-offAvoiding unnecessary migration saves effort and cost, but retained workloads still need an explicit hosting, support, and lifecycle plan.
A stable three-tier application has a fixed migration deadline, limited modernization budget, and no immediate scalability issue. Rehost may be the first treatment to evaluate. If the database can move to a managed service with limited application change, replatform may reduce day-two administration. Record the chosen treatment, evidence, rollback condition, and the trigger for revisiting the decision after migration.
Cost drivers
- Assessment effort
- Migration tooling
- Parallel-run period
- Application remediation
- Data transfer and testing
Design assumptions
- Application owners can provide business context
- Dependencies can be identified before migration waves are finalized
Implementation plan
- Build an application portfolio with owners, business criticality, lifecycle state, dependencies, and current cost—not only a server inventory.
- Assess business drivers and technical constraints for each application, including deadlines, technical debt, licensing, and modernization appetite.
- Assign a 7 Rs treatment with a written rationale and evidence; use “rehost” only when it is actually the best fit, not the default.
- Group applications into migration waves that preserve dependency and business boundaries, and identify prerequisites that must land first.
- Define acceptance, rollback, decommission, and optimization criteria so each treatment has a clear end state after migration.
Validate the design
- Confirm every in-scope application has an owner, migration treatment, target state, and written rationale.
- Verify application dependencies and shared-service prerequisites align with the planned wave order.
- Confirm acceptance, rollback, and decommission criteria are defined before execution.
- Review strategy changes after pilot waves and document why any workload moves to a different treatment.