Insights

Field notes on rescuing legacy software. Not opinion pieces — each post documents a specific pattern we’ve seen across 500+ engagements, with the actual decisions and trade-offs behind the outcome.

Most writing about legacy software is either dismissive ("just rewrite it") or academic (patterns and taxonomies with no operational advice). Neither helps a business owner staring at a system that runs the company, has nobody left who understands it, and is about to break. These field notes are for that owner.

The technologies we work with the most — .NET Framework with WebForms or WinForms, Classic ASP with VBScript, Visual Basic 6, Visual FoxPro, Microsoft Access with heavy VBA, and older-still stacks — are called "legacy" not because they stopped working, but because most developers stopped reading them. That reading gap is what turns "we have some software" into "we cannot change anything anymore." Every post here addresses one facet of closing that gap.

New posts publish every 3–6 weeks. If you’re looking for something specific — a technology, a failure mode, a decision framework — and it isn’t here yet, tell us what you’re facing and we’ll write about it next.