In June 2020 Magento 1 rode off into the sunset to give way to its improved version — Magento 2 — providing for better security, greater performance, and the overall ease of use. The updated platform opened up dramatic growth potential for business owners.
This served as the impetus for most Magento merchants to start migrating their online stores to stay ahead of the curve in the ecommerce market. Little did they know that Magento 2 turned out to be a completely different platform, and their migrations were a lot more complicated than what they seemed to be at first.
What merchants expected
Merchants expected migration to be similar to a regular update they’ve already dealt with many times before.
What it turned out to be
It turned out to be a much bigger deal: they couldn’t just copy/paste their theme and extensions from the original store to Magento 2, as they were not compatible with the new platform. Besides, all customizations that they had needed to be developed afresh.
It is only data that can be transferred using Magento’s official Data Migration Tool, but it’s not an easy task as the tool requires careful configuration and certain prerequisites not to screw things up.
Unless you’re tech-savvy, running the migration on your own is a bad idea — it requires programming and DevOps skills to accomplish it smoothly.
Hence, you’d be better off asking someone experienced for help. Having completed a vast number of Magento migration projects ourselves, we would like to give you some useful tips on how to plan and run your Magento migration effectively together with a third-party vendor.
Why planning matters
Magento migration is a sophisticated multi-stage process comprising the transfer of data, installation of extensions and a theme, and replication of whatever customizations you might have.
Just like when building a house, mapping out a Magento migration plan is similar to creating a construction roadmap — it’s the initial step that lays down the foundation for the success of the entire migration. Planning helps you to identify the desired goals, mitigate risks, and avoid missed deadlines.
Besides, having agreed upon a Magento migration plan with the vendor beforehand, you will eliminate any misunderstandings during the project, will reduce the likelihood of the change of requirements, and will understand the order, the entire scope of work, and the architectural choices your vendor will make.
The ABC rule
For the Magento migration plan to be effective it has to follow the ABC rule, meaning that it has to be:
A — accurate
The more details the vendor and the customer discuss and write down before the kickoff, the more likely the migration will be hassle-free.
B — bilateral
The plan has to be clear to both parties involved and take into account their interests and requirements.
C — custom
Every ecommerce business is unique, and the plan should take into account all specifics and be aligned with customers’ objectives and needs.
By following this simple rule, you will make sure that the plan you map out will provide the basis for a predictable migration to Magento 2.
Magento migration plan
There is no one-size-fits-all approach because every migration is unique. What works for one customer won’t work for the other owing to the complexity of the store, level of its customization, desired goals, and customer expectations.
As a rule, the plan should start with a brief description of customer’s business requirements, followed by an overview of the infrastructure and configuration of the current store, including its extensions and any custom functionality and data it might have. The plan should then cover all the stages inherent to the migration in question.
Each of these stages should be accompanied by a breakdown of sub-tasks to be performed within the respective stage along with the associated costs, risks, and deadlines.
1. Magento & PHP updates
As a rule, the updates of the existing store to Magento 1.9.4.5 and PHP 7.x come at a fixed price, albeit with a twist.
There is the risk inherent to these updates that should be accounted for in the Magento migration plan: a theme or any of the existing extensions might require a reinstall/update/fix as they might have compatibility issues with this version of Magento or PHP respectively. While this is usually not a problem with prominent extensions, some of the less famous ones and especially those that come from shady vendors tend to fail once the updates are complete.
Business owners should understand that these consequences can’t be foreseen and that additional efforts might be required to remedy such a situation if it occurs. These risks should be noted down in the Magento migration plan along with the per-hour costs for the fixes and the availability of the migration team to provide support if needed.
It is considered good practice to first perform test updates on the staging environment to see whether any issues arise — otherwise, chances are high that the updates will bring down a live store. Any issues that arise during the test updates, the steps for their resolution, and the efforts entailed should be documented and included in the Magento migration plan together with access credentials to the staging environment. The business owner and the migration team should also agree upon a time window when the updates will be performed on the live store and specify it in the plan.
2. Infrastructure setup
The business owner and the team should also decide upon the infrastructure the new Magento setup will require and who its legal owner will be.
It’s best to set up a separate server environment for the migrated store not to interfere with the existing one, and to have the business owner purchase the infrastructure — at the end of the day, no further transfer will be required when migration is complete. Once agreed, the parties should specify the expected configuration of the server, its setup costs and timeline in the plan, and write down access credentials if the server has already been purchased. Given that a fresh environment is opted for, a fixed price and a fixed timeframe should be expected and no major risks should be taken into account.
3. Primary database migration
The migration team and the business owner should agree upon a time window when the existing store should be put into maintenance mode in order to perform the primary database migration which will transfer the data from the existing Magento 1 store to the new Magento 2 installation.
As a rule, this is a hassle-free fixed-price process that at worst takes a few hours and brings things back to normal once complete. There are, however, risks that the existing Magento 1 database was manually altered during the course of its existence or became corrupt and that it will hinder migration. Given that nobody is able to forecast these issues unless the migration is attempted and that the remedy is unknown at the time of their occurrence, these risks should be mentioned in the plan together with the per-hour costs for the fixes and the availability of the team to engage if needed.
This part of the plan should also list all the do’s and don’ts for the business owner — the migration team should specify what entities should not be added/modified/deleted as there are risks associated with making changes to both stores during the entire migration. These have to be made explicitly clear to the owner.
4. Business logic implementation
In order to be able to specify an accurate estimate and deadlines for this stage, the migration team should perform a thorough analysis of the existing Magento 1 store and examine its configuration.
Together with the customer, they should identify which business-critical functionality and data should be migrated to Magento 2, and what new functionality should be introduced. This encompasses any existing or prospective third-party integrations, including shipping and payments.
It’s highly recommended to specify which outdated or redundant extensions among the ones that the business owner currently has should be replaced on the new store or abandoned altogether — Magento migration is a nice opportunity to get away from all the trash you’ve been carrying throughout the years.
The migration team should help the business owner create a list of existing extensions supplemented with answers to the following questions:
Do you need the functionality of this particular extension on Magento 2?
For your convenience, the list of extensions can be split into 3 columns: essential, nice-to-have, and redundant.
Are there Magento 2 alternatives to the extensions that you need or does this functionality come out of the box?
Note, that it’s preferable to purchase all or most of the extensions that you require from one extension vendor as this will allow you to avoid compatibility issues.
Is there any existing extension data that needs to be migrated?
Bear in mind, that many Magento 1 extensions don’t have a Magento 2 version. Even if there are functional alternatives from other vendors, their logic might differ from the one you’re already used to.
That’s why both sides should discuss and agree on the possibility of developing custom Magento 2 extensions where needed and include the description of their functionality in the Magento migration plan. Custom extensions are more expensive, but this investment will pay off.
Once the list of ready-made and custom extensions to be installed, and the customizations and integrations to be implemented is in place, your migration vendor will be able to specify an accurate estimate for the entire business logic in the migration plan. All that’s left to be included in this estimate is the efforts required to migrate the data of your existing extensions, if any should be migrated at all.
5. Theme installation or implementation
If there was only one misconception that business owners had about Magento migration, then it’d be that a Magento theme currently in use can be migrated to Magento 2.
Unfortunately, due to the architectural differences of the two versions of the platforms, this is not as easy as copy/pasting files from one server to another and essentially requires the development team to recreate the same theme from scratch. Hence the question: why bother trying to transfer a dated theme to Magento 2 when you can enjoy the benefits of having a brand new unique Magento theme at nearly the same cost?
Now that the idea of transferring the old theme is out of the question, it is worth considering the three options Magento business owners have when it comes to theming their migrated stores:
Installing a ready-made theme
Installing and customizing a ready-made theme
Implementing a custom Magento theme from scratch
The owner should consider the pros and cons of a ready-made theme vs. a custom theme and pick one, while the migration team should reflect this choice in the plan along with the respective costs and time involved.
The installation of a ready-made theme
This option is a fixed-price no-brainer. In the worst-case scenario, it will require the development team to implement some compatibility fixes for the extensions that don’t play well with the selected theme. Just like in the Updates stage, these risks should be noted down in the Magento migration plan along with the per-hour costs for the fixes and the availability of the team to engage if needed.
Installing and customizing a ready-made theme
This is a bad idea akin to the transfer of the existing theme from Magento 1 to Magento 2 as the depth of customizations usually required by the customers and the efforts required to implement them are very close to those required to build a brand new Magento 2 theme.
Custom Magento theme from scratch
This option is preferred. If chosen, the plan should include the timeline and costs for the design of the theme, frontend development, and any backend customizations required to implement the visual and business-logic choices made by the business owner and the design team when creating the UI and engineering the UX.
In short, some of the user interface elements or their expected behavior created by the design team and approved by the business owner will entail the need to introduce changes to the functionality of the store, which, in turn, will require additional development efforts and will increase costs.
That’s why it’s best to set the desired functionality in stone so that the development team can accurately assess the efforts required to implement the unique theme and include the estimate in the Magento migration plan.
6. Delta migration & launch
This one is usually a cakewalk unless the old Magento 1 database is corrupt and prevents delta migration.
Whatever the case, the Magento migration plan should include a 1-hour time window when delta migration and launch of the new store are performed, as the existing Magento 1 store has to be put into maintenance mode while delta migration is attempted — of course, it’s best to select the least popular hours in order to lose as few sales as possible.
The costs of the delta should be fixed and as a rule come together with the costs for the primary database migration unless unforeseen circumstances arise — then the T&M costs for the fixes should be specified. Besides, the availability of the migration team to engage if emergency post-launch support is needed should be mentioned.
Final notes
A rule of thumb is to draft a Magento migration plan which does not leave any ‘what’, ‘when’, ‘how’, and ‘what if’ questions unanswered.
In the end, the plan should help both parties stay aware of what’s happening at any given point in time during migration and should lay the foundation for hassle-free cooperation.
The better the business owner understands the process and the more efforts the migration team puts into explaining all the migration implications, peculiarities, and risks, the better the expectations of both sides are handled and, thus, the more joyful and fruitful the endeavor is.
Jan is the Chief Business Development Officer at Staylime, a Magento
design and development company headquartered in Redwood City, California.
He is responsible for developing and leading the sales and digital marketing
strategies of the company. Jan is passionate about ecommerce and Magento
in particular — throughtout the years his pieces have been featured on
Retail Dive, Hackernoon, Chief Marketer, Mobile Marketer, TMCnet, and many others.
Related serviceConsidering migration to Magento 2?
From automated database migration to functionality redevelopment and manual resolution of compatibility issues, Staylime takes on all the pains associated with upgrade to Magento 2.
This part of the plan should also list all the do’s and don’ts for the business owner — the migration team should specify what entities should not be added/modified/deleted as there are risks associated with making changes to both stores during the entire migration. These have to be made explicitly clear to the owner.
