How do you build a compelling business case for phasing out legacy tech?

990 views1 Upvote7 Comments

Director in Manufacturing, 1,001 - 5,000 employees
Our company's leadership often emphasized the importance of having a secure environment for applications that could be easily patched and supported. However, when proposing a project to reduce legacy applications, the lack of patches or support was mentioned as a justification, but never included in the ROI calculation required for project funding and approval. All of our legacy apps were replaced based on cost savings. This caused problems for some of our small ERP systems running on outdated AS/400s without proper maintenance on software or hardware. The running costs of these older apps were mainly the cost of a few legacy support staff and an outsourced hardware support contract to a third party like Capgemini, which did not include hardware. We even had to buy hard drives on EBAY! We calculated the cost of Capgemini's services, the cost of insourced or outsourced application support, and within that savings, we would either need to shut down the application completely or migrate it to SAP. Sometimes, luck was on our side and the application was in READ/ONLY mode due to a past SAP migration that did not have the funds to complete archiving of legacy data, so the old ERP system was left running. The cost to migrate the data into SQL and write some basic reports was not too much, so we could usually justify the work. In summary, if we could not justify the cost, the legacy application would continue to be used until the hardware failed or the business no longer needed the legacy ERP data, and we could shut it down. Usually, 7-10 years of legacy data is required. For some AEROSPACE and Government requirements, there are sometimes needs for the life of "part" which could have a 4-year or 40-year life. I've found that getting funding for phasing out legacy technology to be the most difficult projects to fund. You won't get much business support since most of their employees are fine using the old application to get the legacy data they need.

Start with trying to get as detailed cost of support information as possible, including human cost and hardware cost etc. Hopefully those costs are high enough to migrate to new tech and still show savings.
Board Member in Healthcare and Biotech, 1,001 - 5,000 employees
I have used business agility to new opportunities as one of the key tenets for phasing out legacy tech using data to demonstrate the time taken to make changes to legacy due to various limitations with unsupported systems, lack of skills to make changes, undocumented code, and impact to business due to the delay in providing new functionality or fixing old issues.

Cost saving is an add-on benefit in some cases.
Director of Business Development in Software, 51 - 200 employees
I usually start with providing a comprehensive financial analysis based on the costs associated with maintaining legacy systems and the potential gain of using modern solutions. In addition, it is important to consider the current technology's impact on customer service, scalability, and security. Analyse technological trends and determine how they could benefit your organization. I think the most important part of the business case is showing how transitioning to up-to-date technology will help the organization maximize their efficiency and save money in the long run.
CEO in Software, 11 - 50 employees
Most everything has been covered here already, I would just emphasize the area that I think is most important and it relates to agility and resource management/solution delivery:
Think of legacy infrastructure and applications like pulling money out of a 401K account. You pull out 1000 and pay it back over 2 years. You paid back the 1000, that's great, but what did you lose, you lost the interest created and the compounding of that interest over the remaining lifetime of your 401K account. This is money you'll never earn. 

Having critical resources allocated to something that's just "keeping the lights on" vs. some or all of those people being focused on activities (coding, learning, sharing, building, etc., etc) that further the mission and vision of the enterprise is a lost opportunity that you'll never reap the rewards from.
CIO Strategic Advisor in Services (non-Government), 2 - 10 employees
Great points but there is also a trap to avoid.

Can you use the legacy tech another day? Can you use it for another week? What about another month? And how about another year?

It is a similar problem as the frog in the boiling pot of water. The danger is the slow slide of decline over time versus stark failure. Put that in perspective with priorities in any given year and legacy tech often falls below the water line.

If you have clear cost advantages or features with value in business terms, that is great. Unfortunately, most legacy tech does not have that opportunity. Therefore the business case is much harder and complicated to navigate. Identifying risks, value and cost avoidance can help. Engaging a cross-functional team to understand and buy-in the problem is key.
CIO in Education, 1,001 - 5,000 employees
It should build itself, actually. Costs to maintain, from both a physical and human capital perspective, should be able to justify migration or transformation to a solution that is more sustainable and cost effective today.
Senior Information Security Manager in Software, 501 - 1,000 employees
Use the Equifax breach as an example.

Old technology that should have been retired, and was scheduled to be retired, was hacked before it was retired.

A project that would have cost perhaps $500,000; ended up exceeding $100 million in fines, legal fees, bad PR, and more.


Content you might like

CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
40.9k views131 Upvotes319 Comments

Limited environment/Infrastructure resources31%

Inability to quickly identify the root cause of CI/CD pipeline failures45%

Lack of standardized CI/CD pipeline templates across the organization53%

Integrating security tools - inefficient security implementation leading to false positives38%

Poor communication across business and product teams/coordination challenges26%

Cost/resource management26%

Implementation of CI/CD into on-going projects and workflows22%

Internal resistance: training issues, culture, etc.14%

Inefficient implementation of CI/CD due to lack of expertise, poor training, etc.19%

Poorly written unit and acceptance testing9%



We are not doing regression testing10%

25% manual, 75% automated50%

50% manual, 50% automated28%

100% manual, 0% automated8%

Don't know2%


1.6k views3 Upvotes2 Comments