You have an agreed target architecture but limited budget and delivery pressure. How do you sequence the move toward it and get real adoption instead of a stalled migration?
answer
- no big bang — stoppable intermediate states
- attach to funded initiatives; thin slice first
- sequence by risk, change frequency, reversibility
- strangler fig + anti-corruption + expand/contract
- count decommissions, not migrations started
basics
~20 sBreak the journey into small steps that each deliver value on their own, attach them to work the business already wants, start with the highest-risk or highest-pain area to prove the approach, and always finish migrations instead of leaving two systems running.
solid answer
~50 sNever plan a big-bang rewrite. Define intermediate states between current and target where each is shippable, valuable and safe to stop at, then sequence them by risk reduction and by riding business initiatives that are already funded — architecture work attached to a launch survives budget review far better than standalone remediation. Prove the approach on a thin end-to-end slice first, so learning is cheap and the pattern is real before you scale it. Use incremental replacement patterns such as strangler-fig routing plus anti-corruption layers, keeping old and new coexisting behind a stable interface. Adoption comes from making the new way the easiest way — golden paths, migration tooling, codemods and hands-on support — not from mandates. Track completion, not starts: half-finished migrations are the dominant failure mode, and each one leaves permanent double cost. Publish progress metrics, name owners, and be willing to formally stop a migration rather than let it linger.
go deeper
Say to do it in small steps that each deliver something useful, and to finish and switch off the old system rather than leaving both running.
Name concrete techniques — strangler fig, branch by abstraction, expand/contract schema changes, parallel run — and the value of proving it on one slice first.
Add sequencing criteria (risk, change frequency, reversibility), attaching work to funded initiatives, migration tooling and support as the adoption lever, and completion metrics with decommission dates.
Treat it as portfolio and governance design: funding policy, review points where the plan can be stopped or re-scoped, outcome-based reporting, organisational incentives that make finishing someone's job, and the discipline to re-derive or abandon the target as strategy moves.
### The problem A target architecture is worthless if the path to it is one enormous project. Large rewrites correlate strongly with failure: they run past the strategic window that justified them, they freeze feature delivery, and they must reproduce years of undocumented behaviour before delivering anything. ### Principle 1 — Intermediate states, each valuable on its own Decompose the journey into states where you can stop indefinitely without being worse off than before. Each step should pay for itself in delivery speed, cost, risk or capability. This turns a bet on a two-year programme into a series of small bets, and it survives leadership changes, because there is no point at which all the value is still in the future. ### Principle 2 — Ride funded business initiatives Architecture work competes with features for one budget. The highest-yield tactic is to attach structural work to initiatives the business already wants: the new market launch pays for the regionalisation seam; the enterprise deal pays for tenant isolation and audit logging. Purely internal remediation programmes are the first thing cut when priorities shift. Keep a small standalone allocation (a fixed percentage of capacity) for work that genuinely has no host initiative, and defend it as a standing policy rather than negotiating it each quarter. ### Principle 3 — Prove it on a thin slice Before scaling a pattern across dozens of teams, take one real, end-to-end but narrow slice through the new architecture — production traffic, real data, real on-call. This surfaces the unglamorous blockers (auth, data migration, observability, deployment, compliance sign-off) while they are still cheap. Choose a slice that is representative but not the most critical path, and treat the result as evidence, not decoration. ### Principle 4 — Sequence by risk and by learning Order candidates by a mix of: - **Risk reduction**: fix what will hurt most, soonest (single points of failure, compliance exposure, capacity cliffs). - **Pain and change frequency**: migrate the components that change most often — they repay decoupling fastest. Migrating a stable, rarely touched component yields little. - **Learning value**: earlier steps that teach you the most about the target. - **Reversibility**: do irreversible steps later, once uncertainty has dropped. ### Principle 5 — Use coexistence patterns - **Strangler fig**: put a routing layer (proxy, gateway, façade) in front of the old system, move capability by capability behind it, and retire the old system when it has nothing left to serve. - **Anti-corruption layer**: translate between the legacy model and the new one so legacy concepts do not leak into the target design. - **Branch by abstraction**: introduce an abstraction over the thing being replaced inside the codebase, then swap implementations behind it, keeping trunk always releasable. - **Parallel run / shadow traffic**: send real traffic to both implementations and compare outputs before switching, converting a risky cutover into a measurable one. - **Expand–contract (parallel change)** for schema and API changes: add the new shape, migrate readers and writers, then remove the old shape. ### Principle 6 — Adoption is a product problem Mandates produce compliance theatre; ease produces adoption. Provide golden paths, scaffolding, automated migration tooling and codemods, migration guides with worked examples, and embedded help (a platform engineer working inside a delivery team for a sprint). Recruit early adopters and publicise their results — peer evidence outperforms architectural authority. ### Principle 7 — Finish, and count finishing The dominant real-world failure is the **half-done migration**: two ways of doing everything, forever, with double the operating cost and a permanent tax on every new engineer. Countermeasures: - Track **completion percentage and decommission dates**, not the number of migrations started. - Make the last mile someone's explicit job, with the old system's shutdown as the definition of done. - Freeze new usage of the old path immediately (the radar's Hold ring), so the tail stops growing. - Publish a visible dashboard of remaining stragglers per team. - Be willing to **formally abandon** a migration and re-standardise on the old choice; an explicit reversal is cheaper than a permanent split. ### Governance and honesty - Record each significant step as a decision record with its business driver and its exit criteria. - Report progress in outcome terms (lead time, incident rate, cost) rather than in components moved. - Set review points where the migration can be stopped, re-scoped or accelerated on evidence. - Expect the target itself to move; re-derive it periodically rather than defending a plan the strategy has outgrown.
- Three teams have migrated to the new platform and eleven have not, and momentum has stalled. What do you do?Find out why empirically — talk to the eleven. Usually the path is missing something (a capability, migration tooling, a compliance sign-off) or there is no funded slot. Fix the blocker, freeze new usage of the old path, provide hands-on migration help and automation, publish remaining work per team with named owners and dates, and if the value no longer justifies it, formally stop and re-standardise rather than sustaining two stacks.
- How do you decide whether a migration should be abandoned rather than finished?Compare the remaining cost to complete against the ongoing cost of running two stacks and the value still expected from the target. If the original driver has disappeared, if the target has been superseded, or if the remaining tail is dominated by systems due for retirement anyway, an explicit, documented reversal is cheaper than indefinite coexistence.
Replacing a bridge while traffic keeps flowing: you build alongside, divert lanes one at a time, and only demolish the old span when nothing is crossing it. Nobody closes the river crossing for two years and hopes.
saying these in an interview costs you the question
- Planning a big-bang rewrite with value delivered only at the end
- Measuring progress by migrations started rather than old systems decommissioned
- Relying on a mandate instead of migration tooling and support
- Migrating stable, rarely changed components first because they are easy
- Leaving old and new stacks coexisting indefinitely with no decommission owner or date
- Funding architecture work only as standalone remediation, with no host business initiative
- Refusing to abandon a migration whose original business driver no longer exists