Transformation programs often begin with a single mandate: move to the cloud, refactor the monolith, replace the mainframe, or adopt a new platform. The mandate can create momentum, but it can also hide the fact that different parts of the estate deserve different answers.
Start with disposition, not destination
For each functional domain, ask whether it should be retained, remediated, encapsulated, rehosted, replatformed, refactored, rearchitected, rebuilt, replaced, or retired. The answer should reflect business value, change frequency, operational risk, technical health, dependencies, available products, and the organization’s capacity to absorb change.
Use the same decision dimensions everywhere
- Business differentiation: does the capability create advantage, or is it commodity?
- Change pressure: how often must behavior change, and how costly is change today?
- Risk concentration: what would failure, incorrect behavior, or unavailable expertise cost?
- Coupling: how deeply is the domain entangled with data, jobs, interfaces, and other capabilities?
- Replacement fit: can a product meet the actual business rules without recreating the legacy system inside configuration?
The roadmap is a dependency argument
A roadmap should explain why one wave precedes another. Early work may isolate interfaces, improve observability, extract shared data, or stabilize tests before a visible business capability moves. Those enabling steps are not overhead when they reduce uncertainty for every later wave.
Prefer reversible commitments early
The earliest phases should improve knowledge and optionality. A business-rule inventory, dependency map, domain model, and executable validation baseline create value across multiple target architectures. They allow leadership to delay irreversible choices until the evidence is stronger.