What happens when organizations stop kicking the can down the road?

Key learnings from an on-going legacy decommissioning transformation

The term “legacy systems” dates to the early 1990s where it was described as systems relating to or being a previous outdated computer system. In 1995 another, arguably more accurate, description was coined; large software systems that we don’t know how to cope with but are vital to our organization. Around 30 years’ later, this latter description fits that of many IT systems in company portfolios today. However, this situation is changing as organizations begin to explore options for modernizing or completely decommissioning their legacy systems and reducing technical debt. In fact, recent research shows that IT executives find “dependency on legacy systems” as one of the top challenges in pursuing digital transformation.

In the following article, we offer an updated view of the ever-present topic of legacy decommissioning and share key learnings from an on-going legacy decommissioning project driven by Capgemini Denmark in partnership with a large Danish retailer.

The classic dilemma: when to stop kicking the can down the road?

It’s a perennial challenge for IT executives and decision makers: how to deal with aging IT systems and the issues that naturally arise when you have them in your IT portfolio. You can’t simply throw out your legacy systems. After all, legacy systems often provide a stable backbone maintaining a high amount of organizational knowledge usually supporting key business processes. They’re also typically mainframe-based and written in old programming languages, such as FOTRAN and COBOL. Moreover, the systems have been built over many years, making them complex and intertwined with large parts of the IT landscape and therefore difficult to get out of. All good reasons to keep “kicking the can down the road” and maintain them in their current setup.

On the other hand, legacy systems are also characterized by attributes that create a case for modernization and decommissioning. In our experience, these challenges include sourcing talent, keeping documentation up to date, difficulties in responding to changing requirements, and integration issues.

The arrival of COVID-19 has increased the pressure on organizations’ legacy systems, further accelerating the business case for decommissioning. This holds true for the supply chain area (among others), where supply chain planners are lacking agility and visibility across their global supply chain due to outdated tools and manual processes. We have had clear demonstrations of how this impairs their ability to respond to a volatile customer demand and broken links in the value chain. As an example, at the beginning of the pandemic outbreak in April 2020, the state of New Jersey experienced a massive increase in unemployment claims. This overloaded an old COBOL-based unemployment insurance system, leading to a desperate need for COBOL programmers.

In light of the above, it is no surprise that we have seen an increasing volume of organizations deciding to stop kicking the can down the road and initiating a legacy decommissioning journey. Typically, this is approached in three different ways:

• Slimming the legacy: Keeping the legacy but reducing its cost and footprint by offshoring resources, optimizing the CPUs, and offloading workloads
• Modernize the legacy: Modernizing the legacy by refactoring services, building APIs on top, and enabling agility with DevOps and Agile application lifecycle practices
• Exiting the legacy: Totally decommission the legacy by replacing and re-engineering existing services with modern cloud-native systems

Good arguments exist for each approach, so IT decision-makers must examine these and understand what is right for them in their context.  

Learnings from an on-going legacy exit – how to overcome complexity and lock in scope

In the case of a large Danish retailer, the decision was taken to venture out on a legacy exit journey. The company worked with Capgemini to decommission its large legacy Lotus Notes landscape, which consisted of +2000 Notes databases. Lotus Notes applications formed a core support component in the retailer’s critical business processes, including direct to customer processes, HR, procurement, distribution and critical infrastructure.

The initiative was initiated as part of an organization-wide IT transformation journey – whereby the main goal was to expand the utilization of selected strategic IT platforms and decommission all legacy. In addition, the retailer faced several classical issues related to running legacy systems, which included:

• Business-critical applications were located on an increasingly complex platform and there was high accountability on the part of a decreasing handful of employees
• There was a limited talent pool from which to source new employees capable of running and developing the platform
• It had become increasingly difficult to extend the system with modern applications and required a high level of customization
• Slow and low performance increased employee inefficiency and hampered productivity

The retailer wanted a partner with experience in some of the common pitfalls and challenges when dealing with large and complex IT landscapes. These challenges included difficulties in getting an overview of the migration scope, setting up the right process around migrating, and decommissioning the legacy (see Figure 1). Consequently, the retailer entered a partnership with Capgemini to combine internal and external resources to structure the migration and subsequent decommissioning.

The project ran in phases, with phase 1 seeing the combined project group conducting a complete overview of all servers in the portfolio. The use of automated scanning tools meant this was achieved fast and efficiently.

Based on the output of this analysis, the project group categorized databases in terms of activity and criticality based on attributes such as:

• Last used
• Number of reads and writes
• Size
• Number of documents

This gave the retailer a comprehensive overview and a foundation for determining which databases to migrate and which to retire.

The databases in scope for migration were further categorized as either simple or complex. In this instance, simple databases contained a relatively low amount of data and simple functionality (e.g., storing the employee handbook), while the complex databases supported more advanced functionality (e.g., marketing campaign management).

After the initial analysis in Phase 1, further activity incorporated:

• Phase 2: Detailing the migration governance and creating a roadmap for complex databases
• Phase: Driving migration of simple databases resulting in a quick proof of value Phase 4: Building on the activity in Phase 2, this phase was initiated to execute the migration roadmap of complex databases. Taking this approach ensured both a fast realization of value and a solid foundation for the complex migrations (see Figure 2).

The project is still ongoing and, currently, Phase 3 (simple database migration) is about to conclude, while the first spin-off projects in Phase 4 will soon be executed.

Throughout this transformation, the project group has relied on Capgemini’s offshore Migration Factory to drive cost-efficient migration at scale. Further, our battle-tested and proven governance structures have been utilized to run the end-to-end process, from selecting databases for migration to final approval and user acceptance.

While the decommissioning journey is far from over, the retailer has already incurred a range of benefits:

• End-to-end fact-based overview of its landscape, which has determined the migration scope
• Faster and safer overall legacy decommissioning process due to Capgemini’s experience, tools, and methodologies, which combined to reduce both risks and business disruption
• Same or lower cost by reducing time to decommission and freeing up internal resources to focus efforts on business support.

As this successful change program demonstrates, when companies decide to stop kicking that legacy can down the road, they must follow through on their decision wholeheartedly. This means allocating the time and resources needed by such an endeavor. With standardized tools and processes, the transformation journey to a modern IT landscape can go from being complex and opaque to manageable and clear.

About the author

Rasmus Madsen Senior Associate Consultant, Capgemini Denmark

Christian Ansbjerg Senior Associate Consultant, Capgemini Denmark