Preparing for a Magento 1 to Magento 2 migration

Overall, I’d say that a lot of the initial instabilities of Magento 2 have now been resolved and the platform is now proven at most levels.

A lot of the Magento partners who were previously struggling with the transition are now far more positive and even more so around the upcoming 2.2 release. There are also now a number of known-brand Magento 2 stores on the platform – including Osprey and Helly Hansen (both launched by Vaimo), Cycle Republic (launched by The Pixel), Gear4 (launched by GPMD) and Oliver Sweeney (launched by Redbox).

Other live stores include Land Rover, Graze.com, Soak & Sleep and Venroy. 

Osprey’s website on Magento 2

One thing to bear in mind is that moving to Magento 2 is not an upgrade, but a full-scale replatforming exercise. Magento 2 bears many similarities to 1.x versions, both in the front end and the admin area, but it is fundamentally a different platform, with wholly new coding structures and database architecture.

As such, any transition to Magento 2 requires careful planning and execution. In this article, I’ve attempted to set out a basic road map for those merchants now looking to make the transition in a measured and sensitive way.

Take stock of what you have

The first step in the transition process is to conduct an assessment of your current installation. This should incorporate a functional definition of your operations, highlighting any areas that are specific to your organisation (custom extensions, integrations and workflows), areas where the Magento platform could be improved to meet your needs (and generally be more efficient) and areas where you would like to add additional functionality.

If you’re planning on moving to a new agency, you’ll need to create a more comprehensive functionality specification, especially if you’re planning on making big changes to the store.

The next part of this assessment is to identify all third-party extensions or custom modules that you have installed in your existing Magento store. If any internal records have not been kept to date, you can get an idea of the third-party extensions you’re using by going to system > config > admin > advanced > disable module output in the admin area. Your developers or agency should confirm your list of what extensions you use, by checking both community and local code pools for modules.

All third-party modules should be listed, along with the functionality they provide and whether or not they are in active use within your eCommerce operations. This is particularly important since not all third-party extensions are currently available for Magento 2 and some extension providers are taking the opportunity to ‘retire’ some older, less popular extensions. It’s worth pointing out that existing licenses for Magento 1.x extensions are not valid for Magento 2 stores, so licensing costs will need to be added to the overall project costs.

Another part of this initial assessment should be to identify any new business requirements that could be impacted by a move to Magento 2. If you have soldiered on without implementing a fully responsive design in your existing Magento store, for example, the transition to Magento 2 would provide the perfect opportunity to rectify that. Since Magento 1.x themes aren’t transferrable to Magento 2, you may as well get any desired front-end improvements in the spec to save time.

Helly Hansen’s website on Magento 2

The other thing to consider is that this represents a good opportunity to improve your product catalog setup – I’m working on two Magento 2 projects at the moment where the merchant has taken the opportunity to restructure their core product data, with a view to removing things they don’t need, adding new attributes for merchandising and changing how they use attribute sets to support more specific products.

On one of the projects I’m working on, we’ve also done a lot of working around improving some of the functions of the store as part of this project, specifically product recommendations, search, email marketing, merchandising, product reviews and building social into all of the page templates more. In order to do this, we’ve used the following:

• NOSTO for product recommendations / personalisation – this is a no-brainer really for me and the merchant. NOSTO is really easy to use and maintain and I’ve seen great results in the past. In this project we’re using it for personalised recommendations across all page templates.
• Klevu for Search – Klevu’s AI-based search solution is great for stores with big, complex catalogs and their machine learning aspect means that there’s always a second layer (based on user behaviour) to help service even the most complex queries.
• Dotmailer for email marketing – dotmailer is, again, an obvious choice with Magento because of their integration. Dotmailer allows merchants to create workflows based on the data you have against a customer record in Magento (which is really valuable), as well as your product data. Dotmailer also integrates with Klevu and NOSTO to get more data on the best products to promote to specific users.
• Visual merchandiser for merchandising – this solution has been re-built in Magento 2 Enterprise and is a really good fit for most merchants. You could also use Klevu, which makes use of the machine learning solution to promote products based on how users have interacted with them (e.g. clicks, add to carts or purchases). We’ve used visual merchandiser in this instance so merchandisers are able to visual merchandise at category-level. Worth noting that visual merchandiser is no longer available for M2 Community Edition, after Magento acquired the solution from On Tap.
• Yotpo for product reviews – we’ve used Yotpo for this project because it’s moderated, has Q&A as a built-in option and allows for the form to be embedded into the actual post-purchase email. We’re also using their product-level curated Instagram feature.
• Klarna for checkout – this is still TBC, but Klarna also provides a really strong hosted checkout, with options around paying after delivery or finance payments.

All of these solutions have existing Magento 2.x integrations.

When you’ve selected a partner to support the migration, they’ll perform an initial discovery which will cover your existing store and the migration process in a lot more detail.

Build a project team

With any development project, it’s vital to obtain buy-in and commitment from all key stakeholders, from management who will be signing off on costs, through to operations staff who will have to get used to a new admin interface and changes to core processes. By creating a project team, staff will feel involved in the venture, and will be committed to its success.

Depending on the size of the project, it may also be worth bringing in a solutions architect or project lead on your side to manage the aspects of the project you’re responsible for. On projects I’ve worked on (in-house, agency and as a consultant), this has always paid for itself. 

A few merchants I’ve worked with have also opted to book in-house training to help understand the core changes in Magento 2 – I’d recommend using Deryck from MageTraining for this. I’ve done their Magento 2 training course and it’s perfect for getting your head around how the fundamentals have changed and getting an understanding of all of core processes.

Start using the system early

The technical architecture of Magento 2 is very different from Magento 1 and it’s important that this is fully understood by the relevant members of your team. Any developers or technical users within your team will need time to properly understand the new Magento framework.

I’d suggest getting your team comfortable with the system, the new processes and the way the extensions you’ve selected to work with early on – this will help to reduce the overhead around this once you’ve launched. With the projects I’m working on, we’ve got environments setup early and extensions installed, so we can start the configuration and get used to things as early as possible. If you decide to use third parties for some of the core functions (like NOSTO, dotmailer or Klevu), you’ll also want to allocate a lot of time to the setup and ensuring you get things like automated workflows (email), promotion rules (NOSTO) and synonyms and your product sync (Klevu) working properly.

The other big consideration is going to be the data migration, which is likely to be managed via an agency if you’re using one. Magento have a data migration tool available that allows the transfer of standard and custom tables, but requires mapping and testing to ensure data comes across in the correct way. Data manipulation might be required if you’re changing the extensions you’re using too. This is a big part of the project and it’s important that you have your team setup to QA all aspects of this.

Conduct formal testing

It can often be difficult to get operations staff to conduct formal testing of an eCommerce platform – with team members assuming the agency will take ownership of this. Staff are busy with their day to day workload, and they are not professionally-trained testers, so they see little point in carrying out tedious, repetitive tests that, to them, reflect very little of how they actually use the system. Comprehensive testing is critical, however, and this should be conveyed to all those involved in the testing stage. Testing a key part of a project like this and the plan should really be factored into each stage of the project, depending on how it’s being managed.

As with most things, the success is going to come down to detailed preparation. By taking the time to fully understand the new platform, to carefully assess current functional requirements and platform configuration, and to test the transition site thoroughly, the move to Magento 2 can be a positive and professional experience, leading to ongoing support and commitment for the platform throughout the organisation.