Migrating From Magento 1.8 to Magento 2 — One Year After — Part 1

It’s been a little bit over a year since we migrated from Magento 1.8 to Magento 2. It has indeed been an eventful 1 year. Looking back, I have asked the question: why did we migrate? has it been worth it, would we have been better off staying with Magento 1.8.

A Brief History

When I resumed as a head of software engineering at Gloo.ng, I inherited a Magento 1.8 code base that had been worked on by different developers. Some adhered to best practices; some did not. Some highlights:

1. No version control system. All the code base was what was on the server.
2. Deployments basically through FTP.
3. Magento core code modified.
4. Several 3rd party extensions installed, some conflicting with others.
5. Non mobile-friendly User Interface.
6. No Automated Tests of any kind.

The first task was to put some structure to the code base so we had to do the following:

1. Version Control the Source Code
2. Introduce Modman and Composer

Version Control the Source Code

First approach was to commit the entire source code to a git repository. This was the quickest thing to do even though it has its downsides. The downsides include:

• Large VCS repository size and diffs when code is updated.
• Duplication of the history of all your dependencies in your own VCS.
• Adding dependencies installed via git to a git repo will show them as submodules. This is problematic because they are not real submodules, and you will run into issues.

See here for more on the downsides.

Introduce Modman and Composer

The second approach was to separate the extensions into their different repositories. This was a non-trivial task as Magento 1 stores files from different extensions in different locations throughout the code base. A tool called modman would then symlink those files into the locations they needed to be. So we successfully introduced modman into our development workflow.

This approach also saw us introducing composer. We utilized composer VCS repositories. We had a composer.json file in our project root. Each extension also had a composer.json file. That way we could handle dependencies much gracefully.
We also checked out a fresh install of Magento 1.8 and kept the core code base clean. Changes to the core that needed to be retained where either moved to the theme or custom extensions.

Why Did we Migrate?

As a result of some of the work we had done, we had better code structure. New functionalities were added as different extensions in their own git repo and symlinked to the rest of the code base using modman. We had solved 1,3,4 of the problems listed above. Again, why did we migrate?

Firstly, Our installation was based on Magento 1.8 and the theme we were using was not fully responsive and not based on newer and accessible front end technologies.

We considered the option of just getting a new theme based on Magento 1.9. We did not go with that option because we had done a lot of customization on the theme and extensions and built custom extensions and all, that utilized that theme.
So changing just the theme would have required a lot of work — the amount of work almost equivalent to what it would take to migrate to Magento 2. So we thought to ourselves, is it not better to migrate to Magento 2 instead, given that we get these other advantages:

1. An out-of-the-box Automated Testing Framework for functional and integration tests.
2. Magento Core comes with Unit/Integration Tests out of the box and quality extensions will have to follow suit.
3. Fully Responsive Theme out-of-the-box.
4. Default One-step-checkout (Two-step) — lol
5. A more optimised website with features like deferred loading of javascript.
6. Static Asset minification out of the box.
7. A website based on newer and better accessibility standards.
8. All extension files live within the extension so extensions can live within their separate GIT repository for better versioning without the need to use a tool like modman.
9. Use of php composer out of the box for dependency management.

These points were important to us as we were at the point of moving towards a more structured engineering set-up and needed to be nimble in our operations.
Also, we got to a point where we were having a lot of regression issues and modules clashing with other modules — issues that Magento 2 is engineered to avoid IF best practices are adhered to.

In Addition, we wanted a standard production setup with Auto-scaling support.

In follow up, articles, I will write on the following:

• Migration Experience
• Post Migration
• Experience so far
• Recommendations