Modernization is a pipeline, not a rewrite.

The rewrite that did not happen

Last year a client asked us to scope a full rewrite of a .NET monolith. 87,000 lines. Four engineers. Eight months. Roughly $400,000. The slide deck almost passed the steering committee.

We stopped it in week two. Not because the monolith was healthy — it was not. We stopped it because the rewrite was the wrong instrument, and the second budget cycle would have killed the project before it shipped any value.

What we built instead was a modernization pipeline — three tiers of analysis and change, running continuously against the monolith, retiring it in pieces while it kept earning revenue.

What a pipeline looks like

There are three tiers, and the discipline is to put the cheapest one in front of every change:

1. Static survey. A small local model (3B parameters, runs on a developer laptop) reads every file and produces a structured map: dependencies, dead code, modules that look like seams. Fourteen minutes against 87,000 lines. Cost on the laptop: about $0.60 in compute we did not charge for.
2. Targeted analysis. When the survey flags something interesting, a frontier model gets a scoped, expensive look — one module at a time, with the surrounding context the static pass already prepared. Roughly $47 to analyze 1,200 files in detail. Worth it because the cheap tier already filtered everything else out.
3. Human review. Every PR the pipeline opens lands in front of a person. The pipeline does not push to main. It opens a PR with the diff, the analysis, the migration risk, and the rollback. The engineer decides.

Why this beats the rewrite

The pipeline's first run generated a 47-file PR that would have broken session management for 12,000 active users. We caught it because the human-review tier exists. If we had been six weeks into a parallel rewrite, we would not have known the gap was there until the cutover weekend.

After four months of pipeline runs:

• Eleven modules extracted from the monolith into well-fenced services.
• Nineteen thousand lines of dead code retired — never executed in production, kept "just in case."
• Drift score down 62% against the target architecture, measured weekly.
• Zero big-bang cutovers. The monolith is smaller and cheaper every month, and the lights have stayed on.

The thinking behind it

There is a constraint-theory move here that is worth naming. Goldratt's framing — identify the bottleneck, protect it, optimize everything else around it — applies cleanly. The bottleneck in legacy modernization is almost never engineering throughput. It is the team's ability to ship something operators can trust on Monday morning. A rewrite removes that bottleneck only at the end. A pipeline respects it from the first week.

The other piece is industrial. The PLC / SCADA / MES hierarchy from ISA-95 has a lesson that the software side keeps forgetting: continuous processes outperform batch processes when the cost of a bad batch is high. Rewrites are batch. Modernization pipelines are continuous. The cost of a bad batch in enterprise software is measured in revenue and trust, not story points.

What we tell clients now

If your modernization scope is more than three months and more than 40,000 lines of code, the answer is almost never a rewrite. It is a pipeline. The pipeline is cheaper to start, cheaper to stop, and far cheaper to be wrong about. The rewrite is one decision under uncertainty. The pipeline is forty decisions under increasing certainty.

Modernization is not a project. It is a process you run until you decide to stop — which, if you are doing it right, you never quite do.