Five Things to Consider Before You Replace a Complex Legacy Web Application
by Nicola Marcacci Rossi
Our client asked us to replace their legacy application with a more modern technology stack of our choice.
At first it might sound like an opportunity to simply pick whatever technology you always wanted to use and fulfill yourself, but it’s more complex than that.
The application regularly imported data from various sources, some of it daily and some hourly. It provided read-only access to the data via a REST API, which was used directly by various stakeholders. Additionally, it had multiple client UIs and widgets with different settings and themes, embedded in different ways in a number of websites.
Our task: take on the maintenance of the legacy application, and completely replace and modernize it, all the while making sure all stakeholders could continue relying on the application’s service and make the switch as painless as possible.
This large project has helped us greatly grow our expertise and experience. We decided to publish a case study about this big project, illustrating in a series of articles what we learned and what we deem to be good practices when transitioning a large code base.
In this first article, we will go through a few reflections you have to make if you, as a business, are considering taking on a similar project.
1. Be sure it’s worth it
As a company, there is always some risk involved in taking in an externally developed code base and reimplement it.
Remember what Robert C. Martin says about redesigns in his classic book «clean code»:
Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky. […] Now […] two teams are in a race [one of which] must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.
Yet there are still good reasons to take on such a challenge:
- The legacy stack doesn’t fit your company’s quality standards, core expertise, or philosophy, so you can’t just take over and keep the current code base
- There is a big payoff in the end, such as acquiring the knowledge embedded in the old stack, and becoming responsible for the maintenance of the new code base, with the possibility of a long-term relationship with your client
2. You need to care about the transition
You will have to understand the old system and probably add new features and fixes while you work on developing the new one. Shareholders will need support, there will be resistance and there will be delays. If there’s a challenge about such a project, it is that there are many moving parts, and the devil is in the details about the interplay of such parts.
And — you heard R. C. Martin — such an operation might take a lot of time — months or even years. During this long period of time, only people who really care will be patient enough, work hard to keep all the details in mind, think about consequences, set reminders and inform the right people at the right time.
3. Distribute your team well
Remember that the people working on the old system have to work against their own interests — they have to make themselves obsolete! It is therefore advisable that all of them have a foot in both projects, i.e. not just be responsible for the maintenance of the legacy system, but also take active part in the transition. With a team of about 6 people working for this particular customer, we had 1 person responsible for the old system and the migration (+ 1 backup), and the rest of the team working on the new stack.
4. Communicate, communicate, communicate
You will need to bring all the stakeholders along with you on the ride. They have their own projects going on with their own very real requirements, budgets and deadlines. They don’t necessarily want a change (or know that they do). You need to be able to communicate the advantages of the new system, send them links to documentations, send them customized code snippets, remind them about deadlines, and most importantly be willing to repeat yourself a lot.
5. Draw a line
The counterpart to the previous section. You don’t want the people in your team to be stuck forever with a legacy system (or have them leave in frustration with the work half-undone). When taking on such a project, be clear towards your client about how far in the future you are willing to work on the legacy system. Work with the client to define rough dates for the following milestones:
- Official deprecation of the old system
- No new features and changes
- No bug fixes
- End of support
- Shutdown of legacy system
If it is a really complex project, expect some delays. But don’t be afraid to remind them and keep pushing towards a successful transition.