The success story of how we migrated Handy Labels from Magento 1 to Magento 2 with design refreshment, modernized frontend, and advanced SEO setup in place for this new build.
When founded in 2007, the owner of Handy Labels, Martyn Kilford, wasn’t even bothered with a choice of eCommerce platform. His goal was to offer competitive prices on a good selection of shapes, sizes, and materials to instantly buy online, and once the business grew he decided to pick Magento as a platform for his Handy Tags and Handy Labels website.
Martyn reached Inchoo when one of his stores, Handy Tags, was already migrated to Magento 2. The general idea was to audit Handy Tags installation, suggest improvements and determine the migration strategy of Handy Labels.
The final decision was to migrate Handy Labels to M2, and eventually rebuild Handy Tags and join it on the same Magento installation. The fact that Magento allows different websites/stores on a single installation will forever be one of our favorite things regarding this platform.
This is, then, a success story of how we migrated Handy Labels from Magento 1 to Magento 2 with design refreshment, modernized frontend, and advanced SEO setup in place for this new build.
The bizarre situation regarding the timeline
Have you ever had a situation where delivery from your development agency came earlier than agreed? It is as rare as bizarre, some would say, but this is honestly is how it went down. The development started at the end of June and we had the site up and running at the beginning of December.
Initially, the communicated date was the second week in January, but we were ready one month before and all within the agreed expected budget.
Work was organized in 3-4 weeks milestones, after every chunk of work we had a checkpoint and didn’t move away from the plan. Let’s see what was done during that time.
Atypical product page or “Build your own label” flow
First of all, in the planning phase, we discussed the product build flow, which stands out from the default Magento product/category page. You see, in the label industry, it is a necessity to build your own label. You pick shape, size, materials, adhesive, quantity – depending on the product you need a label for. Pricing logic is set to follow this flow, and in every step, it would be convenient to see what are your choices and how the changes have affected the price.
Part of this data was already transferred in data migration, but other work on the main product page was regarding custom options and logic for showing custom options based on the category customers came from.
Further in the product flow, it was necessary to cover the Product page Artwork upload, handling the upload logic, CSV upload adjustment, and CRUD operation. There are many more details in this specific product flow that needed to be taken into consideration from the backend and frontend perspective but especially the UX point of view, but let’s move forward with an overview since we covered a lot more in this project.
Fresh UX and modernized approach to frontend
After the design came out with a proposal for new refreshment, the client wanted to modernize the UX but not stray away too much from what customers are used to.
Once it came up to the frontend development, rather than building a theme on outdated Magento’s frontend tech stack, we’ve (once again, as on pretty much every one of our projects) used our custom compiler. This allowed us to be more efficient and faster in frontend development, and provide Handy Labels with a better code that is in line with newer technologies.
Also, this mutually gives a better starting point for any customization in the future.
Custom tier pricing
Because of the specific industry, tier pricing on Magento 1 was already in place. While looking deeper into code we concluded that we need to rework the pricing logic to simplify it and make it easier to extend and edit in the future if necessary.
Since pricing is based on custom rules, built-in Magento pricing mechanisms have been almost completely bypassed in order to reduce complexity and unnecessary processing. Five different pricing calculation models have been implemented in order to cover all available product cases.
This custom implementation allowed us to provide better performance for these specific needs.
In the checkout flow our holistic approach is to simplify all that we can and make the process as smooth as possible for the end-user. So, we decided to go with default Magento checkout with a few additional boosts like:
- address autocomplete custom code
- adding a custom packaging module that allows selecting “plain packaging” as an option
- a comment filed on the checkout (a custom backend functionality of the comment section at the end of the checkout process so that it automatically populates the invoice PDF)
With other minor changes, the checkout flow was polished to be as optimal as possible.
When it comes to reordering we rely on Magento’s default Allow Reorder feature since this is functional in Open Source from the 2.4 version. We added the solution to tackle artwork in the first step, but in the last phase, there was a need to provide the customers the possibility to reorder from legacy orders and to keep all of them available for this action.
While developing this we need to add order ID, cover the case if the artwork is sent via email and reproof existing artwork, and adjust the data if there was a pricing change in the meantime.
Once this and a few other edge cases were resolved it was ready for quick action which made happy customers repeat their orders.
Extensions behind Handy Labels
We always have a sensible approach regarding the number of extensions on our client’s projects. Where custom development makes more sense, we will be pretty strong-minded about it.
But we will also suggest where the installation of extensions available on Marketplace will have more sense.
The client wanted to continue offering customer support and live chat options as he had on Magento 1, so we’ve mutually decided that Zendesk will be a way to go. Reviews are handled with Reviews.io and for the purpose of shipping calculations and matrix rates, we integrated Shiptheory to cover the cases necessary for business, from which some of them were already predefined.
Finally, since the client used the loyalty feature on Magento 1, it was pretty important to keep up with this favorable eCommerce practice on the new build as well. So we decided to find a suitable loyalty extension that can handle basic point-earning when placing the order and exchanging points for discounts.
The final decision was the Mageplaza Reward Points extension. We didn’t want customers to lose any of their loyalty points so the points were transferred as they are and were ready for use the minute the site went live.
WordPress Blog or Magento Blog Extension?
Blog feature on Magento 1 was handled through WordPress, and we usually suggest against this approach. WordPress as a platform is far more vulnerable in terms of security than Magento, and the integration exposes Magento to some of the security threats in WordPress. The client had a great understanding of this, so we’ve decided on Mageplaza’s Magento 2 blog extension.
Next to that, a lot of modules are developed internally and Inchoo provides them in a form of custom code that is prepared to make your site better and cover all the pains you might have without it.
Some of them are Social Login, Breadcrumbs, Search suggestions, SEO module, and Google Tag Manager which provides the necessary data layer for enhanced tracking. All of them are developed in-house and possible to add for just the price of installation and configuration/setup.
The real value lies in the wish from us to be better and give you all that is a must-have in today’s e-commerce trends. Not all of them were installed in this build since we have atypical categories and products, but they are available and taken into consideration when preparing a plan and offer.
Don’t lose the SEO juice in migration
When migrating to M2 we always want to ensure that the organic traffic and (more importantly) revenue doesn’t get lost during the migration. Because of that our approach is to prepare, check and adjust URLs, canonical links, metatags, prepare 303 redirects and make sure there are no 404’s by following tips & tricks from the Inchoo SEO checklist for Magento 2 migration.
We are not done yet
Many more things can be said in this smooth cooperation, where the owner Martyn was super responsive which made our work consistent and easy. If you would like to talk some more, drop us a word here.
Luckily, we are not stopping here, but rather continue growing Handy Labels with our eCommerce digital marketing services. Oh, and do you remember Handy Tags from the beginning of this success story? It will be joining the same Magento instance as Handy Labels, as it was planned from the beginning of our cooperation.
We are happy to provide the UK market access to better label prices for the same quality and we will be working further on a growth strategy for Handy Brand LTD. Follow us for more results, which we don’t doubt will be all up trends!