Back to blog home

Magento migration: how to smooth your move to Magento 2

By Stephen McNairn & Paal Soberg

With Magento winding down support for its 1.x versions, now is the time for Magento 1 users to start making decisions about their next platform. If you’re thinking of moving to Magento 2, here’s what you’ll need to consider in your migration plan.

Note that this article is based on a recorded Inviqa webinar on migrating from Magento 1 to Magento 2

Firstly, why Magento 2?

Thinking about migrating to Magento 2? Great! Magento 2 has proven itself to be a significant step-up from Magento 1.x versions – especially when it comes to usability and performance – and features a new backend admin panel, a better UX for admin users, an improved native frontend, more native features, and enhanced B2B functionality.

An upgrade or a replatform?

What’s important to understand is that a Magento 1 to 2 migration is essentially a re-build or a re-platforming project. Magento 2 is very different to Magento 1, which means custom work on your site will need to be reproduced for the new store (as opposed to just being moved over).

So yes, you are going to need to re-build your site from scratch, but fear not; there are a great number of advantages to migrating to Magento 2, rather than to an entirely new platform, and there a number of things that will make the re-build a lot easier:

  • You won’t have to re-learn the platform; Magento 2 has a lot of admin improvements but the user experience and processes won’t be alien to you or your teams
  • Magento 2 offers a lots more out-of-the-box functionality (e.g. B2B features)
  • Magento’s Data Migration Tool simplifies the task of transferring data and checking its consistency to your new Magento 2 website

 

As with any digital investment, the success of your project will come down to careful planning and assessment of your business requirements. We recommend that this is conducted as part of a detailed Discovery process.

We always recommend retailers undertaking a rebuild to 'release light and release early'. Resist the temptation to add too many features in your first release, because you’ll learn more about your platform if you can rapidly get to market quickly and start capturing real feedback and analysis to inform your decisions regarding any further development.

Don’t try to ‘lift & shift’

Approaching your Magento 2 move as a straight port of your Magento 1 platform’s features to the new platform may seem like a lower-risk option. But a ‘lift and shift’ approach is not only impossible (M2 doesn’t support all M1 features and extensions, for example), it can also impede innovation and increase risk.

A big issue for merchants migrating to Magento 2 is the cost required to replicate existing functionality where equivalent extensions don’t exist in Magento 2. So, if mimicking a feature on your old site doesn’t give you a measurable advantage over your competitors, it’s better to adapt that feature to work within the context of your new platform. This will help you save budget and enable you to innovate in other areas.

Instead of focusing on features you want to port over from your Magneto 1 site, it’s better to think in terms of the key business processes, ways of working, and business value you want to bring to the new platform.  

Reviewing your old code

This post is based on a Magento 2 webinar you can watch on YouTube

It’s key to look at analytics and get customer feedback to understand how your old site is being used by customers. What features are being used?  What’s driving revenue, helping you reduce costs, or giving you a competitive advantage? Use this to inform your decision-making on what to migrate to your new platform. 

An upgrade is also a good opportunity to strip out any obsolete code, unused extensions, and redundant functionality from your Magento 1 site. Remember that the more that can be left behind, the more savings you can make, because you could end up spending budget building features that don’t actually add value. 

See this as an opportunity to ‘clean up’; the chances are that you’ll have some functionality that isn’t used enough to justify spending budget on upgrading extensions.

It’s also important to have a plan for commodity features – those features that users expect to be there, but that don’t provide differentiation or give you a competitive advantage. You should minimise spend on these features, or avoid them altogether, where possible. But remember that what may be a commodity feature for one business may actually be a differentiator for another (a store locator, for example).

Capture the needs of your new system

Building a user story map can be highly effective way of capturing the high-level needs of a platform while tying those needs into value for users of the system. At its simplest form it’s about identifying specific user goals from which you derive activities, tasks, and user stories that deliver on that goal.

As they’re collaborative in nature, and often cut across departments and business functions, user story maps are an effective way of creating a shared understanding of what needs to be delivered by the migration. 

What’s more, they allow you to understand what the minimum, go-live version of your new platform looks like. For reasons we’ve explored in more depth in a previous article, story mapping is far more effective way to capture the needs of your new system than using techniques like MoSCoW.

Once you have a story map that gives you a view of your system, you should ask yourself the following at each point of the map to help you make decisions as to how business value is best delivered:

  • Does the new platform deliver this value without customisation?
  • If not, can you adapt your business processes to work in the way that’s required by the new platform?
  • If not, and customisation is required, does the return for that feature justify the investment?

 

These questions will help you to limit the amount of customisation needed to implement what are often commodity features. Remember that the focus should be on finding the cheapest and easiest ways of delivering the value, rather than the feature.

Minimise risks, maximise returns

Risk mitigation one of most important things in replatforming. Your ecommerce system touches many business-critical systems; for many businesses, the ecommerce platform is your main customer touchpoint and many business processes will be baked into this platform.

Projects like this can be expensive if you’re not managing this risk properly. You’ll need clear governance and clean lines of contact, and you should consider what you DON’T need to deliver in time for go-live. 

Take frontend design and UX, for example. This is something you build and evolve over time based on analytics and changing user behaviours. To take on a full redesign at same time as an ecommerce replatform adds a significant amount of risk. What’s more important at this stage is to get a brand or style guide in place and work closely to ensure quality and consistency.

Have a plan for data migration

Remember that all migrations will be different from each other, and that it’s hugely important to get a handle on migrating your data as soon as possible. Ensure you test your data throughout and don’t leave data migration to the last minute.

The following are areas where you’ll need to migrate data to your new platform:

  • Historical orders
  • Addresses
  • Profiles
  • Passwords
  • URL structure 
  • Content (articles)
  • Products

 

Use Magento’s Data Migration Tool, a command-line interface that verifies the consistency between Magento 1 and 2 database structures, to track progress when you’re transferring data to Magento 2. Use the tool to create logs and run data verification tests.

Quality assurance (QA) and testing is another really important part of a replatforming project and needs to be planned and factored into every stage to ensure your upgrade work doesn’t have a negative impact on your main journeys – from both a customer and admin user perspective.

Driving innovation  

You’ll have limited budget, time, and energy to invest in your ecommerce replatform project. But it’s important to make sure that you have enough to invest in innovation once your new site is live.

The Kano model, developed in the 1980s by Noriaki Kano, offers a useful lens through which to view platform migration projects. By highlighting the difference between basic ‘cost of entry’ features and those features that ‘excite’ end users, the Kano model suggests that we should minimise the effort spent on non-differentiating features. This then gives you the opportunity to retain enough budget to experiment and innovate in areas that will genuinely differentiate you from your competitors. 

One way of doing this is to start small; try low-cost experiments and see if they delight your users and drive business value. If they do, invest in further development and testing to see what resonates with your customers.

Our Magento 2 expertise

Here at Inviqa we’ve been working with Magento 2 from the beginning as one of only a handful of partners selected to take part in the Magento 2 beta programme ahead of the platform’s general release. 

We launched two of the UK’s first Magento 2 websites for Byredo and Graze.com, and our ecommerce experts include some of the UK’s very first Magento 2 Certified Solution Specialists.

This article is based on an Inviqa webinar on migrating from Magento 1 to Magento 2 and we hope it helps you lay the foundations for a solid migration plan as you map your move to Magento 2.

Please don’t hesitate to get in touch with your Magento 2 questions, or if you simply want to talk to our consultants about your ecommerce challenges.

Related reading

About the authors

Stephen McNairn, senior project manager

Stephen is a project manager and coach with a track record of delivering complex ecommerce, content, and innovation projects for global brands. He has 15 years’ ecommerce experience with a track record of delivering complex projects for some of the UK’s leading brands. A passionate advocate for continuous improvement and self-organisation, Stephen also trains delivery teams and business stakeholders in Agile and Lean approaches.
 
Paal Soberg, Magento solution consultant 

Paal has more than nine years’ experience working with enterprise digital projects, and is focused on delivering high-end ecommerce projects for leading UK brands. Paal works closely with internal teams at Inviqa and his clients to provide Magento product knowledge and training. His passion is helping merchants serve their business needs with technology, utilising platforms’ native features where possible to minimise risk and cost.