What makes a working system become legacy software

Old software can remain healthy software

A 20-year-old mainframe billing system can be a healthier modernization candidate than a three-year-old microservice. If the mainframe remains supported, its code is documented, and continuous integration and delivery (CI/CD) work, engineers can still change it with confidence. The younger service can already qualify as legacy when its framework has reached end of life (EOL), automated tests are absent, and a failed deployment cannot be rolled back. Support, testing, and documentation can deteriorate within the “first eighteen months,” while disciplined systems can retain them for decades.

That difference changes the first question in modernization planning. Instead of asking “how old is it,” ask: “What is the gap between what it can support and what the business now needs?” The issue is whether the organization can still change the system safely at a cost the business can sustain. Age can correlate with difficulty, but cannot establish that condition by itself.

Technical debt adds another dimension because it describes accumulated shortcuts and design compromises inside software. A system can contain extensive technical debt while remaining supported and easy to deploy, in which case refactoring may be enough. Netguru’s guide to managing technical debt addresses that code-level problem; as a software consultancy that sells engineering and modernization work, Netguru also has a commercial interest in organizations acting on such debt. Conversely, a nearly debt-free application can become legacy when its underlying framework loses support and security patching.

Developer experience shows why the two concepts still overlap in practice. GrowthBook’s analysis of the 2024 Stack Overflow Developer Survey found that 62.4% of professional developers ranked technical debt as their #1 work frustration. GrowthBook, which sells software-development infrastructure, benefits commercially when engineering organizations invest in improving how they build and release software, so its analysis should be read with that stake in view. The figure shows the burden of technical debt; frustration with debt does not by itself classify an entire system as legacy.

For engineering and business leaders, the practical test is whether software retains enough safe and economical capacity for change to meet current business requirements. That test leaves old, healthy systems alone when they remain fit for purpose. It also brings relatively young systems into modernization discussions when unsupported technology, weak verification, or unsafe deployment has already limited what engineers can change.

Legacy status is a capability gap

That capacity-for-change test has useful standards context in ISO/IEC 25010, which describes software quality through eight characteristics. Maintainability, compatibility, and functional suitability are especially relevant because they examine whether software can continue serving its required purpose and environment. ISO/IEC 25010 does not itself provide this definition of legacy status. Its quality characteristics instead provide evidence for judging the gap between a system’s current capabilities and current requirements.

Support status can create such a gap before wider organizational symptoms appear. Microsoft set October 10, 2023 as the end of security patches for Windows Server 2012. A deployment could have continued performing its existing workload perfectly on October 11, but its operating conditions had changed because known vulnerabilities could no longer rely on ordinary vendor patch support. Future operation and modification consequently carried a different safety and economic profile.

That support boundary makes EOL an objective trigger independent of the software’s calendar age. EOL means the supplier has ended a defined level of maintenance or support, such as ordinary security patching. A nearly debt-free application can cross that boundary before its deployment process, team ownership, or feature delivery visibly deteriorates. The first loss of capability can therefore begin in the support environment and spread into engineering work later.

Business requirements can create the gap from the opposite direction. An enterprise resource planning system (ERP) can still process established transactions yet fail when a new compliance requirement demands something its architecture cannot provide. An AI integration can expose the same limitation when required data or interfaces are unavailable. AI agents and other agentic functionality, meaning software that can carry out multi-step tasks on a user’s behalf, can join native cloud connectors and real-time data pipelines in requiring access patterns that a system built around manual exports cannot supply.

The resulting tension is between “still works” and “still fits.” Existing workloads establish that the system retains operational value. Future requirements establish whether the organization can keep changing it at acceptable risk and cost. Evaluating that difference requires evidence from the infrastructure, the engineering team’s relationship with the system, and the costs reaching the business.

Diagnose legacy status across infrastructure, teams, and business cost

Those three areas support a diagnostic of 12 signs: four infrastructure checks, four team checks, and four business-cost checks. The categories matter more than a raw tally because they reveal whether a technical limitation has begun changing engineering behavior and business outcomes. Several isolated weaknesses can remain ordinary technical debt, while weaknesses crossing category boundaries indicate a broader loss of changeability.

The first infrastructure check, support status, starts with the vendor lifecycle notice for the exact technology in production. Windows Server 2012 illustrates why precision matters: its lifecycle boundary changes the risk profile even when application behavior looks identical on either side of the date. Support status therefore measures the environment in which future changes must operate.

The second check follows that external support question by examining the team’s own evidence about changes. After code is merged to main, a healthy automated path should trigger a build and tests through CI/CD, giving engineers evidence before production. Without trusted automation, even a one-field data fix can lead to a “multi-week regression pass.” Mainframe COBOL applications make the distinction particularly clear because long-running logic can keep producing correct results while the organization lacks an automated way to establish that a new change is safe.

Once verification is understood, the third check is deployment because a repeatable build provides limited protection when production changes still depend on human memory. A release requiring SSH access, commands executed in remembered order, a checklist, an ad hoc script, or hand-edited configuration concentrates operational risk in the release process. Monolithic deployment increases the consequence because the whole application moves together, so a release intended to alter one area can expose the entire system to the same failure.

The fourth infrastructure check extends deployment into recovery. Rollback means returning a failed release to a known-good state; without it, engineers may have to create a forward hotfix while production is impaired. The situation becomes especially dangerous when a legacy database sits below integration points that nobody has completely mapped, because a rushed repair can encounter dependencies invisible during planning. Recovery capability therefore shows how safely an organization can experiment with change.

Infrastructure weaknesses matter more when the team begins adapting its behavior around them. The fifth sign is tribal knowledge concentrated in “one or two people’s heads.” A useful test is to ask who can safely alter the billing module without first consulting the person who understands it. When nobody else can do so, delivery depends on an individual’s availability instead of reproducible documentation and engineering practice.

That dependency leads into the sixth sign, avoidance inside the codebase. Engineers may wrap a difficult module instead of refactoring it, or schedule a risky change for the shift when the only confident engineer is on call. Weak recovery helps explain that behavior because a deployment failure that cannot be reversed quickly raises the downside of changing code. Architecture decisions can then begin to reflect low confidence in recovery.

Ownership provides the seventh check because repeated avoidance can enter planning itself. During sprint planning, tickets for an unwanted system may repeatedly be deprioritized, reassigned, or accepted by employees with less ability to refuse the work. Jira can record those engineering tasks, but technical weaknesses can eventually become control failures or delayed business commitments outside Jira. A growing bug list describes problems in software, while systematic ownership avoidance shows a change in how the organization allocates people around those problems.

Recruitment and retention provide the eighth team sign because staffing difficulty can make that allocation problem persistent. Stack Overflow’s “most dreaded” rankings have placed VBA and classic ASP near the top “for years,” providing contextual evidence about unattractive stacks rather than a quantified diagnosis for an individual system. Local evidence is stronger when hiring cycles lengthen for one stack or new engineers ask to rotate away “within months.” At that point, sustaining the software is becoming harder in the labor market as well as in the codebase.

Business effects provide the third line of evidence, beginning with blocked requirements. The ninth sign appears when an ERP cannot expose information required by a new partner API, forcing engineers to add custom middleware that moves records between environments. The middleware satisfies the immediate request, but becomes another dependency to maintain. An integration ceiling has then affected both architecture and the cost of later requirements that depend on the same data.

The tenth sign carries the problem into governance. When a compliance auditor explicitly identifies an application as the cause of a control gap, technical risk acquires a formal business owner and paper trail. The same system that previously generated engineering tickets can then appear in material prepared for senior management or a board. Postponement consequently becomes a governance decision as well as an engineering-priority decision.

The eleventh check measures marginal change cost because total operating expense can hide the price of touching the software. A ticket that previously took “a day” and now takes “three weeks” shows that each modification has become expensive even when routine operation remains manageable. The earlier one-field data fix illustrates the mechanism: tiny implementation work can trigger extensive manual validation when automated evidence is weak. Marginal cost therefore exposes limitations that a run-cost budget can conceal.

The twelfth sign compares delivery speed with the business opportunity. A feature that has been “scoped twice and shelved twice” shows that feasibility is influencing product decisions before implementation starts. In retail, the same constraint appears when a payment method or sales channel requires a “full quarter instead of a sprint” because checkout and inventory remain coupled at the data layer. A competitor able to ship an equivalent capability faster turns that architectural limitation into a business consequence.

The signs do not carry equal diagnostic weight. The guidance describes “Three isolated signs” as potentially ordinary technical debt, while “Three signs scattered across categories” describe a monitor situation. Once “Six or more” signs span infrastructure, team, and business cost, the evidence supports scoping a formal assessment because the same problem is appearing beyond one technical layer.

Distribution makes that threshold more useful. A team dependent on tribal knowledge while running a current framework with working rollback is fragile, and documentation plus pairing can directly address the succession risk. An EOL framework combined with no rollback and “two or three business-cost signs” has already connected infrastructure limits with business outcomes. That cross-category pattern provides stronger evidence of legacy status than the threshold by itself.

Technical constraints become organizational constraints

Cross-category evidence matters because the signs can form a causal sequence. Missing automated tests and recovery make changes harder to verify and failures harder to reverse, which raises the expected cost of a mistake. Engineers then have a reason to avoid risky modules, arrange work around scarce experts, and increase manual validation. The technical condition has begun shaping how the organization works.

Deployment practices can deepen the same sequence. When releases depend on remembered procedures and failures require pressured forward hotfixes, each difficult release can lower confidence in the next one. Engineers respond to that expected risk through scheduling, architecture, and staffing choices. Avoidance under those conditions is an operational response to the production path.

ERP patching shows how that response accumulates over time. Customizations with thin automated coverage can force teams to validate patches manually against production-like copies, while blocked integrations can lead to custom middleware around the ERP core. These patterns commonly appear in ERP and billing systems that have expanded beyond their original scope. Each workaround can solve a local problem while making the combined environment harder to change.

Banking cores show the same mechanism at a different scale. New functions can be bolted around an established core because changing underlying transaction logic carries more perceived risk than adding another surrounding layer. Unwanted tickets may then be repeatedly deprioritized as teams protect delivery schedules from work with uncertain recovery. Architecture, release calendars, staffing, and backlogs start reacting to the same underlying difficulty.

Once those adaptations reach business planning, the diagnosis has moved beyond code quality. Manual verification lengthens schedules, scarce experts constrain start dates, custom middleware raises integration cost, and control weaknesses can become compliance findings. A single expert dependency can remain a manageable succession problem, but recurring adaptations across technical and business boundaries show that the organization is paying continuously for limited changeability.

Valuable systems can still be difficult to replace

A legacy diagnosis does not make continued operation irrational. An incumbent can impose growing change costs while still executing core transactions for finance, inventory, customers, or compliance. Replacement requires significant spending up front and introduces migration risk immediately, while another patch can postpone both. That asymmetry can keep established systems in production long after their limitations become visible.

The incumbent also contains accumulated correctness. An ERP with “two decades of real transactions” has encountered business rules, exceptions, and edge cases through actual operations, including cases that may no longer be completely documented. A replacement must rediscover or revalidate those behaviors while continuing to serve the business. Rewrites spanning finance, inventory, or compliance data make that requirement especially consequential.

The financial scale reinforces that caution. Broad rewrites can require “seven or eight figures and multiple years.” A separate benchmark labeled “Industry data” puts enterprise replacements at “$150K-$2M+” and “11-15 months.” Those ranges frame the scale leaders may have to consider when comparing continued operation with replacement.

Migration risk can become immediate before the full program cost does. An engineering lead considering replacement has to account for a cutover that could produce a multi-day accounts-payable outage while the incumbent still closes the books correctly today. Teams can consequently keep patching integration ceilings until the aggregate cost of workarounds becomes harder to defend. For an individual planning cycle, continued operation can carry lower immediate risk even while the longer-term limitation grows.

ERP systems show why that period can last for years. ERP Research says SAP ECC 6.0 and comparable Oracle E-Business Suite installations serve “thousands of enterprises.” ERP Research operates in the ERP market and benefits commercially from organizations researching, selecting, and changing ERP systems, so that market position matters when judging its claim. SAP’s timeline provides the vendor’s own lifecycle position: ECC 6.0 mainstream maintenance continues through 2027, with paid extended support afterward.

SAP also has a direct commercial stake in that support timeline because it sells enterprise software, maintenance, and migration paths. The persistence of ECC 6.0 and comparable environments still has an operational explanation: their core transaction behavior has already survived regulatory and business edge cases. Replacing that behavior requires the new environment to preserve those accumulated rules through migration.

Customization can make the challenge specific to one deployment even when the underlying platform remains active. Automated coverage around bespoke ERP extensions can be thin enough that patches require hand-validation against production-like copies, and a custom ERP module might remain untouched for a decade because changing it creates more uncertainty than leaving it in place. SAP, Salesforce, and other enterprise platforms can therefore contain healthy current deployments alongside problematic deployments whose old versions, undocumented customizations, or lapsed support limit change.

Current platform capabilities make that deployment-specific distinction sharper. Platforms can add AI agents that automate workflows, native cloud connectors, and real-time data pipelines while a frozen installation remains dependent on manual exports and unavailable interfaces. The organization’s actual deployed system is consequently the useful unit of diagnosis. Its version, custom code, data access, recovery path, and support position determine what engineers can safely change.

Banking carries accumulated correctness deeper into transaction processing. Mainframe COBOL systems and deprecated early-2000s Java monoliths can continue clearing workloads that replacements would have to re-prove, encouraging institutions to add functions around the core. One common form is a COBOL batch environment behind a modern web front end, with fraud checks or reporting added as separate layers while the core still lacks CI/CD and reliable rollback. Proven transaction behavior remains valuable even as incremental change becomes increasingly difficult.

Healthcare adds patient-data integrity to the migration calculus. Electronic health record (EHR) environments still rely on HL7 v2 messaging, a long-established healthcare data-exchange standard, which is commonly treated as a bridge toward Fast Healthcare Interoperability Resources (FHIR), a newer interoperability standard. Interface changes during deployment can threaten patient-data integrity, increasing the cost of migration errors. A patient-record database running on an unsupported operating system can also require custom middleware for modern interoperability while creating patching and compliance concerns.

Retail demonstrates the same conflict through product velocity. A heavily customized e-commerce or point-of-sale monolith can continue selling reliably while tightly coupled checkout and inventory data turn a new payment method or sales channel into a quarter-long project. Its proven behavior gives the incumbent continuing value, while its structure raises the cost of each new requirement. Any replacement has to preserve that production correctness while creating a safer path for future change.

Those replacement pressures explain why organizations often keep paying through manual validation, middleware, surrounding functionality, and constrained delivery. The difficult part of modernization is preserving the behavior the business depends on while reducing the cost and risk of changing it. Diagnosis establishes whether that work deserves formal assessment; it does not by itself select the modernization method.

Use the diagnosis to scope modernization

That distinction makes assessment the next step after classification. Roughly three signs scattered across categories call for monitoring, while six or more spanning infrastructure, team behavior, and business cost warrant a formal assessment. Category spread carries greater diagnostic weight because it shows that technical limits have propagated into engineering behavior and business delivery.

A formal assessment can begin with an infrastructure and data audit that separates substantive risk from superficial age. The audit should establish support status, deployment and recovery paths, data dependencies, integration ceilings, and the business effects tied to those conditions. With those facts mapped, leaders can identify which limitations require action and sequence the work around operational dependencies.

That evidence then supports selection among modernization strategies. The “7 Rs” provide the referenced modernization-selection framework for matching systems to different paths. Their role is to turn a legacy diagnosis into a strategy suited to the particular system, its dependencies, and the business risk established during the assessment.

Key takeaways for decision-makers

• Age does not define legacy software: A decades-old system can remain healthy when it is supported, tested, documented, and safe to deploy. CTOs can focus modernization decisions on whether the system still supports required change at sustainable cost.
• Legacy status reflects a capability gap: EOL technology, new compliance demands, unavailable interfaces, or weak recovery can create a gap between what a system supports and what the business requires. Engineering owners can use support status and current requirements to identify that gap early.
• Diagnose across technology, teams, and cost: Strong evidence of legacy status appears when infrastructure weaknesses coincide with tribal knowledge, code avoidance, staffing difficulty, blocked requirements, or rising change costs. Organizations seeing six or more signs across these areas have grounds to scope a formal assessment.
• Technical limits reshape the organization: Weak testing, manual deployment, and poor rollback increase the expected risk of change, driving engineers toward workarounds and scarce experts. Engineering managers can treat recurring avoidance, middleware, and manual validation as evidence that technical constraints are affecting delivery.
• Preserve the value embedded in incumbent systems: ERP, banking, healthcare, and retail systems can hold decades of proven business rules while becoming increasingly expensive to change. Modernization planning needs to protect that accumulated correctness and account for migration, data, compliance, and cutover risk.
• Turn diagnosis into modernization scope: A legacy classification establishes the case for assessment rather than prescribing replacement. Technology leaders can audit support, deployment, recovery, data dependencies, integration limits, and business effects before selecting an appropriate modernization strategy.