Replatforming

Replatforming refers, in e-commerce, to the process of migrating an existing online shop or digital retail platform from one technical system to another. Unlike a simple version update within the same software, replatforming involves moving to a fundamentally different platform, such as from Magento Open Source to Shopware 6, or from a shop developed in-house to a standard system. The term emphasises that it is not just data that is being moved, but the entire technical infrastructure is being replaced, with all the consequences this entails for the front end, interfaces, processes and operations. The term has become firmly established in English usage and has been adopted unchanged in German-speaking e-commerce, as there is no apt German equivalent beyond the cumbersome term ‘Plattformwechsel’.

Why retailers consider replatforming

Replatforming is a major project involving risk and costs, and is rarely undertaken without a valid reason. The most common reasons can be summarised in a few categories:

In practice, several of these factors occur simultaneously. A typical example: a Magento Open Source retailer is struggling with high maintenance costs, sees support coming to an end and lacks native B2B functionality. It is only the combination of these factors that makes the switch economically justifiable.

Replatforming is more than just data migration

A common misconception is to equate replatforming with pure data migration. Data migration – that is, the transfer of products, categories, customers, orders and media – is often the most manageable part of replatforming. Modern migration tools automate this process to a large extent. Shopware, for example, provides a free plugin called the Migration Assistant, which uses a Magento migration profile to connect to Magento 1 and 2 as source systems in read-only mode, without altering the source system.

The real project risk lies elsewhere. The following areas have a greater impact on the effort and timeline of a replatforming project than the sheer volume of data:

• Extensions with no equivalent: An extension in the old shop (product configurator, specialised tax or pricing logic, ERP integration) often has no direct counterpart in the target system and must be rebuilt.
• Custom code business logic: Custom-programmed workflows must be analysed, evaluated and reimplemented in the new system.
• Front-end and theme: The design is usually rebuilt from scratch because template systems differ fundamentally.
• Interfaces: Integrations with ERP, PIM, CRM, payment service providers and dispatch systems must be redesigned and tested.
• SEO and redirects: A clean redirect mapping from the old to the new URLs is essential to ensure the relaunch does not damage search engine rankings.

The typical process of a replatforming

A structured replatforming proceeds in clear phases, even if the specific details vary depending on the project.

1. Assessment and requirements analysis

The first step is an honest assessment of the current situation: the existing system, bottlenecks, existing extensions and interfaces, as well as B2B and data requirements. This forms the basis for the requirements profile of the target system.

2. Platform selection

The target system is selected on the basis of the requirements. Factors to be considered here include not only functionality, but also the cost model, data sovereignty, available developer expertise and strategic alignment.

3. Design and data mapping

The data structures of the old and new systems are mapped against one another, functional gaps are identified, and the redesign of the front end and interfaces is planned.

4. Implementation and migration

The theme, custom logic and interfaces are built; the data is migrated and reconciled during test runs, with the option to re-import data records at a later stage.

5. Testing, redirects and go-live

Prior to the relaunch, extensive testing is carried out, URL redirects are set up and a controlled go-live is conducted, followed by close monitoring during the first few weeks.

Timeframe and effort

The duration of a replatforming project depends on its complexity. As a rough guide, depending on the scope, three to six months is a realistic estimate, comparable to a migration from Shopware 5 to 6. The decisive factors are not the number of products, but the number and nature of the interfaces, the extent of custom business logic and the requirements for the new front end. A shop with 50,000 products but only standard functions can be migrated more quickly than a smaller shop with a dozen custom interfaces and complex pricing logic.

Real-world example: Replatforming from Magento to Shopware

A medium-sized B2B retailer operates a Magento Open Source shop with around 30,000 items, an ERP connection to a merchandise management system and a B2B section built using extensions. When replatforming to Shopware 6, the data migration runs largely smoothly via the Migration Assistant. The real effort lies in rebuilding the ERP interface, mapping the purchasing hierarchies to Shopware’s native B2B components, and mapping redirects for the URL structure that has evolved over the years. The project takes around five months; the biggest part of the work is not the migration itself, but the interface and front-end development. This pattern is typical: the data is easy to move; it is the functions and integrations that determine the effort involved.

Big Bang versus phased migration

There are essentially two strategies for carrying out a replatforming, which differ significantly in terms of risk and effort. With the Big Bang approach, the old shop is completely replaced by the new one on a fixed cut-off date. This is simpler from an organisational perspective and avoids the parallel operation of two systems, but it concentrates the entire risk on a single go-live date. With a gradual or phased migration – often referred to as the ‘strangler pattern’ – individual areas or functions are migrated to the new system one after the other, whilst the rest continues to run on the old system. This spreads the risk but increases complexity, as two systems coexist temporarily and data must be kept synchronised. Which strategy is appropriate depends on the size of the shop, the risk tolerance and the technical separability of the functions. For most medium-sized online shops, a well-prepared ‘big bang’ relaunch with an extensive testing phase is the more pragmatic approach, whilst very large platforms tend to benefit more from a phased approach.

Data sovereignty and compliance as drivers of replatforming

Regulatory requirements are an increasingly important reason for replatforming. Those switching from a cloud platform hosted by a US provider to a self-hosted system with a German data centre improve data sovereignty and simplify GDPR compliance, for example through the free choice of hosting location and control over data processing and sub-processors. Accessibility can also be a driver: the German Accessibility Enhancement Act (BFSG) and the European Accessibility Act impose requirements on online shops, and a platform switch that is already on the cards provides the natural opportunity to address these requirements straight away with an accessible, semantically clean front-end, rather than having to retrofit them later at considerable expense. Anyone planning a replatforming should therefore include such compliance issues in the requirements analysis from the outset, as they help determine the target system and the front-end concept.

When replatforming is not beneficial

Replatforming is not an end in itself. There are scenarios in which a change does more harm than good. Anyone operating a well-maintained, functioning system with a well-established team and a suitable scope of functionality should not switch simply on principle. A well-established development team and established processes represent an asset that a replatforming would initially destroy and then have to rebuild elsewhere. The practical test is this: is there a specific, identifiable bottleneck that the current system cannot resolve, and do the benefits of the switch outweigh its costs and risks over a period of three to five years? Only if this question can be answered with a clear ‘yes’ is a replatforming justified.

Realistically assessing the costs of a replatforming

The costs of a replatforming consist of several components that go beyond the implementation itself. In addition to the project work involved in design, front-end development, interfaces and migration, there are licence costs for the target system, hosting migration, internal effort for testing and acceptance, as well as a stabilisation phase following go-live. An honest assessment compares these investments with the costs of inaction – namely, ongoing maintenance costs, rising licence fees or the risk of a system reaching the end of its support lifecycle. The key question is therefore not whether the new system is better, but what the cost of staying put versus switching will be over three to five years. It is only this comparison that makes replatforming a sound business decision rather than a technical fad, and it is the reason why every serious project begins with a sober assessment of the current situation rather than a platform change on a hunch.

Definitional Distinctions

In everyday language, several terms are often used interchangeably. A data migration refers to the simple transfer of data and is a sub-step of replatforming. A version upgrade (such as from Magento 2.4.6 to 2.4.7) remains within the same platform. A relaunch refers to the visible re-launch of a shop, which may or may not be accompanied by replatforming. Replatforming is the most comprehensive of these terms: it includes data migration, front-end redevelopment, interfaces, process handover and go-live.

Frequently asked questions about replatforming

What is the difference between replatforming and migration?
Migration usually refers to the transfer of data alone. Replatforming is more comprehensive and additionally involves front-end redevelopment, interfaces, reimplementation of custom code and go-live. Data migration is just one step in the process.

How long does replatforming take?
Typically three to six months, depending on complexity. The timeframe is determined by interfaces, specific business logic and front-end requirements, not by the sheer number of products.

What is the biggest risk involved in re-platforming?
Functional gaps caused by extensions with no direct equivalent in the target system, as well as faulty or missing URL redirects, which negatively impact SEO rankings. Both must be addressed early in the project planning phase, ideally before the final platform selection is made.

Is replatforming always worthwhile?
No. In the case of a well-maintained system with a suitable feature set and a well-established team, a change can destroy more value than it creates. There needs to be a specific, identifiable bottleneck and a positive cost-benefit analysis over three to five years, which also takes into account the costs of inaction.

Will my SEO rankings be retained during replatforming?
Only with proper redirect mapping from the old to the new URLs. Without this mapping, the shop will lose visibility and rankings upon relaunch.