Since the first announcement on Magento 2, way back in 2010, the eCommerce industry waited with baited breath to see what the new version would look like. After considerably longer than anticipated in its development, Magento 2 finally saw the light of day as a beta version in July 2015, and it is now the standard platform release, with support for 1.x versions due to be withdrawn in November 2018. In this article, we examine some of the key functional changes in Magento 2, and assess what kind of impact those changes are likely to have on merchants, developers and front end customers – as well as the preparation required going into a re-build project.

Magento 2 Back End

Before looking in detail at some of the functional changes contained in Magento 2, it’s worth pointing out that Magento 2 is by no means just an upgrade. The Magento 1.x platform has been rewritten from scratch, using new codebase structures, a revised database architecture and many new software components. Merchants and developers should see moving to Magento 2 very much as a replatforming project, with a data migration exercise to bring in products, customers and orders from the client’s previous version of Magento. That said, earlier versions of Magento have always been functionally very rich, so, of course, there is a great deal of crossover functionality that has been carried through into Magento 2, or tweaked very slightly, in order to enhance usability, performance or functional scope.

The Requirements Gathering Process

I’ve recently done two Magento 2 discovery projects with merchants, to map out their functional requirements going into the build, helping them to understand where custom development work is required (particularly where third party solutions aren’t available yet) and general planning going into the project. Based on this, here’s how I would suggest approaching the requirements gathering process:

Business Analysis & Discovery

This is a key phase for ensuring that the development partner fully understand your requirements for each feature and it’s something that should really be done regardless of if it’s a new partner or your existing partner (or if you’re porting most of the store over as it currently is) – you don’t want to lose any key functionality. Most Magento agencies won’t take on a project like this without doing an extensive discovery.

The first step should be to understand the top-level objectives and requirements for the project – which would cover things like the core business objectives behind the move, how the project will be judged, whether trading improvements are part of the objectives, short-term improvements etc. Then, once this has been addressed, I’d move into the functional requirements gathering stage.

As part of this, I’d usually go through my functional specification sheet (all agencies and consultants will have their own version of this) and write relatively detailed descriptions for each item (split out by key categories). Bigger merchants should also be looking to apply user stories and acceptance criteria to each feature as well, to further reduce the room for error. Although I would definitely advocate this, it’s probably more relevant to larger merchants than smaller ones.

Here are some of the top-level / general questions and areas you’ll want to address as part of the first stage of the discovery:

  • What are the objectives of this project? This should really be around whether it’s just a case of future-proofing with Magento 2 or whether there are objectives around driving more trade, improving the overall CX etc.
  • If you’re making front-end or back-end changes, what are the core objectives these? Again, this should provide detail around what you’re trying to achieve around key changes, which will help with prioritisation and matching phase one items to a business objective.
  • Which key systems will be integrated with as part of this project? This is important and will directly influence how Magento needs to work. This would be addressed in a lot more detail in the functional spec’ing phase.
  • What are the key risks for this project? This would be things like losing certain functionality, not being able to rely on certain extensions in Magento 2 (e.g. visual merchandising), loss of revenue etc.
  • What is the SEO plan as part of this project? Something that would require thought early on – again I’d list these requirements in the functional specification too.
  • Will the hosting infrastructure remain the same? Good to understand changes here early on – will require an understanding of the setup, key peaks / high load times etc
  • What are the key areas of change to the front-end and back-end of the store? Will provide an idea of how this project is being seen internally.

Functional requirements gathering

Gathering requirements around the extensions required and back-end customisation is going to be the biggest part of this, as these are going to have the biggest impact on the quote (in terms of time and money). Although, that said, regardless of whether there are design changes, front-end development in Magento 2.x is far more complex and re-building the theme will be a big proportion of the cost of the project.

I’d generally go through my Magento functional specification doc initially – which is something that I (alongside Mark from GPMD) have worked on over the last few years and I’ve built out further more recently using various Magento documentation.

Magento 2 Specification

When you’re creating the initial list of items, don’t forget to go through your Magento module list and any known custom config fields in the Magento admin and ensure that they’re factored into the list. Against each item on the spreadsheet, you should assign one of the following:

  • Custom feature / extension
  • Third party module / extension available
  • Native Magento functionality

I usually have a modules section of the functional spec, which would include all costs of third party modules and details of how the custom extensions need to work. I’d suggest using the MoSCoW method for defining how important each area is – this categorises features into four options, which are:

  • Must Have
  • Should Have
  • Could Have
  • Won’t Have this time

If you’ve already selected a development partner, I’d also suggest giving them access to your Git repository and Magento back-end so they can look at custom changes and functionality.

Reviewing third party modules and integrations

One of the biggest current drawbacks for merchants is the fact that lots of mainstream extensions aren’t currently available for Magento 2, which can be costly if the functionality needs to then be developed as a custom module.

There are also various extensions that are no longer available for the Community Edition, such as Visual Merchandiser (which Magento acquired from OnTap) and Bluefoot CMS (which Magento acquired from Gene Commerce) – both of will be EE only and there won’t be a Community Edition option available.

Examples of some extensions that aren’t currently available for Magento 2, which are common for Magento 1.x include:

  • OneStepCheckout
  • Visual Merchandiser
  • Sphinx Search Ultimate
  • Mailchimp for Magento
  • Klarna
  • Webshopapps Premium Matrix

These are just a few examples, but there are lots of other modules and integrations that aren’t yet available – the next step is to work out how important the lost functionality is and whether it’s needed for launch.

The main consideration here is, if the functionality is fundamental for launch, it’ll need to be developed as a custom extension, which will have a significant cost overhead.

Defining what is needed for launch and what is added to the backlog etc

This for me is the main consideration – what will be included for launch and what will be pushed into a phase 2 or the backlog. I’ve worked on a number of these kinds of projects and the objectives have generally dictated whether it’s launching as an MVP, or as a newly improved v2.0 of the existing store – this is really important.

If you’re moving to Magento 2.x because you know that Magento 1.x won’t be supported beyond November 2018 and you’re looking to replicate your existing setup, you may be less enclined to allocate budget to improvements. It’s worth noting that this is going to be a re-build project, not an upgrade and you’re likely to be spending a lot of money on the project. I’ve worked with some merchants that haven’t been particularly pleased about this cost and have looked to replicate their existing site as close as possible as an MVP and others that have completely rehauled their functionality and processes.

There’s not really a right and wrong here, it’s just a case of trying to get value for money. If you’re going to be spending £75k on a re-build, you should be freezing all changes to the Magento 1.x store with a view to applying them to the new one, or doing a phase two further down the line etc. This is something that needs to be defined and ideally aligned with a 12 month development plan.

Which version of Magento 2 should I be moving to?

Another big decision, especially at the moment, is around the version of Magento 2 you’re going to move to. As it stands, the latest Magento 2.1.4 version is said to be the most stable (which included a host of bug fixes from previous Magento 2 versions), but there are likely to be multiple new versions released before you launch, all with big fixes etc. The issue, as I’ve seen anyway, around upgrading again is that it has an impact on modules and causes other issues – so this is something that needs to be considered early with your development partner and as new releases come out.

My top three improvements in Magento 2.x

Admin interface improvements

Magento 2 admin

Anyone with operational responsibility for a Magento 1.x store will testify that the admin interface in earlier versions of Magento was less than user-friendly. It could often seem like something of a battle, trying to achieve what needed to be done from a store operations perspective. Visually, the Magento 2 admin dashboard is cleaner and easier to navigate. The admin menu has moved to the left hand side, and menu items have been re-categorised under more user-friendly headings, such as ‘Content’ and ‘Marketing’. When I started using Magento 2, I found the admin structure very different and struggled a bit – but after a day or so I got used to it.

Performance improvements

Performance has always been an issue with Magento, with lots of customisation and development work generally being required in order to get a Magento 1.x store to achieve a sub-3 second average page load time. Magento 2’s OOTB performance is stronger than Magento 1.x, both in terms of the front-end and the back-end.

The various improvements in the architecture and development principles used in Magento 2 have led to various opportunities for improving it’s performance, both in server response times and front-end rendering. From the Magento 2 stores I’ve seen, the improvements in performance are fairly evident.

Checkout improvements

Magento 2 Checkout

The Magento checkout has improved dramatically in Magento 2, and the old six step checkout process has been rejuvenated, in the form of a two-step process: shipping information and billing information. Guest login is enabled by default, with the invitation to create an account moved back to the checkout success page. UX principles are at the heart of the checkout redesign, and a clean and minimal approach has been adopted throughout. Other checkout improvements include email recognition, which enables the system to identify previously-registered customers and automatically load customer shipping and billing details.

As solutions like OneStepCheckout don’t yet have a Magento 2 extension, the newly improved checkout will remove this requirement (and the need for a custom solution) in a lot of cases.

Helly Hansen is a really nice example of a more customised Magento 2 checkout, as can be seen below.

Examples of stores using Magento 2

Whist doing various Magento consulting projects, I’ve done lots of research into live Magento 2 stores, here are some of the larger / best-known ones.

Helly Hansen

Oliver Sweeney

Land Rover

Soak & Sleep

Cycle Republic

These are just some of the ones I’m aware of, there are lots more. You can also read a more comprehensive list here.