From Old to New — Case Study, Part 1 — The Effort
The story of migrating an obsolete web application to a modern stack, progressively
We had a monolith obsolete web application, with an ancient and unmaintained stack, very bad code design and bug fixes that produce either new bugs or regressions. In this series of posts, I’ll describe the migration steps.
I recently finished a consulting position for a customer, and I feel that what we built was good enough to share, especially since I see the same scenario a lot these days.
We had an old product — a monolith — with old technologies and bad architecture design which led to performance problems and memory leaks.
On top of that, since the code was a big spaghetti bowl, we had some real engineering problems like bug fixing that caused more bugs and new features implementation velocity was 5 times slower than it should be.
I joined to fix all the above under my leadership and in this series of posts, I will describe what we did:
- The effort — What we had to accomplish
- Solution Architecture — How we evaluated different approaches and what was the approach we went with
- The process of transitioning tasks from Designers to Engineering
- Technological choices — How we chose the tech stack
- Show & Tell — See each part of the building blocks in action!
This will be a long journey across multiple parts (not sure how many), so come join the ride!
The Effort
Like I said above — we had a monolith obsolete web application, implemented with an ancient and unmaintained stack, very bad code design that caused development velocity to be at least 5 times slower than it should have, and bug fixes that produces either new bugs or regressions.
Everything was intertwined like a big, smelly, rotten bowl of spaghetti. It was time to … Uhhmmm… cook a new dish, so to speak…
So, I joined to re-architecture the product and come up with a new approach — one that will be modern and have room to grow and update as technologies update.
However, we had some constraints.
Old and New
First and foremost — the old product was being used by paying customers.
This meant that we could not just stop development on the old product and concentrate on the rewrite. New and old had to live together and the architecture and approach had to support the transition from old to new in a progressive way, slowly and carefully, in bite-size chunks.
More importantly — it had to be transparent to the users. We had to make it so that the users wouldn't know whether they are working with old or new.
Sure, there were going to be some UX changes as the experience gets a facelift, but users are not expected to navigate back and forth between 2 separate applications and their workflow must not change.
Modernize the stack
Lessons learned, people!
We wanted to introduce a modern tech stack and architecture that promote velocity without sacrificing quality.
This is important for product resiliency, of course. But it is also very important for the people working on the product and by extension — for the company.
A modern tech stack gives us confidence that it will be relevant for years to come. Sure, technologies come and go, but a resilient architecture takes that into consideration, and unless something really major happens (like deprecating React), wrappers and safeguards put in place will protect us and allow the reaction to changes with minimal effort. I will demonstrate this in great detail in upcoming parts of the series.
Product resiliency is important. However, the people — the ones that create it, are also very important.
Most developers care a lot about the technologies they work on. This means that a modern stack — one that is cutting edge (but not bleeding, this is not a POC after all) — will keep developers happy and interested and also make it easier for the company to grow in numbers.
So the main takeaway here is, that when we are required to choose a technology, it is not only a technical decision.
We also must consider things like:
- What is right for the product and its requirements? Do the features it provides align with the product’s needs?
- How big is the community around it? Is it well-supported and widely adopted?
- How rich and detailed is the documentation?
- How easy will it be to override parts of it if it becomes necessary? If you are unsure — do a small POC and gain confidence
- How steep is the learning curve? Will new team members have a hard time onboarding?
- What are the alternatives? Research and compare!
So, this was the effort we faced. It is challenging but also very common these days. This is why I want to share what we did, in hopes it will help you tackle something similar.
In the next part, I will go over the process we defined for tasks — how they propagate from product and UI/UX designers down to engineering and what should be well defined along the way, for the process to be lean, efficient, and predictable.
