English 
Português
Software evolution is the continuous process of changing a system after it goes live, so that it stays useful as the business, technology and external rules change. It includes fixing defects, adapting the system to its environment and building new functionality.
Most executives know the scene. The system that carried the operation for years starts to slow down, an integration with a partner stops working, and billing depends on spreadsheets to cover what the application no longer does. Nobody built it wrong. The world around the software changed.
This guide explains the concept, shows what research says about it and offers a practical framework to decide when to evolve, maintain, modernize or replace a system.
Quick summary
- Software that runs in the real world is never “finished”: it either evolves in a planned way or loses value.
- Evolution and maintenance are related, but they are not the same thing.
- Classic studies indicate that most of a system’s cost comes after delivery, and that most of that work is enhancement, not bug fixing.
- Evolving with governance costs less than reacting to incidents.
- AI speeds up the reading of legacy code and the creation of tests, but decisions and review remain human.
What is software evolution?
Software evolution is the ongoing change of a system throughout its useful life, driven by shifts in business requirements, in the technology environment and in legal or market demands. The goal is not only to repair what broke. It is to keep the system aligned with what the company needs today.
The concept has a solid academic basis. Researcher Meir Lehman, who worked at IBM and later at Imperial College London, studied the evolution of large systems starting in the 1970s and formulated a set of observations known as Lehman’s laws (see the original paper, Lehman, 1980, Proceedings of the IEEE). They apply to so-called “E-type” systems: those that solve a real-world problem and, by doing so, change the environment they operate in. When the system changes the environment, the environment demands new changes from the system. This cycle explains why evolution is a natural property of enterprise software, not a sign of a design flaw.
A billing system, for example, is built for a specific set of tax rules, a bank and a charging model. If any of those change, the system has to change with them, even if it has no defects at all.
Software evolution vs. software maintenance: what is the difference?
The two terms appear together in almost every source, and many articles treat them as synonyms. The literature draws a useful distinction. According to a COPPE/UFRJ technical report, maintenance refers to activities carried out at any time after a system is deployed, while evolution examines how a system’s characteristics behave and change over time.
In management terms, the difference can be summarized like this:
| Maintenance | Evolution | |
|---|---|---|
| Focus | Preserve and fix what exists | Keep the system in step with the business |
| Typical trigger | Failure, incident, environment update | New demand, process change, growth |
| Horizon | Short term, often reactive | Medium and long term, planned |
| Example | Fix an error in a commission calculation | Build an API integration with the bank’s system |
Maintenance is one of the ways evolution happens. A company that only does reactive maintenance keeps the system running, but does not move it toward what the business needs.
Why does software need to evolve? Lehman’s laws explained
The eight laws were formulated between 1974 and 1996, based on empirical observation of large systems, and they are still studied. Godfrey and German (2014) revisit the laws and discuss how software development has changed since. A 2024 master’s thesis from the Federal University of Ceará analyzed three modern systems and concluded the laws remain applicable. It is worth noting that these are observations, not physical laws: they describe tendencies, not guarantees.
Translated into management decisions, the laws look like this:
| # | Law | What it says | In practice |
|---|---|---|---|
| 1 | Continuing change | A system that is not adapted becomes less and less useful | Keep a permanent evolution backlog |
| 2 | Increasing complexity | Each change adds complexity unless work is done to reduce it | Reserve fixed capacity for refactoring |
| 3 | Self-regulation | The pace of evolution follows a relatively stable statistical pattern | Plan on measured capacity, not on promises of sudden leaps |
| 4 | Conservation of organizational stability | The average rate of work tends to stay constant over the system’s life | Doubling the team does not double delivery |
| 5 | Conservation of familiarity | Those who evolve the system must master its content and behavior | Preserve knowledge and avoid swapping the team every cycle |
| 6 | Continuing growth | Functionality must keep growing to maintain user satisfaction | Have a roadmap, not just fixes |
| 7 | Declining quality | Quality tends to fall unless the system is rigorously maintained and adapted | Test, monitor and govern continuously |
| 8 | Feedback system | Evolution is a multi-level feedback system | Measure, report and adjust in short cycles |
The central message is simple: a system that stops changing is not “complete.” It is falling behind.
What are the types of software maintenance and evolution?
The most common classification divides post-delivery work into four types (see, for example, the CAST glossary):
- Corrective: fixes errors and failures found in production, such as a bug that prevents orders from being processed.
- Adaptive: adjusts the system to environment changes, such as new operating system versions, cloud changes, new integrations or new business and tax rules.
- Perfective (evolutionary): improves performance, usability and features, including the creation of new capabilities.
- Preventive: reduces future risk by making the system more stable, understandable and maintainable, for example through refactoring and library updates.
The point to watch is that these fronts are different in nature. Fixing is reactive; adapting requires tracking the environment; evolving requires dialogue with the business; preventing requires discipline and indicators. Many companies have the structure for only the first one.
That is why NextAge’s Application Managed Services (AMS) is organized around four pillars: corrective, adaptive, evolutionary and application governance, combined in a single recurring contract with a defined scope, SLA and reporting. Governance, with monitoring, indicators and executive oversight, plays the role that preventive maintenance plays in the literature.
How much does it cost not to evolve?
The discussion on cost is old and consistent: most of the money spent on software is spent after delivery.
According to the so-called “60/60 rule,” presented by David Wood in 97 Things Every Project Manager Should Know (O’Reilly), around 60% of a system’s lifecycle cost comes from maintenance, and around 60% of that maintenance is enhancements requested by users, not bug fixing. The author notes that the range varies from 40% to 80% depending on the type of system and environment. In the same source, average maintenance effort splits into roughly 60% enhancements, 23% migration and 17% bug fixes. A study by Benaroch (ICIS, 2013) cites a similar range, between 50% and 80% of a system’s lifetime cost.
These figures are classic and vary across studies, so treat them as an order of magnitude. The conclusion, however, is robust: most post-delivery work is business-driven change, and that is where the budget should be planned.
The cost of neglect also shows up at the macro level. The Consortium for Information & Software Quality (CISQ) estimated that poor software quality cost U.S. organizations at least US$2.41 trillion in 2022, with about US$1.52 trillion in accumulated technical debt. The data covers the United States only, but it illustrates the point: postponing evolution does not remove the cost, it moves it to a worse moment.
Inside the company, that cost usually appears as operational downtime, manual rework and delayed decisions. System failures rarely stay inside IT: they hit billing, operations and the end customer. For that reason, critical systems should be managed as assets that protect revenue, not as an open ticket.
Signs your software needs to evolve
If you recognize three or more of the items below, it is time to look at your systems more closely:
- Important processes now depend on spreadsheets or workarounds outside the system.
- Every new feature takes much longer than it did a few years ago.
- Incidents keep repeating and the root cause is never addressed.
- Integrating with a new partner, bank or platform is considered “unfeasible.”
- Few people understand how the system works, and the documentation is out of date.
- The system uses technologies or languages with a growing shortage of professionals.
- Security updates and library upgrades are overdue.
- There is no visibility into performance, availability or risk.
- The IT team is small and spends most of its time firefighting.
If several of these sound familiar, a diagnostic is worth it. NextAge offers a no-cost, no-commitment diagnostic conversation in which it maps your operational risks and presents an action plan.
How to evolve software without stopping operations: 10 best practices
- Treat the system as a product. Keep a continuous backlog instead of a project with an end date.
- Reserve capacity for technical debt. A fixed share of effort should go to refactoring (Law 2).
- Automate testing and delivery (CI/CD). Smaller, more frequent changes are safer.
- Monitor and measure. Define SLAs and indicators that are visible to the business, not only to IT.
- Document and preserve knowledge. Avoid concentrating system knowledge in one or two people (Law 5).
- Modernize incrementally. Replace parts of the system in a planned way, validating each step, instead of betting on a full rewrite.
- Prioritize by impact. Order the backlog by effect on revenue and risk, not by who asked first.
- Keep the environment current. Up-to-date libraries, dependencies and security patches reduce incidents.
- Establish governance. Regular meetings and an executive report put technology on the management agenda.
- Use AI as support, with human review. See the next section.
Software evolution in the age of AI
Generative AI now plays a practical role in system evolution, mainly in three areas: understanding legacy code (including code without documentation), generating documentation and tests, and supporting translation between technologies. The Thoughtworks Technology Radar (Nov. 2025) describes, for example, an emerging technique in which AI produces functional descriptions of the legacy code, the team reviews them and designs the solution, and only then is the code rewritten. The flow goes from reverse engineering to design to forward engineering. The page is in Portuguese; the Radar is also published in English.
The gain is in reducing the time spent understanding what the system does today. The risk is trusting without validating: inaccurate answers, security flaws in generated code and the loss of subtle business rules all call for review by experienced professionals. That is why combining AI with human expertise is the safest model. It is the idea behind NextFlow AI, NextAge’s approach that brings together AI and engineering experience in every delivery.
Evolve, maintain, modernize or replace: how to decide
Not every system calls for the same answer. A practical rule is to compare the cost and risk of keeping the system as it is with the cost and risk of changing it:
| Situation | Recommended path |
|---|---|
| Stable system, occasional demands, low risk | Corrective and adaptive maintenance |
| The business changes often and the system can still absorb the changes | Continuous evolution with a backlog and governance |
| High technical debt, a shortage of professionals in the technology, or an architecture that limits scale | Incremental modernization, in stages |
| The system no longer fits the process and the cost of adapting exceeds the cost of starting over | Planned replacement, with data migration and a transition plan |
When the cost and risk of maintaining a system outweigh the cost of evolving it, modernization has to enter the planning agenda. The safest path is usually incremental: replace parts of the system, validate each step and only then move on, without exposing the operation to the risk of a full rewrite.
Application Managed Services: continuous evolution with governance
NextAge’s Application Managed Services (AMS) is a model for the continuous management of enterprise applications. Instead of waiting for problems to happen, the service monitors, anticipates and evolves systems, with a defined SLA and planned evolution built into the contract.
How it works:
- Corrective: fault resolution driven by root cause analysis.
- Adaptive: adjustments to changes in environment, integrations and rules.
- Evolutionary: improvements and new features drawn from the backlog.
- Application governance: monitoring, indicators and executive oversight, with monthly reports and regular meetings.
The hour package covers all four fronts, and one third of it is dedicated to monitoring, technical governance and operational indicators. The team works across multiple stacks, including Java, Node.js, .NET, React, Angular, REST APIs, relational and NoSQL databases, and cloud environments on Azure, AWS and GCP.
One example is APCBRH, one of the largest dairy cattle associations in Brazil. Its system suffered from cloud instability, manual billing and limitations in collecting production data. Beyond continuous support, NextAge led the migration to a more stable cloud environment, the API-based integration of billing with the banking system and a new method for collecting production data. The result was fully automated billing (100%).
Who it is for: CTOs, CEOs and COOs of mid-sized and large companies whose operations depend on proprietary or highly customized systems, that have lean IT teams and have already experienced failures with direct business impact.
Who it is not for: small businesses with simple, low-risk systems; those looking for a single developer for a specific task; and those who decide on lowest price alone or do not see their systems as strategic assets.
If your situation fits the first group, learn more about NextAge Application Managed Services.
Frequently asked questions
What is software evolution?
It is the continuous process of changing a system after it goes live, so that it remains useful as the business, technology and external rules change. It involves fixing defects, adapting the system to its environment and building new functionality.
What is the difference between software evolution and software maintenance?
Maintenance covers the activities carried out after deployment, such as fixing errors and updating the system. Evolution looks at how the system changes over time in line with the business. Maintenance is one of the ways evolution happens, but on its own it does not guarantee that the system keeps up with the company.
What are Lehman’s laws?
They are eight observations about the evolution of real-world systems, formulated by Meir Lehman and collaborators between 1974 and 1996: continuing change, increasing complexity, self-regulation, conservation of organizational stability, conservation of familiarity, continuing growth, declining quality and feedback system.
How much does it cost to maintain software in production?
Classic studies suggest maintenance accounts for roughly 50% to 80% of a system’s lifetime cost, depending on the type of software and environment. The actual figure depends on complexity, code quality, documentation and the pace of change in the business.
When should you modernize a legacy system instead of continuing to support it?
When the cost and risk of maintaining it exceed the cost of evolving it. High technical debt, a shortage of professionals in the technology in use and an architecture that limits scalability are clear signs. The safest path is usually incremental modernization, in stages.
What is AMS (Application Managed Services)?
It is a model for the continuous management of applications: support, maintenance, evolution and governance in a single recurring contract. Unlike traditional support, which reacts to problems, AMS monitors, anticipates and evolves systems, with a defined SLA and planned improvements.
Does AMS replace the internal IT team?
Not necessarily. The service can act as a strategic extension of the technology area, complementing the existing team with specialization, governance and execution capacity.
Conclusion
Software that supports a real operation changes because the business changes. Ignoring that does not preserve the system; it only accumulates risk and cost for the most inconvenient moment. Planning evolution, with a backlog, indicators, time for technical debt and governance, is what separates a predictable operation from one that lives on incidents.
If you want to understand where your systems stand, talk to NextAge. In a no-cost, no-commitment diagnostic, we map your operational risks and deliver an action plan. Book a free diagnostic.
