Twelve questions about data ownership, integration surface, regulatory drag, and team capacity produce one of three answers — wrap, rebuild, or strangler-pattern — with the failure mode named for each path. Designed to be the artefact a CTO can send their board.

Every CTO eventually inherits a legacy system that everyone says should be rewritten. The codebase is 12-20 years old, the schema has scar tissue, and every consultant who walks past the building offers to rebuild it for €600k and 18 months. The actual decision is rarely as clean as 'rewrite' or 'leave alone' — there are three paths, each with a named failure mode, and the choice depends on twelve concrete questions you can answer in an afternoon.

The three paths

Wrap. Keep the legacy system; expose it through a modern API layer; let new functionality consume the API. The legacy keeps running; the team shifts from editing it to building around it. Failure mode: the two-system tax — every change has to be coordinated across both layers, and the layer that cannot be ignored wins.

Rebuild from scratch. Pick a target architecture, port the data, ship side-by-side, switch over. Failure mode: the rebuild death march — by month nine the team has reproduced 70% of the legacy and the remaining 30% are the parts nobody understands. Most rebuilds either ship significantly later than planned or shed scope until they are no longer the thing the business wanted.

Strangler pattern. Wrap first; rebuild capability by capability behind the wrapper; let the legacy shrink as the new system grows. Failure mode: the strangler that never finishes — the team gets 60% of the way and the remaining 40% is the unloved core nobody volunteers to take on, and you live with two systems forever.

There are three paths, not two. The wrap-vs-rebuild framing is missing the option that ships most often.

The twelve questions

Score each question 0-2 (0 = wrap, 1 = strangler, 2 = rebuild). The score across all twelve gives you a directional answer.

  1. Is the data model fundamentally wrong? If concepts are conflated or relationships are inverted at the schema level, you cannot wrap your way out — the wrapper inherits the lie.
  2. Is the integration surface large? Many downstream consumers means rebuild risk goes up, wrap appeal goes up.
  3. Is the system load-bearing right now? If outages cost the business significant money per hour, prefer wrap or strangler — rebuild risks a long unplanned outage.
  4. Does the team understand the existing code? If institutional knowledge is concentrated in one person who is leaving, rebuild calculations get harder, not easier.
  5. Is there meaningful regulatory drag? Audit trails, certifications, and compliance reviews often anchor to specific code paths. Rebuild means recertifying.
  6. Are external integrations stable? Each external partner you talk to is a coordination cost during cutover.
  7. Can you split the system into clean capability boundaries? If yes, strangler is feasible. If no, you wrap or rebuild — strangler will collapse into one of the others.
  8. Is the desired end state radically different from current? If you want to add real-time, AI, or multi-tenant capabilities the legacy was not built for, wrap will not get you there.
  9. What is your team's appetite for a multi-quarter project? Rebuilds need executive air cover for at least 12-18 months; if leadership turnover is likely, plan around it.
  10. Are you under a vendor migration deadline? Cloud-provider EOL, SaaS-vendor end-of-support — these can force the timeline regardless of what your team prefers.
  11. How clean is the test coverage? Rebuilds without good tests on the legacy are blind rebuilds — every behaviour you forget to replicate becomes a customer-reported bug.
  12. What is the cost of being wrong? Wrap is the lowest-stakes choice. Rebuild is the highest. Strangler is in between but accumulates risk over time.

How to use the score

Total score 0-9: wrap. 10-15: strangler is most likely the right answer. 16+: the legacy is materially in your way; rebuild is on the table. The score is a starting point, not the answer — the questions you scored 0 or 2 with high confidence matter more than the ones you scored 1 because you were unsure.

The artefact this produces — a one-page table of twelve questions, scored, with the recommended path and the named failure mode for it — is the document a CTO should send their board before any of this work starts. Every successful legacy modernisation we have seen had one. Most failed ones did not.

Or skip ahead and talk through it directly