Magento migration: rebuild or retrofit?.

Rebuild or retrofit: what is the difference?

We are often asked what the difference is between a Magento rebuild and a retrofit, and why we almost always prefer a retrofit. Both approaches have their own advantages and disadvantages, but the choice between a rebuild or retrofit can have a significant impact on the cost and timeline of a project.

What is a Magento rebuild?

A Magento rebuild means that we completely rebuild your webshop from scratch. This means redeveloping all existing functionalities, design, and extensions, often with a new design and improved codebase. The idea is to make a fresh start without the limitations of the current setup.

Advantages of a rebuild:

• Modernization: You get an entirely new, up-to-date webshop with the latest technologies and best practices.
• Optimization: The opportunity to remove inefficiencies in the old code and create a leaner, faster site.
• Flexibility: More room to implement new features and designs without having to consider legacy code or processes.

What is a Magento retrofit?

A Magento retrofit means that we improve and optimize the existing webshop without completely rebuilding it. This may involve adding new features, improving performance, increasing security, and resolving existing issues, all within the existing framework of your current webshop.

Advantages of a retrofit:

• Cost savings: Retrofitting is generally much cheaper than a full rebuild because it requires less development time and resources.
• Faster implementation: Because we build on the existing structure, a retrofit can be completed much faster than a full rebuild.

Why we almost never choose a rebuild

We have found that a rebuild is often not the best choice for our clients, for the following reasons:

1. Uncertainty if problems will be solved: We often see that a rebuild is chosen when the causes of existing problems are unknown. The hope is that when the rebuild is completed, the problems will also be gone. But if the source of the problem is unknown, there is a very real chance that the same problem will be reintroduced in the rebuild. With a retrofit, we address the problems at their source without gambling on a magical solution.
2. Cost and timeline: A rebuild is more expensive and time-consuming. For many companies, the investment in time and money is not justified, especially if a retrofit can deliver the same or better results with fewer resources.
3. Risks: A full rebuild carries more risks, such as data migration problems, SEO loss, and potential downtime. These risks can have significant negative effects on your business.

In short, while a Magento rebuild can be useful in certain situations, we almost always prefer a retrofit. This approach offers a better balance between costs, time, and risks, while still enabling significant improvements and modernizations to your webshop.

Magento 1 to Magento 2 migration

Magento 1 is end of life: no security updates have been released since June 2020. If you are still running on it, the question is not whether you migrate to Magento 2, but when. Patches, PHP versions and integrations with payment and shipping providers keep drifting further apart in the meantime.

Technically, Magento 1 to Magento 2 is not an upgrade but a migration: the codebase does not come along. Your data does. Products, customers, orders and prices move over through a migration path. Theme and extensions are rebuilt, and that is exactly the moment to weigh up every piece of customisation: what moves, what can go and what is now standard in Magento 2. Include your URL structure and redirects, or you will hand in rankings at go-live.

So with Magento 1 the discussion is no longer about rebuild or retrofit; the end of support made that call for you. What you do decide is how compact your first go-live is and which customisation you take with you.

Migrating from Shopify to Magento

Shopify goes live quickly and works fine as long as your processes fit inside the platform. Once they do not, think tiered pricing per customer, your own order and approval flows, or an ERP or PIM integration that goes beyond what an app offers, every exception turns into a workaround on top of a workaround.

When migrating from Shopify to Magento, products, customers and orders come along through export and import. For SEO you build a redirect plan from your Shopify URLs (/products/, /collections/) to your new structure. The real work sits in the apps: they do not translate one to one. For every app you decide whether the functionality is standard in Magento, available as an extension, or custom work.

The switch starts to make sense as soon as your business logic matters more than the speed of setting things up, and as soon as you would rather own the platform than rent it.

Shopware to Magento 2

Shopware and Magento sit closer together: both open source, both self-hosted, both with a B2B story. So the question is rarely which platform is better, but which ecosystem fits what you need, in terms of extensions, APIs and available expertise.

A Shopware to Magento 2 migration runs through export and import of catalogue, customers and orders. The frontend is rebuilt, for example with Hyvä. Integrations are reconnected through the Magento API, so count on reviewing those connections rather than moving them across.

Switching makes sense when you need more from the B2B foundation than your current setup offers, or when the availability of extensions and expertise for your specific requirements starts to hold you back.

Where migrations tend to get stuck

Whichever route you take, things usually go wrong at the same points: a scope that grows before you start, data migration that is only picked up at the end, and end-to-end tests that happen too late. We have listed them in the five biggest pitfalls in a Magento migration.