Magento 1 is nearing its final days of life, while Magento 2 continues as a leader in the ecommerce landscape. Starting the process of migrating to Magento 2 can seem daunting, but it can be relatively painless if you know what to watch out for, your expectations are appropriately set, and you plan well.
We have already laid out the steps to consider during a Magento 2 data migration, but our experience has also produced some things to be aware of in your code migration for a Magento-1-to-Magento-2 project.
Each package of code should be reviewed and asked the following questions:
- Is this functionality still needed?
- Can this functionality be solved by using native features?
- Can this functionality be solved by using an extension and/or third-party API?
If the answer to these questions are yes, no, and no, then platform customization is necessary, and the following should be considered.
Migrating your integrations for customization
Both direct integrations and middleware integrations should be a part of the integration team’s toolbox.
Ensuring that a website’s integrations are successfully transitioned is a big deal. When an ecommerce site is connecting to third-party systems, such as an ERP, OMS, or WMS, there has generally been a large investment in getting those systems up and running.
Choosing the right solution for the integration will leave a lasting impact on the solution architecture for years to come. Both direct integrations and middleware integrations should be a part of your integration team’s toolbox so that the best integration option can be utilized.
For example, integrations to payment gateways and shipping-rate services are almost always done via a direct API connection. This will require skills around building HTTP requests and handling the responses in the proper ways. However, when it comes to integrating with back-end systems that do not provide easy-to-use APIs, file imports/exports and complex protocols will need to be used to get the job done.
When working with these systems, it is often the best decision to create a middleware that knows how to interact with Magento’s APIs, but can also transform the necessary data and interact with the legacy system in the proper way. By decoupling the two systems via a middleware, you gain the ability to switch out the integrated system with minimized effort later down the road.
Migrating custom code using code generation
There are a few approaches to migrating custom code. When migrating custom code from Magento 1 to Magento 2, the code-porting tools that exist are, in most cases, a bad idea.
If you are an extension developer and you just need to get your extension into the market as fast as possible, then code porting might become a viable option. When migrating code for a website implementation, these tools do not take into account Magento’s architectural patterns and best practices. They, in fact, introduce technical debt that will be an impediment as your codebase grows.
This doesn’t mean that code generation is altogether bad. For example, in areas that can be built from a boiler plate—like many administration interfaces, the base code for request controllers, or scheduled jobs—code-generation tools are a big timesaver. Using Alan Storm’s Pestle or Mage2Gen can help you get where you need to be a little bit faster than doing everything from scratch.
The reality is that custom code will take time and effort to migrate because most of it will need to be rewritten, using the Magento 1 code as a guide for your new Magento 2 site.
Magento 2 comes with multiple testing frameworks that can help you ensure that your ecommerce site is acting as expected. Test automation can be implemented at the code level and at the browser level, and should be considered when implementing a new Magento 2 site.
Automated tests are a combination of investment and insurance. They are investments because they allow you to release code later on with a much faster coding cycle. Having a net to catch you gives the ability to make changes faster and the ability to make larger, more complex changes. They act as insurance because they do cost money. While you hope the development team will never introduce bugs into the software, it’s unavoidable, and the tests will catch them before something catastrophic can happen.
Using native functionality is always ideal where the business case can be satisfied by it. However, in our experience, there are still gaps in every ecommerce platform that need to be filled by custom development.
The Magento platform gives unlimited flexibility for doing this custom development, but there is no magic bullet for getting the work done; it simply requires efficiency and skillful work. Don’t forget to always measure the estimated effort against estimated ROI. You might find out the work is not needed at all.
If you need an ecommerce partner to help walk you through migrating Magento 1 to Magento 2, reach out to us. Your continued success is our number-one goal.