A client recently came to me and said, “We have this legacy software we built. We have an individual running it and they’re nearing retirement age. What do we do? This software is extremely critical to our business operations, it can’t go down.”
This is a common problem that I hear about when working with SPARK clients. Companies – from manufacturers to healthcare and financial institutions – built and invested in custom software years ago, but now they’re worried about the risks it poses to their operations. Risks like:
What happens if our developer leaves or retires?
How do we continue our company’s growth with software that isn’t using the latest and greatest technology?
What do we do when our software can’t support security updates?
Most companies fear these risks, but they’re often unsure how to solve them. What are their options? How disruptive will it be to their current operations?
In most cases, modernizing legacy software isn’t as simple as overhauling the system all at once. Instead, I recommend companies take a phased approach. Here’s why.
Understanding Legacy Software and Its Challenges
Often, when legacy software was initially developed, it was innovative to the firm’s industry and custom-made to fit their operations. Because of this, they’ve spent the last several years (as many as 10, 15, or even 20) putting their blood, sweat, and tears into that unique software.
There’s a lot of pride in what was built– as there should be! Some of the most innovative software I’ve seen has been uniquely tailored to the companies I talk to every day and I am blown away by the depth of functionality.
When you look at a legacy system from that lens, it’s clear that most companies don’t have the option to simply replace it with off-the-shelf tools. The requirements don’t match up.
The other challenge is that a legacy system is usually very ingrained in the company’s processes. You can’t simply rebuild a new system and cut over to it – it’s too disruptive.
Here’s how a phased approach can help businesses overcome those challenges.
The Modernization Roadmap: A Strategic Approach to Upgrading Your Legacy Software
When modernizing legacy systems, I’ve found that there are two ingredients you must address:
1. Ensuring business continuity
2. Creating a strategic roadmap on what to build and how
To be successful, these two ingredients must come together (and you can’t do one without the other).
This is the strategic approach that I recommend (and have seen firsthand work for companies):
1. Define Clear Objectives and Desired Outcomes
Before you embark on any software modernization journey, set clear objectives. Get down to the root of WHY you want to modernize. It can help you avoid wasted resources and future complications during your project.
When setting goals, the biggest mistake I see companies make is not focusing enough on the long-term impact. Think about what success of this journey looks like 1, 3, or 5 years. Doing so helps you align your project with your overall business goals.
2. Assess the Current State of Your Legacy Software
Have additional team members audit and document your current system for any risks or opportunities, such as identifying pain points, performance bottlenecks, and compatibility challenges.
Enlisting others to learn about your system and truly understand its risks supports business continuity. It means that the burden of supporting the old system no longer rests on the shoulders of a single person.
3. Create and Execute a Phased-Approach Project Roadmap
Taking a phased approach to modernization means taking small, intentional steps toward replacing your system – instead of cutting over to a new system all at once. You can prioritize your initiatives based on your overall budget, timeline, and scope considerations.
Building incrementally also allows you to build new functionality, while still supporting your existing processes and system. This allows you to minimize disruptions to your business during the rebuilding process.
4. Plan for Incremental Improvements and Maintenance
As you execute your roadmap, continue to evaluate risks, opportunities, and strategic direction every quarter or so. Your budget, scope, and software requirements will continue to evolve. By checking in regularly, you can continue to align your current efforts with your big-picture goals.
While you can’t fully “future-proof” your software, intentional planning can help your software evolve as needed (and you can avoid ending up in the same position again with a system you’ve outgrown).
Real-World Story: How To Modernize Your Legacy Software
So, what does this approach look like in action? Let’s circle back to the client I mentioned in the beginning.
When they came to SPARK, it might have been easy for our development team to tell them to build a whole new system for hundreds of thousands of dollars. But with our experience, we knew that another path should be considered.
So, our team guided the client through the same steps above.
Starting with Strategy & Planning (Discovery).
First, our team took a deep dive into their business goals and legacy system (SPARK calls this the Strategy and Planning phase of a project. )
During this initial discovery, we documented the client’s current system and user workflows, ensuring we understood how it worked, how to support it, and any potential roadblocks to modernization. This initiative alone gave the client peace of mind that a single individual no longer held all the knowledge of their system.
Discovery related to an existing system is not about trying to fit a client into a specific or pre-determined solution. It’s about evaluating the risks, opportunities, goals, and unique challenges a client is facing. Determining the best path forward is very unique to each situation and often a client’s budget and/or timeline dictates the options available.
Our Findings.
The SPARK team quickly saw how critical this system was to their current processes. We documented specific Risks and Opportunities and prioritized them according to our client’s established business goals.
For this project, business continuity was crucial, and we were aware of specific challenges posed by their current application. So, we took that into account when building their strategic roadmap and recommended a phased approach to building a new system.
Our Recommended Phased Approach to Modernization.
We provided recommendations to address the “low-hanging fruit” challenges that caused immediate concern regarding the operation of the current application and then focused on how we could best set up a more flexible software ecosystem for the client.
In this case, the first step was creating a new database structure. We identified that the data and data structure were key building blocks to the existing and future system state. We discovered an opportunity to separate and modernize this first. By separating out the data from their legacy system, it allowed the client to leverage their current data in a new system, while still using all of the core elements of their existing system built 10 to 15 years ago.
The best part of this approach? Now the client has options. They can build a new interface to access that data…or they can wait another year or two. Maybe, they want to start with data visualization and exploring reporting tools. By separating the data, many of those strategic decisions come down to their own budget and business goals.
With the full support of the SPARK team behind them to build and execute their roadmap, they are well on their way to modernizing their legacy system and mitigating risk to their business.
Collaborating with Trusted Partners for Successful Modernization
Need help with modernizing your systems? I’m happy to talk through your challenges and the process I outlined above. Contact me here.
At SPARK, we know that one of the best ways to reduce risk in a modernization process is to work side-by-side with tech experts and developers.
There is no reason why modernizing your legacy software has to be so daunting – just ask us how we do it here at SPARK!
