Years ago I worked on a system with an unusual shape. A VB6 core, wrapped in a C# layer, exposed to the world through a PHP front end. I maintained it and extended it. I did not migrate it, and I want to be accurate about that, because the interesting part of this piece is a proposal rather than a delivery.
The proposal was to move the PHP front end to MVC, endpoint by endpoint. A pass-through layer sitting in front, rendering the existing PHP resources through the new stack, so that endpoints could be moved across one at a time while everything stayed live. Server-side rendered, so a shared session layer between old and new. A strangler, in other words, and a fairly textbook one.
MVC has moved on and the specifics are dated. The reasoning is not, and it is worth re-examining now that the economics underneath it have changed.
What the strangler was actually buying
Look at that plan and count what is load-bearing.
The pass-through layer: scaffolding. Built to be deleted.
The shared session layer: scaffolding. Built to be deleted, and the fiddliest part of the job, because session state across two stacks is where the subtle bugs live.
The endpoint-by-endpoint sequencing: not scaffolding. That is the actual method.
So a substantial share of the effort in that proposal existed only to make incrementalism possible. None of it was the replacement system. It was the apparatus for arriving at the replacement system slowly.
That apparatus was worth building because writing the new endpoints was the expensive part, and anything that let the business fund it in slices was worth a large overhead. The overhead looked small next to the thing it was enabling.
What changed
If generating the replacement is now substantially cheaper, that ratio inverts. The scaffolding does not get cheaper at the same rate, because it is integration work against a specific pair of systems and their specific session model. The new endpoints get much cheaper. The apparatus stays roughly as expensive as it always was.
At which point the scaffolding is no longer a small tax on a large project. On a small enough system it can approach the cost of the replacement itself, and you are paying a significant premium for incrementalism rather than a marginal one.
That is a real argument for the big bang, and it is the argument I would expect to hear from a vendor. It is also only half the picture.
What the strangler was really for
The pattern was never primarily about affording the work. It was about surviving being wrong.
Endpoint by endpoint means every step has a rollback that takes minutes. It means the blast radius of a mistake is one endpoint, discovered by the users of that endpoint, fixed before the next one moves. It means you learn the shape of the problem on the endpoints that do not matter much before you touch the ones that do.
Cheap code generation does not improve any of that. The probability of being wrong is a function of how well the old behaviour was understood, and the old behaviour is undocumented, which is the entire reason the system is being replaced. If anything, generation makes it worse, because a generated replacement is plausible everywhere. A human rewriting an endpoint hits the part they do not understand and stops. A model does not stop. It produces something reasonable and moves on, and the place where it guessed looks exactly like the places where it did not.
So the two halves move in opposite directions. Incremental migration got relatively more expensive. It also got more valuable, because the failure mode it protects against became more likely.
Where I would actually land
The honest answer is that it depends on a variable most of these discussions skip: whether anyone can tell if the new system is wrong.
If the system has strong observable outputs, transactions you can compare, numbers you can reconcile, then a faster cutover is defensible, because you will find out quickly. The strangler's rollback path is less valuable when your detection is good.
If the system's correctness is mostly invisible until someone complains, and that is most internal business software, then incrementalism is buying you detection, not just rollback. You are migrating in slices small enough that a regression is attributable. Big bang on a system with weak observability means every defect for the next six months is a candidate for having been caused by the migration, and nobody can prove otherwise.
Framed that way, I would spend the money I saved on generation buying observability before I spent it going faster. Comparison harnesses, output reconciliation, logging on the paths nobody understands. That budget did not previously exist. Now it might.
The uncomfortable version
There is a reading of this I cannot dismiss, which is that a proportion of what the industry built into migration practice was a response to labour cost rather than to risk, and we have been telling ourselves a risk story about it for twenty years because that sounded better.
If that is true, then some of these patterns will quietly stop being used, the way a lot of careful pre-planning stopped being used when compilation got fast, and nobody will write the post-mortem because nothing will visibly break.
I do not think the strangler is in that category. Its core is a rollback and detection mechanism, and that has nothing to do with typing speed. But the specific apparatus I proposed all those years ago, the pass-through, the shared session, the elaborate machinery for running two stacks at once, some of that was a response to expensive labour, and I would think harder before building it again.
If you are weighing a migration approach and the vendor is pushing a faster cutover than you are comfortable with, I am happy to talk it through.
