31 Oct, 2025
Picture this: we have a large organisation that runs a dated piece of middleware software which is heavily tied into the backbone of that organisation’s technology landscape.
Over time, this software becomes the organisation’s problem child for a number of reasons, such as:
Lack of ownership or unclear boundaries
Knowledge loss due to staff leaving the organisation
Untidy organisation and archival of older documentation
Lack of updates and deployments leading to decreased confidence in supporting the software
Lack of understanding of the reach and entanglement of the software within your architecture
Fear of change
To throw a spanner in the works, the company that developed the software has announced that the software is reaching its end-of-life. You’ve now reached your breaking point and must decommission it.
Setting yourself up for success
Before we can start tackling the problem we should set a deadline. In our case, this deadline was sparked by the previously mentioned end-of-life date but it doesn’t have to be. It can be tied to a major software release, the date of a business objective or your cat’s birthday; the important thing is to pick a date and circulate it. This is especially important if working with a larger forum or across domains as it creates a common goal to work towards.
A good place to start is documenting a set of guidelines for the overall process that can be applied across each division of work even if you don’t know what that looks like yet.
At a high level these guidelines should cover:
Which software environments are being tackled? - This will help you build out your scope of work and gauge how big the decommissioning task will be. e.g. test, production
Where are your milestones and when do you want to achieve them? - Attribute a time period where possible to your milestones as it helps to drive your indication of success. The time period can come in the form of either a set amount of days or a significant domain event such as the end of the financial year. An example could be having no network traffic flow through your production environment for 14 days before switching the flow off.
Do we need any sign-offs at any stages and who should do them? - This is to ensure we have some accountability in place given we’re looking at a high risk task e.g. An engineering manager or product manager signing off for test environment but maybe more senior leadership team for production
Next, we have a few things we need to answer here so that we can safely navigate our unknowns:
How can we break down the problem into more manageable parts?
How will we handle any interdependencies that arise between teams and how will we keep the correct teams informed when we start switching things off?
What will we do when things go wrong?
What will our indicators be that our work is successful and when will we call it done?
Breaking down the beast
The same agile software delivery rules that we use to create software can be applied to decommissioning software. We essentially want to build a “minimum viable product” but in reverse. Given we may have a lot of unknowns, rather than just looking at what the software is, we should look at what our measurable inputs and outputs are, what business flows are occurring and what value the software is providing to the business and segment the workloads accordingly. We can then associate a profile of risk and revenue associated with what is being decommissioned and prioritise appropriately and reduce the blast radius of each service we switch off.
Imagine software handling two different jobs: one that automates a simple manual task of copying calendar events, and another that keeps credit card transactions in sync across multiple billing systems. It's clear that a problem with the credit card system would be much riskier and cost a lot more money, both in lost earnings and operating expenses. So, it might make sense to deal with and remove the easier, less risky tasks first. While this seems obvious, it shows the importance of assessing what functions are being performed when determining where we may want to start. Another benefit is that if our software spans multiple teams, we may be able to assign a single flow to a team that looks after a specific function e.g. assigning the decommissioning of the credit card flow to the technical team that looks after billing.
Don’t be attached to “the way we do things now”
One of the hardest things to overcome in a large organisation, especially where there are a lot of unknowns, is the fear of changing or abandoning a process. It’s often very easy to just rebuild exactly what “works” somewhere else and sometimes it might be appropriate but it’s always worth asking the questions:
What are we currently trying to achieve with our tech solution?
Do we really need to do this anymore?
Are we really seeing value in continuing to do this?
Hedging our bets
Decommissioning software often doesn’t mean an instant transition between installed software to uninstalled software in all environments or just deleting our infrastructure as code stacks and calling it a day. The process of uninstallation is usually the “point of no return” so it’s often favourable to start with the least destructive option first and move along the path of decommission incrementally. We should also consider our options in terms of rollback and reversion so that when things go wrong, the path to service restoration is clear. Steps like running parallel runs of the old solution and new solution and “soft” decommissioning your old solution by pausing or stopping them for a period of time instead of jumping right to uninstalling them goes a long way in increasing your confidence when trying to retire legacy software.
Now that we’ve explored a few points, what does it all look like together?
Going back to the middleware example, an example of the decommission process could look like this:
This old piece of software was identified as running, and the decision was made to decommission it.
The software was identified as currently supporting integrations between our billing system, providing customer account updates, managing software licensing, and various other internal functionalities.
The related technology teams that look after billing, software licensing, customer account management, etc., were gathered into a forum.
A call to action was put out to decommission the software by the new year.
Responsibility for decommissioning each workflow was distributed to the related team, but overlap was identified on the billing flows between the accounts and billing team, so the billing team was allocated the work but the accounts team was also required to be involved with the sign off.
A replacement solution for the billing integration was built so the process of decommissioning the existing one was kicked off.
a. Pivot to the new system occurs in non-production
b. Monitoring of traffic on the old systems flows shows a sudden halt in the old system but traffic correctly being processed in the new system in non-production
c. Pivot to the new system occurs in production
d. Monitoring of traffic on the old systems flows shows a sudden halt in the old system but traffic correctly being processed in the new system in production
e. After 14 days of the old system no longer having traffic in non-production passes, the service is switched off in non-production.
f. After the “end of financial year” period has successfully been processed in production on the new system, we switch off the old system in production.
Rinse and repeat for the other workflows until the relevant functionality has been replicated
Uninstall your application(s) and turn off your infrastructure
Decommissioning legacy can be a challenging but fun and rewarding experience. Rather than treating it as a chore and putting it off, look at the process of “unbuilding” something as a puzzle to solve and a task to rally around. Hopefully this article has provided you some insight into switching off old tech.
Decommissioning legacy can be a challenging but fun and rewarding experience. Rather than treating it as a chore and putting it off, look at the process of “unbuilding” something as a puzzle to solve and a task to rally around. Hopefully this article has provided you some insight into switching off old tech.
"Vasin Pether is the kind of engineer you trust with mission‑critical systems and complex transformation work. He blends deep technical judgment with pragmatic delivery leadership—raising the bar on observability, quality, and risk management while keeping teams aligned and outcomes front‑and‑center.We engaged Vasin to lead high‑stakes delivery across multiple platforms and teams. He brought calm, outcome‑focused leadership, built‑in observability, and operational discipline that reduced legacy risk and improved integration reliability. Our teams moved faster and with more confidence thanks to his clear communication and hands‑on coaching. We would partner with him again in a heartbeat.”Why I recommend him:
Outcome‑focused leadership under pressure—he made complex legacy decommissioning and multi‑platform delivery tractable and well‑sequenced
Engineering excellence with operational maturity—security‑minded configuration, robust error handling, and traceable workflows were built in from day one
Uplift and collaboration—he coaches pragmatically, clarifies ownership, and leaves systems and teams better than he found them.
Bottom line
If you need someone to own the hard parts—reducing legacy risk, strengthening integrations, and ensuring the delivery engine hums—he delivers. Strongly recommended for senior delivery, integration, and platform leadership work.
Ganesh Kawade, Engineering Manager at MYOB
.png){kind=logo}
