Last year we have successfully completed the migration of a legacy codebase to a completely new one. It was a gradual rewrite and replacement of the components step by step while the site was up and running.

It's been a 9 month job from the very first git commit until the shutdown of the last piece of the old site. We had a lot to experience on the run, which wouldn't fit into a single article. Therefore I will share the whole story in a series of articles, each focusing on a significant step on the road.

The Starting Point

As I mentioned we used to have a legacy codebase to start with. The legacy was mostly technical, ie. the existing site was covering the business logic quite well.

The problem laid on the fact that the old site was built with Sylius 0.17, which was only capable of running on Symfony 2.8 (more precisely on v2.8.18). Once we have upgraded Symfony to the latest 2.8 version and some crucial parts of the site started to produce errors. We've found that there was a behavior in Symfony which later the Symfony team marked as buggy and fixed it. But until that point, functionality, including libraries were built with that behavior in mind.

Thus we ended up reverting to the older (2.8.18) Symfony version.

The other major issue was that the site used to run on PHP 7.0 and upgrading to higher PHP versions has caused errors within Sylius. But the upgrade of Sylius from 0.17 to v1.0 was something we never were able to complete ourselves, due to Sylius 1.0 having a significantly different internal structure.

Thus we ended up keeping PHP 7.0 and Sylius 0.17 (including the extensive customization we wrote for it).

The Decision

The Sylius site was built back in 2016 and was running without major issues until the very last day of its operation. Sylius was great, even at its incomplete very early v0.17 stage. So why did we choose something else?

A very important factor was that beginning with 2016, the team's primary PHP framework has become Laravel. Before that Symfony and Zend were also often used. The team was ready for the switch.

In 2019 we accepted that the Sylius site can not be easily upgraded. We also had issues at changing simple things within the application due to the early and less mature parts inside the ecommerce framework.

In 2019, Vanilo 1.0 was released and we decided to opt for that. Despite the 1.0 tag, Vanilo contained less features than Sylius 0.17. But that was actually an advantage, as we needed something very unobtrusive.

We sat down and had a series of whiteboard sessions where we discussed to gradually rewrite the system on a component by component basis.

The Strategy

The most important "trick" was that our in-house Microservices Guru has told us to boot up the new system as soon as possible and start using it parallely.

It meant that we started to duplicate data in the new system
as early as the 2nd(!) sprint of the iteration. Obviously we couldn't make a "place" for all the data in the new system in 2 weeks, but everything we developed went to live and received data from the old system.

This simple thing made us to test the new things thoroughly without compromising the production systems.

Modularization

Another important aspect was that Vanilo is modular by heart. This has helped us to think in modules and take components from the old system one by one and move to the new system.

It may sound easy, but we needed to do this in a way how old system suffered as few modifications as possible. In certain cases it was not, and we had to build bridges in the old system. I will detail those in the next posts of the series.

The End Result

What we ended up having is a quite up-to-date code base, running on PHP 8.0, Laravel 8 and Vanilo 2.1.

Other than the solved technical legacy, we could streamline the search engine with an Algolia based backend (used to be a way slower ORM search).

The entire site is moving much faster now, especially the Admin area.

The old codebase was almost untouchable for the less experienced team members. The Laravel codebase means that any team member is now capable of working with it, since this has become our primary PHP toolkit.

Another big plus is the queue system of Laravel that is way more reliable.

Last but not least, getting rid of the cache hell of symfony (especially Doctrine proxies) has dramatically reduced the number of errors in Sentry.

To be continued...

Photo by Kevin Ku from Pexels