Lawrence Fitzpatrick, Computech president, is a FedScoop contributor.
Projects to modernize legacy systems are the hardest, riskiest, most complex projects we know. Their success rate is exceedingly low (less than 20 percent), and they can cost a lot in time, talent, money and opportunity. But while the road to legacy modernization hell is paved with good intentions and notable project failures, it’s also paved with roadmaps that aren’t suited quite right for the effort.
To take the right path to legacy IT replacement success, you need to know the right steps and common pitfalls to avoid along the way.
Modernization projects are less risky when agencies leverage best practices from the community of experts specializing in this demanding field. Consider these three steps and their corresponding pitfalls.
Step 1: Choose a solution aligned to your objective
Agencies must undertake detailed analysis of the business system, the technical system and the project’s objectives before choosing a modernization approach. Whether you are modernizing to improve service, expand your mission, reduce operational costs or eliminate risks from instability, scalability, unsupported technology or dying skills, it’s essential you know exactly why you want to modernize in order to choose an appropriate approach for meeting your objectives.
Pitfall avoided: Presuming solutions are interchangeable
Depending on the agency’s application strategy and business conditions, the approach to meet replacement objectives can vary widely.
- Re-hosting may be optimal if the application is critical but static, yet suffers high infrastructure cost
- COTS replacement may make sense if the application’s capability has become commonplace in the market, and the agency is undergoing reorganization anyway
- Staff training is far cheaper than any modernization project to access legacy code skill sets
- Incremental modernization through enhanced operations and maintenance efforts can be low risk and cost effective, but will take time to complete
- Waiting is less risky if you have the time to let early adopters learn important lessons
Step 2: Hire the right skill to recommend and execute your approach
Expertise and experience matter. All of the unique attributes of legacy modernization projects must be considered in developing a roadmap for performing the replacement. Experienced teams appreciate the complexity, know what to address when and are prepared to be accountable to deliver on their recommendations.
Pitfall avoided: Presuming skills are interchangeable
Legacy modernizations are significantly unlike other software projects, and when attempted by those without legacy modernization experience, projects wind up in trouble.
Some key differences between legacy modernization and other software projects are:
- Requirements are unavailable — they are in the system code, in outdated documentation or long forgotten
- The system is already running and can’t withstand disruption
- Data has accumulated and must be migrated, with known quality
- The sequence of iterations is determined by technical and business process dependencies, not by priority
Step 3: Maintain business continuity
Determining the approach and roadmap to sequence the replacement and cutover is essential. Understanding the users, business processes, operations and data migration contribute to crafting the cutover roadmap that will minimize impact and ensure business continuity.
It’s often said sanity is defined as doing the same thing over again and expecting a different outcome. Legacy modernization success will not come from doing it the old way, just harder. Success demands a new thinking and a different approach — driven by business objectives, pursued with planning and execution rigor and managed by seasoned professionals, with a legacy modernization track record, who can ensure the plane continues flying smoothly while the engines are replaced in flight.
Pitfall avoided: Presuming it’s all about the code
Beware of approaches and estimates that focus primarily on the code. Reading, understanding and rewriting or re-architecting code — with or without the assistance of software products — is a basic programmer skill. But application code is less than one quarter of the complexity of a legacy modernization therefore plans devised by the inexperienced are often wildly inaccurate and fail to focus on critical project elements.