EXPERIENCE

Ecommerce Migration

We move an existing ecommerce store to a more suitable platform or infrastructure without treating the project as a simple product export and import.

Shopify

WooCommerce

Shopify migrationecommerce platform migrationonline store migrationmigrate ecommerce storemigrate to Shopify

EUR 50 / hour

Request an ecommerce migration estimate

Complementary products

Ecommerce Redesign Technical SEO Tracking & Analytics Implementation API & Systems Integration Data Synchronization & Processing Process Automation

Website Migration remains the product for general websites.

When the migration involves an ecommerce system with products, catalogue, checkout, orders and commercial operations, the intent belongs to this page.

01PRODUCT READER

First screen

We inventory everything that needs to continue working:

catalogue -> products -> customers -> orders -> checkout -> payments -> delivery -> SEO -> tracking -> integrations

and build the transition around those dependencies.

Once we review the current store, source platform, target platform and data that needs to move, we estimate the required amount of work.

CTA support text:

Send us the current store and tell us where you want to move it. We inventory the data, functionality and integrations and estimate the project.

02PRODUCT READER

What problem does it solve?

An ecommerce platform may still work today while no longer being suitable for the next stage of the business.

Migration may become necessary when:

the platform limits future development;

administration is difficult;

costs have become too high;

the application ecosystem is no longer appropriate;

checkout cannot support business requirements;

integrations are difficult to maintain;

performance is poor;

infrastructure is unreliable;

the catalogue has become too complex for the current setup;

expansion into other markets is difficult;

the business needs a more dedicated ecommerce platform;

the current system requires too much technical intervention;

the store needs to connect more effectively with business operations.

An ecommerce store contains much more than what the customer sees.

A poorly managed migration may affect:

products;

variants;

SKUs;

images;

customers;

orders;

stock;

URLs;

SEO;

checkout;

payments;

delivery;

discounts;

tracking;

integrations;

operational workflows.

That is why ecommerce migration needs to be planned as a transition between commercial systems.

03PRODUCT READER

What does the product do?

Ecommerce Migration transfers an existing online store from one configuration to another while preserving or rebuilding the elements that need to keep working.

Depending on the project, we may migrate:

catalogue;

categories;

collections;

products;

variants;

SKUs;

prices;

images;

content;

customers;

orders;

selected historical data;

URLs;

metadata;

redirects;

tracking;

payment configuration;

delivery configuration;

discounts;

commercial settings;

integrations;

automation.

We do not assume every element can be transferred identically between two different platforms.

Some elements can be migrated.

Others need to be rebuilt.

04PRODUCT READER

What you receive

Depending on the project, Ecommerce Migration may include:

analysis of the current store;

analysis of the target platform;

catalogue inventory;

product inventory;

variant inventory;

SKU inventory;

category and collection inventory;

customer inventory;

order inventory;

discount inventory;

integration inventory;

tracking inventory;

URL inventory;

validation of available export data;

definition of transferable data;

identification of elements requiring rebuilding;

field mapping between platforms;

data cleaning and transformation where required;

data export;

import into the target platform;

catalogue rebuilding;

variant rebuilding;

image transfer;

category or collection rebuilding;

customer transfer where possible;

order transfer where possible;

checkout setup;

payment setup;

delivery setup;

discount rebuilding;

URL mapping;

redirects;

transfer of relevant metadata;

canonical validation;

internal-link updates;

new sitemap;

robots validation;

tracking configuration;

reconnection of integrations;

catalogue testing;

order testing;

payment testing;

delivery testing;

ecommerce QA;

responsive QA;

SEO QA;

launch;

post-launch validation.

Not every project requires every step.

05PRODUCT READER

What we need from you

For the initial assessment, it helps to have:

store URL;

current platform;

platform you want to use, if already selected;

reason for the migration;

approximate number of products;

approximate number of variants;

approximate number of customers;

historical order volume;

categories;

SKUs;

stock;

payment methods;

delivery methods;

discounts;

markets;

languages;

currencies;

integrations;

ERP or WMS;

invoicing system;

marketplaces;

tracking setup;

analytics and Search Console access where relevant;

elements that absolutely need to be preserved.

You do not need to know every technical limitation of the source and target platforms.

We review those during the assessment.

06PRODUCT READER

Frequently asked questions

How much does Ecommerce Migration cost?

The service costs EUR 50 / hour.

The number of hours depends on products, customers, orders, SEO, tracking, integrations and the complexity of both platforms.

Can you migrate WooCommerce to Shopify?

Yes.

We analyse the current structure and define what can be transferred directly and what needs to be rebuilt in Shopify.

Can you migrate an ecommerce store to Shopify?

Yes.

Shopify is one possible target platform where it fits the project requirements.

Can you migrate away from Shopify?

Yes.

If there is a real reason to change platforms, we can assess migration to another configuration.

Will all products be transferred?

In most projects, product data can be transferred, but variant, attribute and category structures may require transformation.

Can customers be transferred?

They may be transferable where the platforms and available methods support it.

Can customer passwords be transferred?

We do not assume so.

Platforms may use incompatible authentication systems, in which case customers may need to set a new password.

Can old orders be transferred?

It depends on the platforms and data available.

We define what historical data is useful and what can be imported correctly.

Can saved payment details be transferred?

We do not assume so.

Payment details and tokens are managed through specialised mechanisms and depend on the platforms and payment providers involved.

Will I lose SEO when changing platforms?

A platform migration can affect organic visibility if URLs, redirects, content and technical signals are handled incorrectly.

We build an SEO migration plan to avoid preventable losses.

We cannot guarantee there will be no fluctuations.

Does tracking need to be rebuilt?

It may.

The new platform may generate events and data differently, so tracking needs to be validated or adapted.

Can I keep the same domain?

Yes.

Changing platforms does not automatically require changing the domain.

Does the store need to be taken offline during migration?

We normally prepare as much as possible before final cutover.

The launch process and any downtime depend on the specific infrastructure involved.

Can you redesign the store during migration?

Yes.

In that case, the project combines Ecommerce Migration with Ecommerce Redesign.

07PRODUCT READER

What can be migrated

Transfer feasibility depends on the source and target platforms involved.

Products

Data that can often be transferred includes:

product name;

description;

SKU;

price;

images;

categories;

variants;

attributes.

The structure may need transformation to match the data model of the target platform.

Customers

Customer data may be transferable where the platforms and available methods support it.

Orders

Order history may be transferable completely, partially or not at all depending on the systems involved.

Content

Pages, articles and other content may be migrated or rebuilt.

SEO

URLs, metadata and SEO structure are not treated as ordinary import data.

They require separate mapping and validation.

08PRODUCT READER

What we do not assume can be transferred identically

Different ecommerce platforms may use different data models and functionality.

We therefore do not automatically assume identical transfer of:

customer passwords;

stored payment details;

payment tokens;

applications;

plugins;

custom functionality;

automation;

themes;

checkout customisations;

complex discount logic;

reports;

data generated by external applications.

These areas need separate evaluation.

For example, passwords may be stored in a format that cannot be transferred between platforms.

In that case, customers may need to reset their password after the migration.

Payment data is not treated as ordinary export/import data.

Its transfer depends on the payment providers and mechanisms supported by the systems involved.

09PRODUCT READER

Migration examples

Projects may include, for example:

WooCommerce -> Shopify

When the business wants to move from the WordPress/WooCommerce ecosystem to a dedicated ecommerce platform.

Shopify -> another configuration

When the business requirements can no longer be covered efficiently by the existing Shopify setup.

Custom platform -> Shopify

When a previously custom-built system can be replaced with a standard infrastructure that is easier to manage.

Legacy platform -> WooCommerce

When WordPress/WooCommerce is the appropriate setup for the project requirements.

Legacy platform -> custom development

When standard ecommerce platforms cannot support the requirements correctly.

The destination should be selected because it solves a real business requirement.

10PRODUCT READER

Ecommerce Migration vs Ecommerce Redesign

Ecommerce Migration

The main goal is to change platform or infrastructure.

Ecommerce Redesign

The main goal is to change the store experience and structure.

We can migrate a store while keeping the experience relatively similar.

We can redesign a store without changing platforms.

We can also do both.

For example:

WooCommerce -> Shopify + new experience

means:

Ecommerce Migration;

Ecommerce Redesign.

The scope needs to be defined explicitly.

11PRODUCT READER

Ecommerce Migration vs Online Store Development

If an ecommerce store already exists and the main objective is to transfer it into another setup, this is a migration project.

If the new configuration is so different that:

the catalogue is rebuilt from scratch;

the experience is completely new;

functionality changes fundamentally;

most of the old system is no longer used,

then the project may effectively become Online Store Development.

We do not call a new ecommerce build a migration simply because an older store exists.

12PRODUCT READER

How we migrate the store

1. We analyse the current store

We identify:

platform;

catalogue;

products;

variants;

customers;

orders;

URLs;

tracking;

integrations;

operations.

2. We define the target platform

We establish where the store needs to move and why that configuration is appropriate.

3. We build the migration inventory

We define what needs to be:

migrated;

transformed;

rebuilt;

redirected;

removed;

validated.

4. We map the data

We establish correspondence between the structures of the two systems.

5. We prepare the target store

We build the target configuration without unnecessarily interrupting the active store.

6. We run test migrations

For projects where complexity requires it, we validate the process on a sample or test set before the final migration.

7. We migrate data and rebuild components

We transfer what can be migrated and rebuild what cannot.

8. We reconnect infrastructure

We configure:

payments;

delivery;

tracking;

integrations;

automation.

9. We test

We validate the complete ecommerce flow.

10. We perform the final cutover

We move the store onto the new configuration.

11. We verify after launch

We validate the live production system.

13PRODUCT READER

Products and variants

Correct product mapping is one of the most important migration stages.

We review:

product ID;

SKU;

title;

description;

price;

sale price;

images;

categories;

collections;

variants;

attributes;

weight;

stock;

other required fields.

The source and target platforms may structure data differently.

A variant model that works in one system may need to be reorganised in another.

14PRODUCT READER

SKUs

The SKU may act as an important identifier across:

store;

warehouse;

ERP;

WMS;

invoicing;

feeds;

reporting.

We therefore do not change SKUs unnecessarily during migration.

If the existing SKU structure has problems, any change needs to be controlled and its impact on connected systems validated.

15PRODUCT READER

Customers

Customer migration may include:

name;

email;

phone;

addresses;

selected attributes;

other data that is available and required.

Transfer should be limited to data that can and should be moved into the target system.

We do not assume all data from the old platform needs to be replicated.

16PRODUCT READER

Customer passwords

Passwords are a special case.

They are generally stored in protected formats, and different platforms may use incompatible authentication mechanisms.

As a result, existing passwords may not be transferable.

In those cases, the new store may require customers to:

reactivate their account;

set a new password;

use the authentication method supported by the target platform.

This needs to be defined before launch.

17PRODUCT READER

Orders and history

Order history can be important for:

support;

customers;

reporting;

operations;

accounting;

analysis.

However, platforms may represent order data differently.

We define:

which period needs to be migrated;

which fields are available;

what can be imported;

what should remain archived elsewhere;

which data needs to exist operationally in the new store.

We do not transfer large amounts of historical data simply to say that “everything was migrated”.

We transfer what has real operational value.

18PRODUCT READER

Stock

Stock requires additional care when connected to:

ecommerce store;

warehouse;

ERP;

WMS;

marketplaces;

other channels.

We need to define the source of truth.

During final cutover, we need to avoid mismatches between:

stock in the old store;

stock in the new store;

real operational stock.

For complex systems, a dedicated synchronisation procedure may be required.

19PRODUCT READER

SEO and URLs

Ecommerce migration can affect a large number of URLs.

We inventory:

categories;

collections;

products;

pages;

indexable URLs;

canonicals;

metadata;

internal linking;

sitemap;

existing redirects;

pages receiving organic traffic;

pages with relevant backlinks where data is available.

URL mapping

For every relevant URL, we define the correct destination.

Redirects

Where a URL changes, the previous address should redirect to the most relevant destination.

We do not redirect every old category or product to Home.

Discontinued products

We decide individually whether:

a replacement product exists;

a relevant category exists;

the page should remain;

the page should be removed.

Canonicals

We validate canonical URLs after migration.

Sitemap

We generate or validate the sitemap produced by the target platform.

The objective is continuity, not mechanical preservation of every old URL.

20PRODUCT READER

Ecommerce tracking

Changing platforms can fundamentally change how ecommerce events are generated.

We review:

view_item;

add_to_cart;

remove_from_cart;

view_cart;

begin_checkout;

checkout events;

purchase;

order value;

currency;

products;

SKUs;

coupons;

traffic sources;

custom events.

The implementation may involve:

GA4;

GTM;

Google Ads;

Meta Pixel;

server-side tracking;

other measurement platforms.

We do not simply copy the old implementation if the new platform behaves differently.

21PRODUCT READER

Payments

The target platform may use different payment integration methods.

We review:

payment provider compatibility;

currency;

available methods;

checkout configuration;

relevant callbacks or webhooks;

payment confirmation;

order status.

We run test orders before launch.

We do not assume saved customer payment data can be migrated.

22PRODUCT READER

Delivery

We rebuild the required configuration for:

couriers;

lockers;

pickup;

delivery zones;

rates;

thresholds;

free delivery;

other relevant rules.

If delivery depends on an external integration, it needs to be reconnected and tested.

23PRODUCT READER

Discounts and promotions

Platforms may use different promotion engines.

We inventory:

active codes;

automatic discounts;

thresholds;

bundles;

promotions;

special rules.

We define what needs to be recreated in the target system.

We do not assume a complex rule can be imported directly.

24PRODUCT READER

Integrations

Migration may affect connections with:

invoicing;

ERP;

WMS;

warehouse;

couriers;

payments;

CRM;

marketplaces;

feeds;

email marketing;

analytics;

advertising;

APIs;

middleware;

custom software.

Every important integration needs to be:

inventoried;

adapted where required;

reconnected;

tested.

25PRODUCT READER

Automation

Workflows built around the old platform may not work in the target system.

Automation may exist for:

orders;

customers;

stock;

invoicing;

delivery;

email;

notifications;

leads;

reporting.

We inventory these workflows and define what needs rebuilding.

26PRODUCT READER

Final synchronisation at launch

One ecommerce-specific challenge is that the old store may continue receiving:

orders;

customers;

stock changes

while the new store is being prepared.

A final synchronisation point therefore needs to be defined.

Depending on the project, this may involve:

a final data migration;

a controlled freeze period;

dedicated synchronisation;

another method appropriate to the systems involved.

The objective is to avoid losing orders or creating stock discrepancies during cutover.

27PRODUCT READER

Backup and rollback

Before final cutover, there should be a reasonable protection mechanism.

Depending on the systems involved, this may include:

exports;

backups;

database copies;

catalogue export;

customer export;

order export;

documented configuration;

temporary preservation of the previous store;

documented DNS settings.

Rollback strategy depends on the platforms involved.

28PRODUCT READER

Downtime

The objective is to keep interruption as short as possible.

Most stages should be prepared and tested before final cutover.

There may still be dependencies involving:

DNS;

propagation;

payment providers;

external applications;

data synchronisation;

platform infrastructure.

We do not promise zero downtime when the project architecture does not allow it to be guaranteed.

29PRODUCT READER

Shopify Migration

Shopify Migration can mean two different things:

Migration to Shopify

We move an existing ecommerce store from another platform to Shopify.

Migration from Shopify

We move a Shopify store into another configuration where there is a real reason for the change.

In both situations, we evaluate:

catalogue;

data;

orders;

customers;

SEO;

tracking;

integrations;

functionality differences.

We do not automatically recommend Shopify or recommend leaving Shopify.

The target platform needs to solve the actual business requirement.

30PRODUCT READER

How much does Ecommerce Migration cost?

EUR 50 / hour

The number of hours depends on migration complexity.

Factors may include:

source platform;

target platform;

number of products;

variants;

image volume;

customers;

orders;

historical data;

catalogue structure;

URLs;

redirects;

SEO;

tracking;

payments;

delivery;

discounts;

integrations;

automation;

ERP;

WMS;

marketplaces;

data cleaning;

custom development;

QA.

Once we analyse the systems involved, we estimate the required amount of work.

31PRODUCT READER

Ecommerce Migration as an individual product or together with other components

Ecommerce Migration is a Component within Experience.

It can be purchased independently when the objective is the controlled transfer of the ecommerce system.

It can also work together with:

Ecommerce Redesign;

Technical SEO;

Tracking & Analytics Implementation;

API & Systems Integration;

Data Synchronisation & Processing;

Process Automation;

Custom Software Development.

These products are not automatically included.

They are added when the migration requires additional scope.

32PRODUCT READER

How long does it take?

The timeframe depends on the systems involved.

A migration with:

few products;

standard checkout;

limited integrations

may be substantially simpler than one involving:

thousands of products;

many variants;

customers;

orders;

stock;

ERP;

WMS;

marketplaces;

complex tracking;

automation;

multiple countries.

The timeframe is defined after analysing the source store and target platform.

We do not publish one universal duration for projects with substantially different complexity.

Ecommerce Migration

Your privacy matters