Legacy System Retirement Projects: Reducing Risks with Business Objectives and Business Process KPIs

ArgonDigital - enterprise automation experts

Share This Post

Business Objectives that are rigorously clarified and defined before initiating a legacy retirement project may show the project is not in fact needed.

There are numerous reasons a business may elect to retire a legacy system, some of which may be harmful to a business. Adopting a new technology because it’s what the competition is doing, or politically driven system adoptions, are legacy retirement reasons that typically do not add value. In fact, they will more likely cost the organization a significant amount of money with little return on investment.

On the other hand, retiring a legacy system to meet regulatory requirements, to reduce licensing and maintenance fees, or to add additional/improved functionality that adds business value, are all reasons that generally do add value to an organization.

What are some good reasons for legacy retirement?

  • Compliance. A ArgonDigital client ran the risks of fines and sanctions due to existing software not being ICD-10 compliant (October 1, 2013) or Version 5010 compliant (January 1, 2012). In addition, the current software was expensive to maintain and is no longer supported.
  • Redundancy. A ArgonDigital client had implemented an ERP system 30 years ago. Over the last ten years, the client developed new ERP software as part of their product offering. Since the organization was now
    essentially running their competitor’s legacy ERP system, they chose to retire that system and use ERP they developed.

The legacy system retirement will be valuable if you have a net overall improvement as shown by KPIs by business process.
If there are good reasons to proceed, use KPIs to maintain business throughput. An organization typically replaces a legacy system with one that executes the existing business processes more efficiently.

Your teams can use Key Performance Indicators (KPIs) on existing processes to help determine which are business-critical and must stay as is, which can be modified with no negative impact.

KPIs should be used to measure the business impact of activities performed in the existing system, thereby allowing the business to set a target measurement for the new system.

The goal is to maintain business throughput on the most important business processes. However, while improving some part of the organization, you might actually degrade performance in another. The legacy retirement will still be valuable if you have a net overall improvement in the organization.

It is important to assess legacy retirement success by the net impact on the business, rather than by considering whether every KPI in every part of the business is improved. This holistic approach is important because individual departments or users might resist retiring the legacy system if it increases their work burden. By illustrating the improvement in the overall business results, even resistant adopters can understand the overall value of the legacy retirement.

For example, ArgonDigital worked with a health insurance organization that upgraded their claims processing system to a new COTS system. The new system degraded the KPIs for multiple departmental processes yet still improved the primary organizational KPI (administrative cost per member) by 100%!

We recently published a briefing on legacy retirement that included an organization self-assessment. You may find this useful even if your organization is already moving forward with legacy retirement.

Organization Self-Assessment for Legacy Retirement Readiness

  1. Do you have the business processes documented, and KPIs defined and prioritized on those processes? Do you know which business processes are critical for the business and cannot break?
  2. Do you have well-defined business objectives and use them to prioritize potential new features to be implemented?
  3. Do you have a strong partnership with your users business, and can you help ensure the new solution is valid as part of ensuring adoption?
  4. Does your business analyst team partner as business architects with your organization’s enterprise architects?
  5. Are your business analyst teams prepared to thoroughly elicit and manage legacy replacement requirements to reduce roll-back risk?
  6. Do you have enough senior business analysts with experience in legacy replacement projects to lead, coach, and support other business analysts, and to ensure development and QA/testing have what they need to succeed?

More To Explore