Every organisation has systems that nobody would build today but nobody has switched off. An integration that duplicates a feature the ERP now provides. A reporting tool used by two people. An AI assistant built for a project that ended last year, still running on a key that renews automatically. Each one carries a small, steady cost in money, attention and risk.
These systems linger because retiring them feels like admitting failure. Someone sponsored them. Someone built them. Switching them off seems to say they were a mistake.
CloudNala's view is that archiving is a governed outcome, not a failure. The CNCF treats it that way in its own project lifecycle, where Archived is one of the four named levels, used for inactive or low-activity projects that the foundation no longer supports, and reached through a defined process. An enterprise lifecycle should do the same. A system retired on time protects its users from an unsupported service, frees the people and budget that kept it running, and removes a risk the organisation no longer needs to carry.
Waterberg Mining Services is fictional, and its systems and figures are illustrative.
Retirement and funding are different decisions
It helps to separate two questions that often get blurred.
The first is a funding decision: should the organisation keep investing in this use case? That question is about value, strategy and evidence of benefit, and the Boardroom AI Test series looks at how leadership should make it.
The second is a lifecycle decision: given that a system will stop growing, how is it contained, migrated and closed safely? That is the subject of this part. A use case can lose its funding and still need careful retirement. A use case can keep its funding and still need one of its systems retired and replaced.
Signals that should open a review
A retirement review should open automatically when any of these signals appears:
- The owner left and nobody replaced them.
- Adoption is flat or falling for two consecutive quarters, measured as described in Part 4.
- The benefit was never evidenced, despite repeated requests.
- A security finding cannot be fixed without rebuilding the system.
- A dependency is out of vendor support, such as a model version past its retirement date or a library with no maintained release.
- Cost per outcome is rising while usage is not.
- A better replacement exists, inside or outside the organisation.
A signal does not decide the outcome. It obliges someone to look. A review may conclude that the system should be fixed, given a new owner, or kept as it is, and that is fine as long as the conclusion is recorded with its reasons.
Waterberg's contract rates bot
The contract rates bot was one of three initiatives labelled Retiring when Waterberg first inventoried its portfolio. It had been built during a busy tender season to answer questions about the rates in client contracts: what Waterberg charged for drilling per metre at a given mine, what escalation clause applied, when the rate was next reviewed. It worked by retrieving from a folder of scanned contracts.
Three signals had fired. Its original builder had left the company. The commercial team had since moved contract rates into the ERP, which now answered the same questions from structured data. And a spot check found that the folder of scanned contracts had not been updated in eight months, so some answers were wrong.
Nobody had switched it off, because twelve people in the commercial and site teams still used it occasionally, and nobody wanted to be the one to take it away.
Six steps of a responsible retirement
1. Name a retirement owner. Retirement is a small project and needs an owner with the time to run it. Without this step the other five rarely happen. At Waterberg the commercial systems lead took the role.
2. Inventory users and dependencies. Who uses it, for what, and what consumes its output? The bot had twelve users, one spreadsheet that pulled from it weekly, and a shortcut on the site portal. The access logs and a short message to known users found all of them.
3. Migrate or replace the use. For each use, decide where it goes. The commercial users moved to the ERP's rate enquiry screen after a half-hour walkthrough. The weekly spreadsheet was rebuilt against an ERP report. The site portal shortcut was replaced with a link to the ERP screen.
4. Decide data retention. What happens to the data the system holds or produced? The scanned contracts were already held in the document management system, so the bot's copy was deleted. Its conversation logs were retained for ninety days, in line with Waterberg's retention schedule, then deleted.
5. Announce and end support. Tell users when it will stop and where to go instead. The bot displayed a notice for four weeks, then was switched to read-only for two more, then switched off.
6. Accept residual risk, then close. Record what remains, and have a named person accept it. In this case: some historical answers given by the bot may have been wrong, and the commercial team checked whether any had been used in a live quote. None had. The lifecycle review recorded the retirement as complete.
The whole retirement took six weeks of part-time effort. It removed a source of wrong answers about client contracts, a cloud cost, and an unowned system with access to commercial documents.
Preserve, archive or delete
Not every retirement ends in deletion. There are three reasonable endpoints:
| Endpoint | When it fits | What remains |
|---|---|---|
| Decommission and delete | The use has moved elsewhere and no record is needed | A retirement record only |
| Archive for reference | The system's outputs or design may be needed for audit, learning or a future rebuild | Read-only code, configuration, evaluation results and data per the retention schedule |
| Replace | The need continues but this system cannot meet it | A migration plan and a successor with its own lifecycle label |
For AI systems, archiving the prompts, model versions and evaluation results is often worth the small effort. They are a record of what the organisation learned, and they make a future attempt cheaper.
Why timely retirement matters
Lingering systems cost more than their hosting. They hold access to data. They depend on libraries and model versions that stop receiving fixes. They consume a share of someone's attention every time they misbehave. And they quietly teach the organisation that anything once built must be kept forever, which makes every new initiative more expensive to approve.
A portfolio that retires systems on time is one where people can say yes to experiments more easily, because they know there is a way out.
For a cloud-specific angle on the same discipline, Retain, repatriate or retire covers placement decisions for workloads, and The cost of duplicate internal systems looks at the price of keeping two systems that do the same job.
Next: Part 8, Portfolios need lifecycle labels, not only red, amber and green. All parts are on the series page.
How CloudNala can help
We help organisations identify systems that no longer earn their place, run retirement reviews, and plan responsible shutdowns: user and dependency inventories, migration paths, data retention decisions and closure records. For AI systems we also help preserve the evaluation and configuration history that makes the next attempt cheaper.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology and AI Maturity Assessment or write to us at consult@cloudnala.co.za