(Image credit: Adobe Stock.)
As insurers continue to replace aging core systems, many are finding implementation is only half the battle. In order to fully realize the potential savings from core systems replacement, old systems need to be retired. Decommissioning a legacy platform isn’t a particularly glamorous process, but it is ultimately good for the health of an organization. What follows are six best practices to guide insurers through the process of legacy system retirement.
- Assign Ownership. These projects will not get priority from business users unless you have someone accountable for execution. Detailed planning, testing, and follow up will be needed over an extended period of time. Picking the right people to staff the project is key, but system retirements aren’t for everyone
- Communicate, communicate, communicate. Before going to end users, develop a communication plan and validate it with key functional leaders. The plan should focus on the expected savings and chargeback impact of the retirement, and include information about approach, timetable, replacement systems, and historical data access provisions. Analysts and project leaders need to reinforce the direction in any communications.
- Plan for retirement. Every system replacement is a move from, as well as a move to. Most implementation plans are developed to minimize implementation risks and to address immediate business problems. System retirement implications like increased exposure to support and technical risk may not be considered until it is too late.
- Know your users and use cases. Email requests for information about a system that is going to be retired three years from now are often ignored or answered superficially. The team that is responsible for planning a system retirement must be diligent and thorough in their investigation. Once you know who is using the system and what they are using it for, plan transition support carefully. Both transition and post-transition support should be considered, and staff retention plans may be necessary.
- Understand what’s happening to the historical data. It’s important to understand in depth the business process requirements for historical data access and retention, bearing in mind that audit and regulatory requirements may also come into play. This includes not just frequency of data access and expected lifetime of data, but also a downstream uses of the data, such as spreadsheet downloads and reports. Business areas outside the main line of business should not be forgotten. Alternative sources of data may exist, and if not, these considerations will determine the cost/benefit of conversion.
- Keep an eye on the contracts. The barriers to decommissioning a system are not always technical or data driven. Review contracts for package software, hardware leases, and outsourcing agreements to understand any legal and financial commitments attached to the system in question.
Taking the time to prepare the ground for decommissioning a system yields rewards in the form of a faster rundown, fewer unpleasant surprises, better staff morale, and, ultimately, quicker realization of cost savings. While the process can be daunting, appropriate preparation can help minimize the pain.