How to ensure the survival of a software project after its production release
Learn how to extend the lifecycle of industrial software projects with documentation, reproducible builds, and open-source strategies.
In industrial projects, whose maintenance rhythm differs from that of other types of projects (such as SaaS), we often tend to focus on the early stages: design, sprints, production release, user feedback and so on. Yet, we rarely pay attention from the start to the end of the lifecycle. However, that final phase can prove problematic.
What is a lifecycle in a software project?
A software lifecycle describes all the successive phases that a project goes through, from its initial idea to its maturity and long-term evolution. It generally includes:
- Requirements gathering and analysis (audits, specifications, understanding the industrial or business context)
- Design (architecture choices, data models, technologies, system constraints)
- Development (code implementation and module integration)
- Testing and validation (unit, integration, system, performance)
- Production release (deployment and delivery to the end user)
- Operation and maintenance (corrective, adaptive, perfective, preventive)
- Long-term evolution (refactoring, technology migration, living documentation, knowledge transfer)
Depending on the methodology used waterfall, agile, iterative or DevOps, these stages may follow one another sequentially or repeat in short cycles.
But in all cases, software is never static: it is a living system that evolves with its technical environment, its users, its dependencies and its industrial constraints.
A lifecycle does not end at delivery
Most software lifecycle models, whether waterfall, spiral or iterative, stop at production release or immediate post-delivery maintenance. But these diagrams were designed to manage projects, not living products.
In industrial reality, a software’s lifecycle continues well beyond the project phase: it extends over time, through wear, team changes, evolving operating systems, unmaintained libraries and shifting hardware.
This post project phase, often misleadingly called “maintenance”, is actually a cycle of its own, non-linear and often unplanned, yet strategic. If not anticipated from the start, it becomes a grey area where risk slowly but surely increases. And that’s where the real issue lies: considering the lifecycle as a whole, including beyond the initial delivery, with a long-term continuity mindset.
Research confirms this: maintenance and evolution account for up to 80–90% of total lifecycle costs and determine whether a software product can withstand “software aging". Studies also show that maintainability (stable architecture, clear documentation, reproducible build processes) is the key to reducing costs, improving quality and ensuring durability over decades.
A software project can outlive the team that built it
This situation is far from rare: an industrial software product is deployed and operates smoothly. Years pass, and the team that designed it is no longer there. The new team only has incomplete documentation, sometimes requiring prior project knowledge just to be understood.
The project no longer has an identified reference person. No one really knows how to modify or evolve the code without breaking existing functionalities, sometimes requiring very costly resources to test, such as production machines.
As a result, companies find themselves with a stable but critical tool in production, without anyone who holds the knowledge or know how to redeploy the application, fix a bug or install the correct versions of the libraries.
Without preserving knowledge and know how, major risks arise
The lack of knowledge preservation is a genuine risk factor in the medium and long term.
Builds become hard to reproduce
One of the major causes of this loss of control is non-reproducible builds. Today, most software depends on an ecosystem of libraries, packages, dependency managers, precise versioning and online resources.
Sources: ISO/IEC 14764 (Software Maintenance), ISO/IEC 29119 (Software Testing), Reproducible Builds Initiative, CISA Secure Software Development Framework (SSDF).
Dependencies may no longer be known
Losing track of exact versions or neglecting build scripts (if they exist) leads to serious risks. Whether the tooling involves Node, Python, CMake, Gradle, Maven or Conan, it does not matter: if the versions are lost, if the package repository has disappeared or if the build relied on online resources that no longer exist, the software becomes extremely difficult to maintain.
Fixing a bug or delivering an update reliably becomes almost impossible.
Integration tests become hard or impossible to run
This is the other side of the problem: testing. Test scenarios are not documented, required hardware (cameras, sensors, APIs, etc.) is no longer available, test benches are out of order and data is corrupted or lost. Integration tests can no longer be run. Neither the scenarios, nor the data nor the required hardware are documented. You end up with an unusable test environment. Unit tests are missing or obsolete.
The result: A nearly frozen project
In long term support environments (industrial systems, embedded software, technical applications, etc.), such conditions can lead to a deadlock:
➡️ The software can no longer be built. ➡️ Fixes cannot be deployed. ➡️ Installing it on a new machine becomes difficult or impossible.
Technical debt settles in and solidifies. Without a clear technical referent or documentation to explain the reasoning behind key decisions, the overall understanding of the project fades away.
Sources: ISO/IEC/IEEE 12207 (Software Life Cycle Processes), ISO/IEC/IEEE 14764 (Software Maintenance), IEEE Software Aging studies.
How to manage a software project’s lifecycle to avoid technical debt
Several practices can reduce these risks:
1. Document thoroughly
Documentation should be carefully constructed, stored in the right place, easily accessible and justify design choices, dependency points, target use cases and known development constraints.
2. Aim for repeatability
As far as time and budget allow, strive for reproducibility—ideally building offline, without HTTP requests to external servers, freezing dependency versions and integrating the build into a robust CI/CD pipeline. This ensures that the build can be rerun identically without relying on volatile external URLs.
3. Anticipate the “after” from the start
Even when a project is considered “finished,” especially in industrial contexts, maintenance needs will reappear sometimes ten years later. This means preparing long-term documentation (not just sprint notes), designating a “project guardian” even after delivery and anticipating future portability (OS, platforms, hardware).
And what about web projects?
Web projects are often more dynamic, with regular updates, scalable hosting and DevOps teams constantly monitoring. However, even web projects are not immune: frequent updates, cloud hosting, rotating teams…
They too can age poorly frozen projects with obsolete stacks, outdated dependencies, no CI and no internal skills to perform deployments. The same reflexes apply here as well.
Considering a radical but virtuous solution: going open-source
When a software project reaches the end of its life and when internal maintenance is no longer desired or possible, there is a responsible and sustainable alternative: making it open source.
This involves:
- Publishing the source code under an open license,
- Making the documentation, build scripts and dependencies accessible,
- Allowing a community to take over, fix, secure and improve the project.
From our perspective, this is more than a technical choice—it is an ethical act of transmission: allowing the project to live on, even after the company steps away.
A Parallel with the video game industry: the “Stop Killing Games” initiative
This topic echoes a very current issue: video games becoming inaccessible because publishers no longer consider them “profitable.” The Stop Killing Games highlights this situation: games that players legally purchased become unavailable because servers are shut down or the software is no longer compatible with modern operating systems. Publishers refuse to patch or release the code, leading to an irreversible loss of digital heritage.
If those games were open-sourced, enthusiasts could ensure compatibility, maintain servers and adapt them to modern platforms.
The reasoning is identical for industrial software, business tools or internal projects: a software project is rarely “finished” when delivered and opening it to a community can be a way to keep it alive.
Conclusion: A well designed software lives long and even longer with open-source
A software project does not end with its delivery. It simply enters a new phase one of maintenance, transmission, change and sometimes reinvention. Ignoring this phase means taking the risk of seeing the software degrade and become unusable, a potential future nightmare.
That is why preparing it to survive matters: designing it as sustainable, ethical and accessible software, beyond the lifespan of a project or a budget.
And why not give it a second life through open source, so it can continue to evolve even without us? Because what is no longer profitable for a company may still be essential to collaborators, users, researchers, or entire communities.