When Should You Revamp a Legacy System?
Questions to ask for a successful legacy system revamp
Every organization has legacy systems, and at some point, they hit a wall and demand a revamp. I want to share some lessons I've learned since joining a new organization and taking charge of a legacy revamp project.
Why do legacy systems need a revamp?
The term "legacy system" is thrown around a lot in the field. But what exactly qualifies as a legacy system?
Wikipedia defines a legacy system as follows:
A legacy system refers to outdated technology, methodologies, computer systems, or software. It can refer to technology that is still in use today, but also includes cases where it is no longer used yet still influences modern technology.
Source: Wikipedia
"Outdated technology" doesn't just mean tech that has been used for a long time. Over time, new methodologies and systems naturally emerge to improve upon the old. A legacy system is essentially one that has been maintained without adopting these new technologies for an extended period. In practice, the term is used much more broadly—if you find yourself having to modify multiple places just to meet a simple requirement, or if scaling the program feels like pulling teeth, we usually just call it a legacy system.
At this point, clearly defining the problems of the legacy system will help you build a solid revamp strategy. Even if it feels like legacy, if it's running smoothly, revamping it might be unnecessary or low-priority for an organization with limited resources. It's incredibly easy to complain about legacy systems, so when talks of a "revamp" begin, you really need to dig into whether it's genuinely necessary and avoid kicking off an unwarranted project.
What problems does the current legacy system have?
How do those problems affect our day-to-day work?
Is that impact significant enough to prioritize over other organizational goals?
If you can't give clear answers to these questions explaining why the legacy system needs a revamp, you probably don't need one right now. "Because the tech is old," "because it's more annoying to run than newer programs," or "because the source code is messy" are just superficial reasons. You need a more concrete, comprehensive analysis of the problem.
The current legacy system is highly dependent on external services, hard to test, and slow to process.
It helps us get immediate work done, but high complexity leads to low productivity, making it hard to add new features or achieve the long-term project vision.
It's the core tool for achieving a specific, top-priority value for the organization, but system limitations prevent fast service improvements, thus necessitating a revamp.
As shown above, you need to look at it from an organization-wide and business perspective.
Every piece of software has room for improvement, but improvement tasks are often strategically and intentionally delayed based on business goals, ROI (return on investment) of resources, and task prioritization.
If it's technically lacking but still sufficient for creating and delivering business value, pushing for a revamp might just be an itch to clear out technical debt, or a sign that you haven't spotted the more critical problems that actually need solving. Therefore, deciding whether it's a problem worth solving requires a comprehensive look combining both technical debt and business perspectives.
Once you clearly define the problem, you'll get a feel for exactly what needs to be improved and how many resources it will take. Laying a solid foundation before starting the work can lead to vastly different outcomes compared to just diving in.
What exactly should be revamped?
Once you've defined the problem and decided to go ahead with the revamp, the critical first step is to organize the requirements. If you have zero understanding of the legacy system and no reference documentation, this can be agonizing. However, it's an essential process because you need to know what to improve in order to establish the right direction and strategy.
The target for the revamp could be the entire overall system, or it could be scoped down to specific areas like infrastructure improvements or code refactoring. To determine the appropriate scope, you have to understand the system and extract the areas for improvement. Don't try to figure everything out on your own—make sure to get as much help as possible from the original creators or people who know the history. There might be various hidden dependencies that aren't documented or visible in the source code.
What to do to understand the existing system
If the original creators are around, ask them for a high-level overview of the system and what the hardest parts were when building it.
Jot down any questions that come up while figuring out the system, no matter how small, and share them to ask for help.
Map out the overall execution flow of the system and pinpoint where the issues lie.
The most dangerous thing you can do is skim the source code a few times and delude yourself into thinking you know the whole system. Of course, it's practically impossible to map out every single piece of logic and dependency before you actually start the revamp work.
Even if you think you know it all, or if it looks simple, double-checking everything reduces the chances of running into a critical outage after deploying the revamped system. If you aren't sure what to look for or what questions to ask, leaning on a teammate or lead who knows the team's business history best is a great approach.
They can help you catch things you've missed and provide information on internal or external dependencies you weren't aware of. Instead of assuming, "Oh, this part is probably handled like this," and moving on, sharing even the smallest details often yields surprising amounts of help. Especially for a project like a legacy revamp, the available time is strictly fixed, but the scope of work can balloon out of control depending on your strategy or plan. Therefore, it's best to absorb and organize as much information as possible.
Once you've gathered the info, it's time to set the direction for the revamp. Here are a few examples:
Rebuild the system in a language the team is familiar with.
Keep the existing deployment infrastructure as is.
Adopt a modular structure that is easy to maintain.
Introduce Hexagonal Architecture to minimize the impact of external services.
Eliminate unnecessary data synchronization steps with external services.
When things are clearly laid out like this, it makes it much easier for your peers to share their thoughts. Share it within the team, get it reviewed to see if there's a better direction, and evolve it by incorporating their feedback.
Rebuilding the system vs. Refactoring
Deciding whether to completely rebuild the system or just refactor it is another crucial decision. If the scale of refactoring is basically equivalent to building it from scratch, and it's notoriously difficult to test, you might be better off just rebuilding it entirely. However, what you absolutely must watch out for here is compatibility with the existing system. Switching to a new system shouldn't cause a massive drop in productivity for stakeholders. You need to have thorough discussions on whether the work history and data from the old system need to be preserved or if it's fine for them to vanish, and then decide on the approach.
There is just so much to keep track of when revamping a legacy system. It helps immensely to jot down even the smallest details and periodically review those notes to ensure you haven't missed anything.
Breaking down the work into phases
Once the requirements are organized and you know exactly what needs to be improved, it's a good idea to break down the scope of work based on that information.
Divide the project into major features, list out the chunky tasks that look like they'll take some time within each feature, and set the scope of work. At DelightRoom, we work in two-week sprints. If you scope the work using the sprint cycles already used within your organization, it makes the workflow much smoother in terms of cross-team collaboration, reviews, and sharing updates.
By scoping the work just right—neither too short nor too long—and proceeding in phases (Phase 1, Phase 2, ..., Phase N), you can get feedback more frequently, and the assignees themselves can constantly verify their direction as they progress.
This approach proved incredibly useful for communication. When discussing quarterly OKRs or sharing updates with teammates, I could simply say, "The goal for this quarter is to finish Phase 2." Reviewers also get a manageable chunk of work per phase, allowing them to provide highly meaningful feedback. This is exactly why you must properly break down your tasks.
After the revamp
Once you finally cross the finish line and complete the revamp through all these stages, you can take a breather and then start steadily preparing for what's next:
Clean up remaining tasks and create action items
Identify further improvements through regular meetings with stakeholders
Reflect on what went well and what could have been better through a retrospective
Share the lessons learned with the organization
Feeling grateful to the team for dedicating the resources to revamp the legacy system, I take a moment to chart our path forward and do a retrospective on the journey we just completed. There will be things I'm proud of, and definitely things I wish I'd handled better. I face them all honestly and use them as stepping stones for growth. Next time, I'll be able to do it even better.
There might have been a better approach that I completely missed. I'm still on a journey, tackling various challenges to find that perfect method. Hoping to do even better next time, I'll wrap up this retrospective on what I learned from my past experiences.