Migrating legacy projects can be challenging, but with the right approach, success is achievable. In this blog, Software Engineers Nikola du Preez and Zishan Khushi Pasha share how they migrated funda’s Listing Detail page using Vue and Nuxt3 with a small team.
Legacy projects
Do you know the feeling when the holidays are around the corner and you're hyped to set up your Christmas tree, only to find the lights are a tangled mess? After an hour or two untangling them, you notice one light is broken so you try and replace it, but when you do, another light randomly breaks. The merry feeling of hanging up the lights suddenly turns into a frustrating puzzle.
This feeling is something that every programmer who has worked on a large legacy project is familiar with, so the chance of migrating such a project to a new stack is a welcome one.
About a year ago we decided it was time to give our beloved Listing Detail page a new lease of life and bring it into the modern era using Vue and Nuxt3. Our main goal? Migrate the project in a pragmatic way while keeping our high quality standards. In this blog post we'd like to share a few things we learned along the way.
See also: How we tackled our major front-end migration to Nuxt 3.
Project background
As the platform grew over the years, so did the complexity of maintaining our pivotal Listing Detail page. The legacy codebase, which was initially robust, began to show its age. Over time, it became increasingly difficult to add new features or optimize existing ones. There were a few key reasons for this:
- Slow deployment times: Each change, no matter how small, led to a lengthy deployment process. This bottleneck made it challenging to iterate quickly and respond to user feedback or market demands.
- Limited support for new technologies: The legacy system wasn’t designed with modern web development in mind. As a result, adopting new technologies or methodologies (like server-side rendering, dynamic content loading, or caching data responses) became a daunting task.
These issues created a barrier to innovation, leaving us with a page that functioned but didn’t meet the evolving needs of our users or the business.
Realizing the need for a change, we decided to migrate the Listing Detail page from an old ASP.NET application to Vue and Nuxt 3, a cutting-edge framework that promised not only to streamline our development process but also offered a strong foundation for future enhancements. This migration wasn’t just about switching technologies, but about setting the stage for rapid innovation.
The power of a shadow team
To tackle this project, we took an unconventional approach by assembling a shadow team of 2-4 dedicated members. The term 'shadow team' refers to a small, agile team that operates independently, outside the main scrum team's regular workflow. The concept of a shadow team might seem counterintuitive for such a significant project, but it offered us several advantages and proved to be exactly what the project needed.
With only a handful of team members, we were able to work with great agility. Working in an agile manner allowed us to avoid potential pitfalls, make swift decisions without the need for lengthy discussions or approvals, and implement changes on the fly.
We focused on getting the job done efficiently and effectively by breaking the migration into manageable chunks and choosing the most pragmatic approach to tackle a task.
With fewer hands on deck, every team member had a clear understanding of their responsibilities, allowing us to power through tasks and resolve bugs. For example, we had fewer and faster meetings, allowing us to spend more time focused on actual development work rather than coordination. The close-knit nature of the team, with more focused and effective decision-making, meant that issues were identified and resolved almost as quickly as they surfaced. We could quickly iterate and adapt our strategies as new issues arose, ensuring that nothing stood in the way of our progress.
An unblocked mindset
While working on these types of projects, you often need to rely on other teams for specific aspects. That could be design-related or maybe an API that needs to be changed. In traditional workflows these are things that could prevent the finishing of a task. After all, if the design is not final, or there are properties missing on an endpoint, the acceptance criteria of a task can't be wholly fulfilled. One of the things that helped us move fast was that the main API work was already done before starting this project. Aside from a few details that had to be added to the API, we could fully focus on building the UI.
Our mindset for this project was to keep going and be fluid. If a certain aspect of a task couldn’t be finished, we still finished the rest of that task and revised it at a later stage. The goal was to never be blocked by something we couldn’t directly fix ourselves. We noticed that this way of working kept us in a high energy state, because we always kept progressing.
In production from day one
With projects as big as this, going to production is often a big moment. The bigger the project, the bigger the risk of unexpected things happening. That’s why we turned things around and decided that going to production was the first thing we wanted to do, even before any of the components on the page were built.
Going live with essentially an empty page, albeit a hidden one, allowed us to get a clear understanding of core performance and resource management in production. As we developed and added components, we could keep track of any potential bugs or performance issues and tackle those. All this meant that when the page was completed, it was already working and tested in production.
A shadow release
One of our goals with this project was to replace our existing Listing Detail page with a brand new one without users actually noticing. Since our page was already running in production but on a different URL, we could easily move some traffic to it and see the results from user feedback and performance. This approach allowed us to fine-tune the new page gradually, minimizing the risk of disruption. When we were confident that the new page was fully stable and optimized, all we had to do was flip the switch, transitioning users seamlessly to the new version without them experiencing any downtime or noticeable change in functionality.
Looking back
This project was a great testing ground to see what would happen if you broke some of the traditional workflow rules and allowed a smaller team to take a pragmatic and focused approach. We found it works amazingly well when the project is a well-defined one with a clear goal. We managed to migrate our Listing Detail page to a modern framework in a short timeframe with the commitment of just a few focused developers.
However, this doesn’t mean that a bigger team can’t work. For complex projects that involve multiple disciplines, when things aren’t as clear-cut, a larger team can provide valuable expertise and different perspectives.
Ultimately, we learned that the key to success lies in choosing the right approach for the project at hand.
See also: How funda's Team Search enhanced the saved search feature with OpenSearch
Question?
Do you have a burning question for Nikola and Zishan after reading this blog? Feel free to reach out to them via email.