Somewhere right now, an engineering team is eight months into a "6-month rewrite." Nobody planned it that way. Here is what nobody told them before they started – and what to ask before your team becomes the next story.

1. The Question Nobody Asks in the Boardroom

Every CTO has heard the pitch for a full rewrite. Clean slate. Modern stack. No more duct tape. It sounds like control. So here is the uncomfortable question worth sitting with for a second: what if the rewrite is actually the riskiest decision on the table, not the safest one?

Because here is what almost never gets said out loud in that first planning meeting: a full rewrite means running two systems side by side, for months, sometimes years, while the business keeps moving underneath both of them. And somewhere in that overlap, three things quietly start going wrong.

·       Scope creep nobody signed off on, because "clean slate" always invites a few more ideas.

·       Timelines built on the assumption that nothing unexpected will be discovered mid-project. Something always is.

·       Dependencies that only reveal themselves the moment someone finally touches the code nobody has opened in years.

None of this shows up in the project plan. It shows up eight months in, when the "6-month rewrite" is still running, the old system is still handling a meaningful share of production traffic, and nobody quite remembers why a bug fix in the new system just broke a report the finance team depends on every Monday.

2. What If There's a Third Option Nobody Mentioned?

Rewrite everything, or live with what you have. That is usually how the choice gets framed. But there is a third path that quietly has the highest success rate of the three, and almost nobody outside engineering circles has heard of it by name: the strangler fig pattern, paired with AI.

The idea itself is almost deceptively simple. Instead of replacing everything at once, you replace one piece at a time, behind a stable interface, and you validate each piece in production before touching the next one. No single cutover date the entire business bets on. Azure's own architecture guidance already treats this as the default incremental migration pattern – which raises the question: if it is the default for the platforms with the most at stake, why is "big bang" still the first instinct in the boardroom?

Here is where it gets genuinely interesting. Four tasks that used to eat most of a modernization timeline are now something AI does alongside the engineering team:

·       Dependency mapping – AI scans the entire codebase and surfaces relationships between modules faster than any human tracing imports by hand.

·       Business logic extraction – AI reconstructs rules that were never written down anywhere, by reading procedures and edge cases straight from the legacy code.

·       Component translation – AI converts code between frameworks, producing idiomatic target code instead of a rigid, literal port.

·       Test generation – AI builds test suites that compare old and new behavior side by side, catching regressions before anyone ships.

But here is the catch that most breathless "AI will modernize everything" takes conveniently skip: none of this works if the AI output is trusted blindly. Deterministic analysis – dependency graphs, call-site maps, static analysis – runs in parallel with the AI layer. Every change gets logged: model version, the exact prompt, the human who signed off on it. That audit trail is the difference between "AI helped writet his" and something a due diligence process can actually stand behind.

Where this doesn't work as cleanly:

Tightly coupled database schemas where a "module boundary" barely exists, regulated environments requiring full re-certification before any production change, and codebases with zero existing test coverage – AI-generated tests still need a human baseline to validate against. If your system falls into one of these buckets, the sequencing above still applies, but expect the discovery phase to take longer, and expect more human review per AI-generated change, not less.

3. A Migration That Avoided the Rewrite Trap

Here is the pattern in practice, drawn from a production Angular platform that had two rewrite attempts shelved internally – once over timeline risk, once because nobody could confidently say what a meaningful share of the codebase actually did anymore.

What the team did instead:

1.     Introduced a React "bridge" inside the existing Angular shell – new features shipped in React from day one, without touching the legacy runtime at all.

2.     Replaced modules gradually, starting with the most isolated, highest-friction components – not the flashiest ones, and never the monolith's core.

3.     Let AI run across the entire migration loop: mapping dependencies before a single line was touched, translating components while preserving business logic, and generating tests that compared old and new behavior side by side.

What changed as a result: no roadmap freeze, no big-bang cutover date, and – the part that matters most to an engineering lead – a modernization program the team could explain module by module, to a board, an auditor, or a new hire, without anyone having to trust a black box.

4. The Cycle That Repeats Every Single Week

Here is the part that surprises most people who hear this story for the first time: it is not a one-time trick. It is a repeatable weekly cadence, running module by module, that scales to almost any legacy system.

Four phases, one week each, repeated per module: discovery and dependency mapping, core logic migration, integration and refactor, testing and validation. Which raises the real question worth asking: if one module can run this cycle independently, what happens when ten modules run it in parallel? That is the actual mechanism behind "near-zero disruption" – no single big release the whole business waits on, and a delay in one module never blocks the others.

5. So Which Path Is Actually Safer?

Numbers tend to cut through the boardroom debate faster than opinions do. Here is how the two approaches compare across the dimensions that actually matter once a project is underway, not just on the pitch slide.

The strangler-plus-AI approach scores highest on rollback safety and audit traceability – the two dimensions that determine whether a modernization program survives contact with a security review, a compliance audit, or a board update after something goes wrong. A full rewrite scores lowest on exactly those two.

(Scores are a directional synthesis of the patterns described in the sources below, not a formal benchmark study – treat them as a framework for the conversation, not a precise measurement.)

The gap is not subtle. And it raises a fair follow-up question for any team currently leaning toward a full rewrite: which of these five dimensions is the one you are most willing to bet the project on?

6. Three Questions Worth Asking Before the Next Meeting

Question 1 · Where is the risk actually concentrated?

Not "is the codebase old" – every legacy system is old. The real question: which 20% of the system carries 80% of the undocumented business logic, and is that the exact 20% the rewrite plan is treating as trivial?

Question 2 · What is the engineering team saying when nobody senior is in the room?

Concerns about lost control, unrealistic timelines, and hidden dependencies almost always surface early – usually to a manager, rarely all the way up the chain. If those concerns have already been raised, has the plan actually accounted for them?

Question 3 · What would the first strangled module even look like?

If nobody in the room can name a single, well-isolated component that could be replaced first, safely, in production, that silence is itself the answer. Either the system is more tangled than anyone assumed, or the plan has not been scoped down to the module level yet.

――――――――――――――――――――

A Note from the Author

Miłosz Cupiał · Head of Delivery

Almost every conversation we have with CTOs across DACH starts with some version of the same question: rewrite, or refactor? The honest answer is almost never "rewrite." But it is also almost never "just refactor and hope." The interesting answer, the one most teams haven't fully explored yet, is a sequenced, AI-assisted strangler pattern – with the audit trail to prove it holds up when it matters.

If a legacy platform is somewhere on your roadmap for the next 6-12 months, or that rewrite conversation is already happening internally, here's a concrete next step: a 30-minute technical walkthrough where we map your system against the framework above – no deck, no pitch, just a second opinion on where the real risk sits.

Book a 30-minute technical review· milosz.cupial@altimi.com

‍