Winning recipe for decommissioning applications

The opening

What is decommissioning?

Decommissioning is the practice of repelling pieces of software that in aggregate result in retiring entire software applications, platforms or other assets. The underlying reasons are often enterprise specific. Think of high cost- and labour-intensive maintenance that is often associated with systems announced End-of-Life, which no longer receive support. Or innovative replacements and potential migration to cloud-based solutions that are a major draw for rethinking current contracts with vendors.

Why is decommissioning important? In the coming years, drastic market disruptions such as the rise, public accessibility and increase in adoption of generative AI will leave many applications and platforms redundant. Companies already familiar and proficient with decom trajectories will continue to thrive in them. For many others, it will unfortunately be a net negative as they will fail or even fail to start.

Have a plan, one which is flexible

You have identified an application or platform to decommission. All chess pieces are on the board and the clock starts. The first and best commandment of chess is: think upfront and have a plan!

You should openly communicate your mission and strategy to the organization. This involves thinking about how and whom to continuously share this with, setting tactics, a timeline and a deadline. Sharing it early and often is important as any plan is subject to change and new insights as you move along. You must obtain a sign-off from (senior) management and have alignment with your engineers. And finally, you must know the intricacies of your application or platform to be able to give a realistic planning of this trajectory, a good ‘opening’.

Set the tone during your project, one which sounds through

There can be an inertia and often a resistance to change even in the most seemingly agile companies. A decom trajectory is hardly ever welcomed. Your stakeholders or users (internal or external) are the ones you need to incentivize and set in motion. You are trying to influence their priorities, their backlogs, to match your timelines. Your tone of voice in driving this trajectory is a determining success factor. On the one hand you need to be patient and understanding. On the other hand, you need to be clear, consistent, resolute and absolutely determined to decommission. Remember, you are as Gartner (a renowned research- and advisory body) puts it, the ‘application assassin’. So, no standard Queens Gambit, but go for a fancy-aggressive Danish Gambit, sacrificing two pawns for immediate development of your pair of bishops and centre control.

The Middlegame

One of the trickiest points in chess is right when your opening preparation ends. You have castled your king and developed your pieces, how to continue from here? Take it slow, see if there are favourable exchange options or if you can open interesting files and diagonals.

Asset Inventory analysis and reporting

It's easier to put into effect collective willpower and effort if you report on numbers and insights of your application or platform. Translating these into dashboards with diagrams and metrics allows you and the organization to measure progress and have an anchor. Identify the type of users, and ask yourself some questions: What data and data structures need to be preserved, migrated or deleted? What regulatory compliancy and risk measures do we need to consider?

Point to an alternative

If there is an alternative application or platform, try to push and pull users, data, functionality and foremost attention into that direction. You may organize walk-in sessions, send personalized newsletters and attend to your top users by volume, risk or criticality. Receive and discuss their plans and obstacles.

It can be challenging if there are hundreds or even thousands of internal and external users to attend to. In such case you need to be careful not to spread yourself and your teams too thin. Continuously build and share documentation on use cases, best practices, what if scenarios and FAQs to alleviate some pressure.

Decommission-as-you-go

You can’t have a laissez-faire approach and hope users will stop using your application or platform. Instead, proactively single out infrastructure, environments or feature- subcomponents that can be repelled ahead of your set deadline. Set restrictive measures to discourage continued access and usage. You send a strong signal to your users by keeping the pressure high, and you are already decommissioning.

The Endgame

The clocks are running out of time and there are only few pieces left on the board. You have simplified down and have a positional advantage. Will you push that passed pawn down the file and promote to a queen? Do you have enough stamina left at this point?

Construct a back-up plan for your decommissioning project

Despite collective efforts to move away from your application or platform, it's possible that not all parties will conform to your planning and will meet the deadline. It's now that you must construct a back-up plan to cater for certain use cases or assets that require more time to be removed. But at this point the field should almost be cleared, most data feeds halted, allowing you to give extra attention to those last remainders.

Do you see a good move? Or perhaps a line of moves that leads to the winning move? Check!

Complete the decom project in The Grand Finale

Depending on the size and magnitude of this decommissioning project, you have likely stretched the fabric of your organization about as far as it can go. The last users and their traces have been removed. You are now ready to terminate the license and activate the assets clean-up runbook. Take the time to evaluate, especially if it was an enterprise-wide effort. And don’t forget to broadly celebrate your achievement.

You have arrived at the grand finale: Checkmate!