Modernize legacy systems or replace them: The debate continues

As the budget debate rages on across government, every agency CIO faces the inevitable challenge of significant budget cuts in IT and the systems and programs IT supports. Although there is no easy fix to eliminate the trillions of dollars required to get the U.S. out of debt, the federal technology community must take a stand by embracing real, tangible cost savings initiatives. Dealing with legacy systems and applications is a potential solution, but the decision to modernize versus replace must be carefully weighed.

It is clear that CIOs are going to have to seriously consider replacing or modernizing legacy systems – but how do they decide?  What criteria should be considered?  And, most importantly, what effect will the decision have on the agency and the mission?  The most important task for any CIO is to determine the cost and the risk associated with replacing or modernizing legacy systems and applications.

In the current economic environment, cost has to be the top consideration for CIOs. The cost associated with a decision to modernize, replace, or simply do nothing can vary significantly. Doing nothing is often simply too risky and the continued operation and maintenance costs do not help cut spending. In my experience, a complete replacement runs six times to 10 times higher than the current system costs, while a rewrite/rehost runs is closer to triple or quadruple the cost. A modernization effort typically runs two times higher, but generally provides about a 50 percent decrease in those carrying costs – O&M – post modernization … leading to real cost savings.

In addition, the CIO must consider the myriad of risks associated with keeping legacy systems and applications intact, including:

1. The system or application is no longer supported by the vendor.  In the ever advancing world of technology, this scenario is all too common. The functionality or process is still working, but lack of future vendor support exposes serious risk to the system or application and business process it supports. This quite often also leads to a major cost increase for the agency.

2. The system or application is incompatible with future environments.  This is a major concern especially if the system or application is frequently used or if it is associated with a mission-critical component of the agency.

3. The system or application could cause harmful operational disruptions. This often occurs when the technology or business function it supports becomes more complex than the legacy platform intended. The old system or application is unable to run appropriately and causes significant disruption.

4. The system or application is expensive and slow to operate. This is an issue when the system or application still meets its desired business functions, but is sitting on an expensive platform and has a very antiquated development environment that is too slow to introduce required updates.

5. The business process has changed. The system or application no longer effectively meets the requirements for which it was developed as the business process has fundamentally changed or advanced, making the system or application obsolete.

Agency CIOs have an unenviable task on their hands as they attempt to maintain operational efficiencies and keep pace with technology developments, all under the watchful eye of the White House, Congress, and other budget “enforcers.”  Proper assessments of current legacy systems and applications – including cost structure and mission impact – are steps these CIOs need to take. As the budget debate rages on, so too will the debate within the CIO community. If only we had a crystal ball …      

Mary Nugent is VP of Solutions Consulting at Micro Focus where she helps customers understand how to improve the value of their applications and how to accelerate the return-on-investment.

About the Author

Mary Nugent is VP of Solutions Consulting at Micro Focus, where she helps customers understand how to improve the value of their applications and how to accelerate the return-on-investment.

Nominate Today!

Nominations for the 2018 Federal 100 Awards are now being accepted, and are due by Dec. 23. 


Reader comments

Sun, Jul 24, 2016 FrankatWork Perth Western Australia

Plan ahead and create a life-cycle when you introduce a new system/service. Make it a mandatory dependency to name the end of life before accepting/providing a new service. Define policies and bind them to recurrent review of operations. Document and publish the steps to migrate to a new service on day one of operation and update them annually. Name the owner of each service (business and IT) and work together to replace it. Continuously improve the system/service and document all changes to make it easier to migrate to a new one.

Thu, Jan 26, 2012 RayW

As Tom and Greg said, some systems need to be modernized. But others, just because they are old, do not need to go more away from the real time (as far as windows will let you) minimalist coding to the bells and whistles, use the net, maximize a super computer coding that is the rage today. They do the job fast, economically, and without the aid of a computer support staff.

Just because a program is six years old is no reason to ban it from use. Analyze what it is doing and what the side effects of trying to "modernize" it would be. And check with the real users, not some 'manager' half the world away looking at a synopsis who has probably never touched the work being reviewed.

Wed, Jan 25, 2012 Dr. Tom Love Arlington, VA

I have been responsible for replacing 9 legacy systems with a modern architecture and design over the last 14 years. We have found that the O&M costs of a new system are 5 to 20 times less than the costs of the legacy system. In one case at scale, 11 million lines of legacy code were replaced by half a million lines of new code. The key is to re-engineer the legacy system, decommission it, and only then begin to add new functionality. It requires discipline but it radically reduces risk. Using this re-engineering approach all 9 re-engineering project were completed on time, on spec and within budget. Of course these re-engineering projects must use agile methods with continuous empowered user involvement, state of the art quality approaches, and extreme co-location of the development team. By doing this combination of best practices the ROI may be measured in months and much needed new functionality may be added in days not months.

Wed, Jan 25, 2012 Greg Ga

Legacy systems generally are not real time or web based. The processes we use are written around those limitations. Some people understand that we do things at certain times because we have learned to work with the legacy systems, i.e. we have become accustomed to getting an end of the month report that might represent the situation on the 15th of the month - that is, provided that any changes were entered in the correct legacy system. Otherwise the data was overwritten and needs to be done again in the correct system before midnight on the 10th of the month.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group