Legacy Software Glossary

Plain-English definitions of the terms that come up in legacy-software rescue engagements. Written for business owners, not developers.

If a term you were looking for isn’t here, tell us and we’ll add it. See also our field notes for longer-form pieces on rescue, modernization, and the decision framework behind each.

Legacy technologies

Legacy software: Software that is no longer under active development by its original vendor or team, but is still in production use and important to a business operation.

Legacy is defined by ownership state (nobody maintains it), not by age. A 1998 FoxPro system with an active support engagement is not legacy; a 2020 React app whose original team disbanded and left no documentation is.
.NET Framework: Microsoft's Windows-only application framework, first released in 2002 and superseded by .NET Core / .NET 5+ starting in 2016.

The Framework is still supported for existing applications but does not receive new features. Most business applications built between 2003 and 2016 run on it. Common versions include .NET Framework 4.0, 4.5, 4.6, 4.7, and 4.8.
ASP.NET WebForms: A server-side web-application framework built on .NET Framework, released in 2002.

WebForms uses server-side controls, view-state serialization, and a stateful-page abstraction that made it easy to build data-heavy line-of-business applications. It is no longer receiving new features; migration paths are Blazor or ASP.NET Core MVC.
Classic ASP: Microsoft's original server-side scripting technology, released in 1996 and superseded by ASP.NET in 2002.

Classic ASP uses VBScript or JScript to generate HTML on the server. Thousands of business applications still run on Classic ASP; migration requires manual code translation, not tooling.
Visual Basic 6 (VB6): Microsoft's Windows desktop programming language, released in 1998. Support for the runtime continues on modern Windows through 2029 (extended).

VB6 was the dominant business-desktop language of its era; typical usage today is inventory management, warehouse scanning, and manufacturing floor tools.
Visual FoxPro (VFP): Microsoft's integrated database + programming environment, discontinued in 2007. The runtime still works on Windows 10 and 11.

FoxPro is common in warehouse management, distribution, and industry-specific vertical applications from the 1990s and 2000s.
WinForms: The desktop UI framework for .NET Framework, released in 2002.

WinForms applications are Windows-only desktop programs, typically used for internal line-of-business tools. Migration paths for continued development are .NET 8+ WinForms (still supported) or a full rewrite to WPF, Blazor, or a web platform.
WPF (Windows Presentation Foundation): Microsoft's XAML-based desktop UI framework, released 2006.

Still supported on modern .NET but not receiving new investment. Common in engineering and industrial control applications.
dBase / Clipper: Database and programming languages from the 1980s.

Still occasionally found in production at niche industrial and government installations. Rescue engagements typically involve extracting the data and repurposing the business logic in a modern stack while leaving the reporting layer intact.
Microsoft Access with VBA: The desktop database product from Microsoft Office, with Visual Basic for Applications macros.

Access + VBA is the archetypal “grew accidentally into critical business software” pattern. Rescue engagements typically split the application into a modern data layer (SQL Server or PostgreSQL) and a modern UI (web or WinForms), leaving the VBA business logic to be gradually translated.

Engineering concepts

Code archaeology: The systematic reading and documentation of undocumented legacy code before modifying it.

Code archaeology identifies implicit couplings, embedded business rules, and areas of implicit state that would be lost if the code were rewritten from scratch. A rescue engagement is fundamentally a code archaeology engagement with subsequent targeted work.
Rescue (in the context of legacy software): An engagement to read, document, and repair a legacy system in place, as an alternative to a full rewrite.

A rescue produces a written assessment first, then targeted repairs or incremental modernization, then optional ongoing support. Rescues are typically 4-10x cheaper than rewrites for equivalent outcomes.
Rewrite: A project to build new software that replaces an existing system, typically on a different technology stack.

Rewrites are the correct answer in specific circumstances but fail at very high rates when applied to systems whose business logic is not fully documented. See our rescue vs rewrite decision framework.
Modernization (incremental): The phased upgrading of a legacy system's technology stack while preserving business logic.

Incremental modernization keeps the old system running while new modules are built and old modules retired, typically over 12-36 months. Modernization is the correct answer for large legacy systems that cannot be rescued in a single engagement and cannot be rewritten in a single project.
Strangler pattern: An incremental modernization pattern where a new system gradually takes over functionality from an old system, module by module, until the old system can be retired.

Named by Martin Fowler after strangler-fig trees. The strangler pattern is the operational tactic for most large-system modernizations.
Big-bang rewrite: A project to completely replace a legacy system with a new one, ideally over a single cutover event.

Big-bang rewrites fail at high rates — the well-known industry figure is 40-70% never-shipped or shipped-broken. Preferred alternative for large systems is the strangler pattern.
Technical debt: The accumulated cost of past decisions that made short-term progress cheaper but long-term change more expensive.

Legacy systems accumulate technical debt in undocumented business logic, workarounds for defects that were never fixed, and inconsistent naming conventions. Rescues typically pay down the specific technical debt causing operational pain, not all of it.
Business logic: The rules encoded in software that reflect how the business actually operates: who can order what, at what discount, on what payment terms, subject to what compliance constraints.

Business logic in legacy systems is often not documented anywhere except the code itself. Losing the developer who knows the business logic is the single largest risk in legacy operations.

Business terms

Vendor lock-in: The state where a business depends on a specific software vendor to the point that switching would be prohibitively expensive or risky.

Legacy software rescue can either resolve vendor lock-in (by making the code portable) or perpetuate it (by making the current vendor essential); the choice is a strategic decision the assessment surfaces.
Source escrow: A legal arrangement where a software vendor deposits source code with a third party, releasable to the customer if the vendor goes out of business or stops supporting the product.

Escrow is a partial protection against vendor disappearance; it does not solve the documentation problem or the “we still need someone who can read this code” problem.
Vendor disappearance: The event where a software vendor becomes unreachable — bankruptcy, dissolution, or simply the original developer leaving with no handover.

See What to Do When Your Software Vendor Disappears.
Failed migration: A partial or complete replacement of a legacy system that did not deliver what was promised.

Either the new system does not work, or it works but at higher cost than the old system, or it never shipped. Failed migrations are common — approximately 40-70% of major-system rewrites fail. See the $180K failed migration rescue case study for a worked example.
Regression: A defect introduced into previously-working software by a change unrelated to the defect.

Legacy systems produce regressions at high rates because their internal coupling is undocumented; changes in one module surface unexpected behavior in another. High regression rates are one of the five warning signs of imminent system failure.
Assessment (in the context of legacy software): A 2-6 week engagement to read the code, document the business logic, and produce a written report on the state of a legacy system.

Deliverables typically include: architecture overview, identified failure modes, prioritized recommendation (rescue / rewrite / hybrid), and cost estimates for each option. An assessment costs a fraction of either rescue or rewrite and eliminates guessing.
End-of-life (EOL): The date at which a software vendor stops issuing security patches and updates for a product.

.NET Framework 4.8 is currently supported but no longer receiving new features; Windows Server 2012 R2 reached EOL in 2023; SQL Server 2014 reached EOL in 2024. EOL is a risk signal, not immediate failure — a system on an EOL platform continues to work, but the risk of unpatchable vulnerabilities accumulates.

Stuck on a legacy system?

Schedule a free 30-minute consultation. We’ll listen first, then propose only what makes sense for your situation.

Schedule Free Consultation