> I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply a

> I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply an evolution of business. Old businesses die and young businesses take their place with more efficient technology. The worst part is that a clean, entire rewrite isn't necessary: while everyone's familiar with a gradual refactor (module-by-module), fewer people seem to be aware of how better a proxied gradual rewrite is: where a single module/area in the old system is rewritten in the new system, but the old system's exposed interfaces remain the same and simply proxy or pass-through to the new system (to support existing clients and use-cases) while new clients can access the new system directly. It's an approach I used for a rewrite of an old ASP.NET WebForms application to ASP.NET Core (famously the two are very incompatible: old WebForms *.aspx markup and stateful Page classes (don't forget `__VIEWSTATE`!) simply cannot even be refactored to work in ASP.NET Core: the only way forward is a total rewrite: but when an old .aspx is replaced, there's an `IHttpHandler` that takes its place and proxies the request to the new ASP.NET Core system and end-users are none-the-wiser (and by "proxy" I don't necessarily mean like a HTTP reverse-proxy - 90% of the time the new .NET Core code was running in-proc and invoked as a normal library reference because it targeted .NET Standard and so ran on .NET Framework 4.x instead of only the .NET Core runtime). Now I know I can't compare a line-of-business web-application to a billion-dollar IBM-powered banking/insurance/public-sector - but I believe the same principles apply. Provided the original application _can_ be decoupled internally (thus to allow that proxying in the first place), then a gradual in-situ rewrite should be doable.