That description hides the real decision.
Migration is not a change of location. It is a set of choices about business capability, architecture, data, security, resilience, cost, and operating ownership. Some systems should move. Some should be retired. Some should be replaced. Some should stay where they are until a better business case exists.
Enterprise architecture gives cloud migration its decision logic.
Not Every Workload Has the Same Future
The first mistake in cloud migration is treating all workloads as candidates for movement.
They are not.
A legacy system with low business value may need retirement, not hosting change. A critical customer platform may need redesign before migration. A commodity application may be better replaced with a software service. A data-heavy application may need careful architecture before any move. A stable regulated workload may need a slower path.
Enterprise architecture helps classify these choices.
The common migration options are familiar: retain, retire, rehost, replatform, refactor, repurchase, or replace. The value is not in naming the categories. The value is in applying them with evidence.
The Evidence Needed
A good migration decision should consider:
- Business criticality.
- Capability supported.
- Technical health.
- Data sensitivity.
- Integration complexity.
- Security and compliance requirements.
- Resilience needs.
- Cost profile.
- Vendor dependency.
- Service ownership.
- Change timing.
Without this evidence, migration becomes a technical exercise. The organization moves systems but keeps old problems.
That is how cloud programs create cost without reducing complexity.
Architecture Prevents Lift-and-Shift Regret
Rehosting can be useful. It may reduce data center dependency, speed exit from infrastructure, or buy time for later redesign.
But rehosting is not modernization by itself.
If an application is poorly integrated, poorly documented, expensive to operate, and weakly owned, moving it to cloud will not fix those issues. It may simply make them harder to see.
Architecture helps leaders decide when a quick move is acceptable and when redesign is required.
Risk and Control
Cloud migration also changes control obligations.
Data may move across boundaries. Identity models may change. Logging may need redesign. Backup and recovery may work differently. Operational support may shift. Supplier risk may increase. Cost may become more variable.
These issues should be designed into the migration path.
Security, data governance, compliance, service management, and finance should not appear after the migration plan is already set. They should help shape the target state.
Practical Recommendations
Start with a workload portfolio assessment.
Map each workload to the capability it supports. Identify dependencies. Classify data. Assess technical health. Estimate cost. Identify risk. Assign an owner. Recommend disposition.
Then sequence migration based on value and readiness.
Do not migrate the easiest systems only because they are easy. Do not migrate the hardest systems first only because they are visible. Sequence should reflect business priority, risk, dependency, and organizational capacity.
Architecture should also define standard landing zones, integration patterns, security controls, observability, resilience tiers, and cost management practices.
These standards reduce rework and improve governance.
The Closing Test
For each workload, ask:
What business capability does it support, what future does it deserve, and what migration path improves the enterprise?
If the answer is only, "Move it to cloud," the architecture work is not done.