Incrementally Modernising Legacy Software: A Love Story
Understanding the legacy modernisation challenge
You know that feeling? The one where you look at your company’s core software, the thing that keeps the lights on and the wheels turning, and you think, “Bless its heart, it’s seen better days.” That is legacy software. It’s the comfortable, slightly-too-worn armchair of your IT infrastructure – familiar, reliable (mostly!). Maybe not the best look for the modern age.
These old systems, built up over years like sedimentary rock layers of business logic and workflows, can feel like they’re held together with duct tape and good intentions sometimes, a challenge explored in research on legacy system modernisation. And let’s be honest, keeping them running can cost an arm and a leg. Trying to make them do new tricks? Forget about it – they’re about as agile as a sleepy sloth after Sunday dinner.
Facing legacy software challenges? Talk to our experts about a tailored incremental modernisation plan.
We covered one of the primary strategies used to tackle legacy systems, which we refer to as the Big Rebuild, involving starting anew. Another strategy, our personal favourite, is where you show your software some love and incrementally improve it over time. Incremental modernisation is not always an option, so let’s start with a number of technical must-haves.
Technical Requirements Before Starting an Incremental Modernisation Approach
1. Ownership of the source code
This seems pretty obvious but in a small but significant number of cases we have found that companies that think they own the software they use don’t. Often, by contractual terms, the intellectual property for some or all of the code remains with the original developer. This is much more common with older software development contracts. It is worth finding out where you stand as you obviously can’t work on software you don’t own, or at least have permission from the owner.
If you don’t own the software, your first option is to negotiate with the owner to acquire ownership. This negotiation process can involve discussing terms such as licensing agreements, usage rights, and potentially purchasing the software outright. By engaging in open communication and outlining your needs and intentions clearly, you may be able to reach a mutually beneficial agreement with the software owner.
2. Access to the source code
This might sound like the same as owning the code but it is not. Having access to the software most likely means you have access to the source code too if the software is written in an interpreted development language, such as PHP. If your development language is compiled, for example C#, then the software does not mean you have access to the source code. There are sometimes ways to decompile software back into the source code but they are messy and should mostly be avoided where possible. Think of it like trying to unbake a cake!
3. Viable Upgrade Path
This is not vital but can seriously impact the complexity and cost of the incremental upgrade approach. The question to ask is what language is your current software in and what does that mean for your approach to upgrades? For example, if you developed in an outdated version of PHP, then you could do the modernisation in the latest version of PHP. That, on the face of it, is a viable upgrade path. On the other hand, if you developed the software in COBOL, then the upgrade path would involve moving to a different platform on top of upgrading the software. There are real challenges in this, not least finding a developer that can deal in both the languages. It would mean the complexity of the project and the cost are likely to be higher.
Ready to give your legacy software the love it needs? Download our Legacy Software checklist today!
What Steps are Needed for Incrementally Modernising Legacy Software?
Before you dive headfirst into code, you need a solid plan. Skipping this step is like trying to build IKEA furniture without the instructions – you’ll end up with something… vaguely furniture-shaped, probably with a few random screws left over. To avoid that do this:
Comprehensive Assessment of the Current Legacy System: This is the foundational step. You need a deep understanding of the existing system, going beyond just the technology. This includes:
- Business Fit and Value: How well does the legacy system currently support business objectives, and what is its overall value to the organisation?
- Technical Analysis: Covered in the section above.
- Performance and Scalability: Analyse current performance bottlenecks and assess the system’s ability to handle future growth and evolving demands.
- Security and Compliance: Identify vulnerabilities and determine if the system meets current regulatory and security standards.
- Cost Analysis: Understand the true cost of maintaining the current system, including infrastructure, support, and the difficulty of finding skilled personnel.
- Documentation and Knowledge: Assess the availability and accuracy of documentation and understand the level of institutional knowledge about the system.
- User Feedback: Gather input from end-users on usability, functionality gaps, and pain points.
Clear Definition of Business Objectives and Goals: Modernisation should not be done for technology’s sake. You need to clearly articulate why you are modernising and what you hope to achieve. This could include improving efficiency, enhancing security, enabling new features, reducing costs, or improving user experience. These objectives will guide your strategy and help measure success.
Identification of Stakeholders and Securing Buy-in: Identify all individuals and teams who interact with or are impacted by the legacy system, including business leaders, IT staff, and end-users. Gaining their support and involving them in the process is critical for successful adoption and change management.
Understanding of Available Modernisation Strategies: Familiarise yourself with different incremental modernisation approaches and understand when each is most appropriate. This knowledge will help you select the right strategy or combination of strategies for your specific system and objectives.
Evaluation of the Target Technology Landscape: Research and understand the modern technologies, platforms (e.g., cloud). Also research the tools that could be used in the modernised system. Assess their compatibility with your existing environment and future needs.
Preliminary Risk Assessment: Identify potential risks associated with the incremental modernisation process. These can include data migration challenges, integration issues, resistance to change, and the possibility of unexpected complexities. Having an initial understanding of these risks allows for proactive mitigation planning.
Resource and Budget Estimation: While a detailed plan will come later, having a preliminary estimate of the resources (personnel, tools, infrastructure) and budget required for the incremental upgrade is necessary to determine feasibility and secure funding.
By taking these steps before embarking on incremental upgrades, organisations can approach the modernisation process with a clear understanding of their starting point, desired outcomes, and the most effective path forward. As you would expect from a hybrid approach, aspects of both maintenance and rebuild will take place, normally at the same time. As with all development, one of the first things that needs to be done is a review of the current software.
The above will allow a plan to be drawn up concentrating on the most pressing issues first. We have seen (and probably tried ourselves!) to avoid doing the above and set out with the intention of when we fix a bug, we bring that part of the code up to date. It rarely, if ever, works. The big problem is that bugs tend to be urgent. The time pressure means that the quickest solution, just fixing it, is the one people take. The incremental improvements never happen. This can also lead to one of the disadvantages we point out below. Parts of the software that work, never get upgraded.
So, a priority based plan of action that covers the whole software is the way to go. Depending on the age of the legacy software one of the first things is to upgrade the stack that the current framework and application works on. The idea being that where possible it is better to have everything running on the same platform. Not least to avoid the expense of running more servers.
The process is defined by the plan. You will keep fixing bugs, keep the software running and alongside that bringing your software up to date.
Don’t know where to get started on your modernisation project plan? Contact us and we will guide you through all the steps above.
What are the pros of incremental modernisation?
- Reduced Risk: By breaking down the modernisation into smaller phases, the overall risk of a complete project failure is significantly reduced. Issues can be identified and addressed in smaller, more manageable chunks.
- Lower Initial Cost: Incremental modernisation typically requires less upfront investment compared to a complete rebuild, making it more financially feasible for many organisations.
- Faster Time to Value (Quicker ROI): Delivering modernised components or functionalities in stages allows the business to start realising benefits and a return on investment sooner.
- Business Continuity and Minimal Disruption: The phased approach allows the legacy system to remain operational while new components are being developed and integrated, minimising disruption to daily business activities.
- Flexibility and Adaptability: The incremental nature allows for adjustments to the plan and scope based on feedback, changing business requirements, or lessons learned during earlier phases.
- Improved User Adoption: Users are introduced to changes gradually, allowing for easier adaptation and providing opportunities for feedback that can be incorporated into subsequent phases.
- Knowledge Retention: Incremental modernisation helps preserve the valuable business logic and institutional knowledge embedded in the legacy system, reducing the risk of losing critical functionality during a complete rewrite.
- Opportunities for Early Testing and Feedback: Each phase allows for thorough testing and gathering feedback from users and stakeholders, ensuring the modernised components meet their needs.
- Better Resource Management: Resources can be allocated and managed more effectively across smaller, defined project phases.
- Reduced Technical Debt Gradually: While not eliminating all technical debt at once, incremental modernisation allows for targeted refactoring and modernisation efforts that gradually reduce technical debt over time.
What are the cons of incremental modernisation?
- Potential for Increased Complexity: Managing the coexistence and integration of legacy and modernised components can be complex, requiring careful planning and robust interfaces.
- Maintaining Data Consistency: Ensuring data integrity and consistency between the old and new parts of the system throughout the transition can be challenging.
- Need for Scaffolding Code: Temporary code or layers may be needed to bridge the gap between legacy and modern components, which will eventually be discarded.
- Can Be a Longer Process Overall: While time to value is faster for individual components, the complete modernisation of a large, complex legacy system incrementally can take a significant amount of time.
- Risk of “Never-Ending” Project: Without clear objectives and a well-defined roadmap, incremental modernisation can sometimes feel like a never-ending project.
- Potential for Inconsistent Architecture: If not managed carefully, different incremental phases might result in an inconsistent overall system architecture.
- Requires Strong Governance and Planning: Success relies heavily on rigorous planning, dependency management, and strong governance across all phases.
- Challenges in Finding Expertise: Finding professionals with expertise in both the legacy technology and the modern technologies being adopted can sometimes be difficult.
Risk management in incremental migration
Risk management is a crucial aspect of any incremental migration strategy. While incremental approaches inherently reduce the risk associated with big-bang migrations, organisations must still implement specific practices to further enhance their chances of success.
One effective strategy is to maintain business continuity throughout the data migration process. This can be achieved by ensuring comprehensive rollback capabilities, allowing organisations to revert to proven legacy functionality in case of issues with new implementations. Additionally, staged deployments can help limit the scope of changes reaching production, thus reducing potential impacts.
Organisations should implement robust monitoring systems to identify unexpected behaviours in both legacy and modern components swiftly. By focusing on both technical metrics and business process outcomes, companies can ensure that their modernisation efforts do not disrupt critical operations while achieving their desired goals.
Summary
We hope it comes across how much in favour of this approach we are for being legacy code up to date. A well researched and thought out plan can make it the most painless of the options we have discussed in the last few posts and it delivers real value by having a big benefit for the cash flow of a business. If you would like to explore how to incrementally improve your legacy software then please get in touch.
Remember if you give your legacy software some love it will continue to support your business for a long time to come.
Read more of our legacy posts here and don’t forget to get your copy of our Legacy Software checklist.
