Migrate Existing M1 Customer to M2

Backend Estimations


We got the task to estimate a migration of Björn Borg to Magento 2, here is how we attacked the issues and what we learned from it.

First thing to do is to explain to the customer that this is not a simple conversion, it basically means writing the entire thing from scratch, with other base modules and a new theme. So it’s a large project, however you choose to look at it.


Step 1 – Create a list of all installed modules

When the list is complete, you are pretty sure you won’t miss any features (we assume the M1 site is an AJA project).

Add all modules to a document. In Björn Borgs case it was over 110…

Step 2 – Create a list of major functions

Look both at frontend and backend, make a list of what you think are major features.

Major features could be: Integrations, Checkout, Payment and Shipping methods used, custom modules, Themes, External modules used for example Search etc

Now take each major function and add the modules you think belong to that major function, for example like this:


Modules involved





Integration code for Björn Borg




Binding certain attributes to a smaller set ot attributes


Same as above, but for categories


Runs tasks at convenient times






Toolkit to bind configurable products to simple products

Step 3 – Examine the list of modules not included in any major function

Make a list of all modules to remove, you can make one for frontend and one for backend.

In that list you place all frontend support modules, for example page manager, quick view, wysiwyg, jquerypack etc

All backend tool modules, such as default, redis, mlib, utils goes on the list

All modules that are installed but not used, for example payment methods, goes on the same list

Step 4 – Examine the list of modules now remaining

Go through all remaining modules one by one, figure out if they are needed and in use. If you are unsure, discuss with the customer if they think they use it. Move any modules no longer used to the list of modules to exclude, with a comment why.

Split the remaining modules into two lists, modules that we already have a M2 replacements for and modules that don’t.

The large task there is to find the modules, which will be a smaller task if we keep the M2 module list up to date.

Step 5 – The customer specific module

All installations have their own highly custom module called something with their name, in our example Vaimo_BjornBorg. It is a collector for many minor and some major features, that just isn’t large enough to end up in it’s own module. This module is usually very difficult to estimate. The important part is to exclude all frontend type of code when considering the size of this module. Any frontend requirement for M2 will be very different from M1, frontend support modules should be treated as a blank page.

Björn Borg custom module was filled with Widgets, triggers, mini routines etc. You can sit down and estimate each features if you want, but I did not, I made that a time bank type of estimate. This time bank should be used for supporting frontend and to transfer all those mini backend functions they really do use and need. That time bank can not be a fixed amount that you aren’t allowed to pass, it should simply be a “we are confident it will be enough, but if we see we will pass this limit, we need to have another meeting”, type of time bank…

Step 6 – Frontend

The theme for M2 will be a brand new one, all the tools we use to build the new theme will have nothing in common with the old M1 installations. That’s why frontends estimate will be very important and also very tricky.

Therefore, any modules or major functions related to Theme, Checkout or Ajax features, should simply not be part of the backend estimate. It makes no sense. They should be kept in the document, for reference, but it should be clear that these modules and major features will be part of the Theme/UX estimates.

Step 7 – Finalise module list

If you follow the above mentioned steps, not only will you now have all modules in neat little lists, you can not have missed any, which is very important.

Now each module and major function needs an explanation and a comment on how to attack the rewrite to Magento 2. Following the integration example mentioned above:


Integration with Navision. Exporting orders, importing products, shipments and stock levels.

Rewrite to Magento 2

Using vaimo/module-integration-base as the core toolkit we will write this custom integration from scratch, with the knowledge of the existing formats in mind. If Navision can change the format to work with our standard XML formats, the estimates made for the integration will be substantially reduced. 

Step 8 – Data Migration

Moving from M1 to M2 is a little bit of a nightmare. Magento has built a migration tool that I have just looked at very briefly, but judging by some comments, it’s not the solution to everyones problem. It can help, but it won’t solve everything… My estimates on this could be very wrong.

I have suggested to migrate non-transactional data, such as Products, Categories, Customers, Stores etc. URL Rewrites is also part of this “core” type migration. Price Rules are usually not that many to make a migration for, so I suggested to transfer them manually.

I also suggested we do NOT migrate any transactional data, such as Orders, Payments, Invoices, Shipments and Quotes. One very important point here is payment methods. You are unable to open an order if the payment method it was placed with, is not available in Magento. Some payment methods will change, some are called different even if they are the same etc. So actually moving orders might just prove contra productive, since you can’t open them anyway… And even if you could, the payment method you have for M2, might not work the same way as it did in M1, so you probably won’t be able to capture or credit anything placed in M1.

To solve that, I recommended that we keep the M1 site running, behind password protection, to ship and capture manually, until all orders are dealt with. Future credit notes on old orders can either be dealt with inside the payment gateways, or in the old installation. The integration will NOT be up between old site and their ERP, all this has to be done manually, during the transition period.

I urge anyone to have any actual hands on experience with the Magento Conversion tool to spread some wisdom of it’s quality.

Step 9 – Estimation

 Each major function will get it’s own estimate, same with the list of modules that are needed but haven’t yet been written for M2. You should also try and find external modules that might solve things in a similar way, that might be an option to use, instead of migrating an old Icommerce module to M2.

After working a little bit with Magento 2 I noticed that working locally is a lot slower than working with M1, it’s also new code to most people, so do not be optimistic on your estimates. I usually am, but in my two M2 estimations so for, I have taken the estimate I might consider for M1, increased it a little and then increased it some more… Well, not in all situations, but pretty much. When we get more experience, the estimates will go down I’m sure, but no good will come from being optimistic when estimating M2 projects. Especially if the team is new to M2.

It is not simply an update of a site, it is a lot closer to a brand new installation than it is an update, therefore we should treat it as such as well, also in our estimates.

Give the customers choices in the estimations, for example option 1 is for Vaimo to build module X while option 2 could be for the customer to purchase the official module XY that probably does the same, but slightly different.

Step 10 – Confere

Discuss your estimates with a colleague, explain why your estimates are as they are, double check that all modules you say doesn’t exist in M2 in fact doesn’t (and of course vice versa). Feedback from someone else is very important and can give good insights of things you might have missed.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s