Migrating a store to Shopify – data, integrations and SEO
We migrate live online stores to Shopify for manufacturers and brands growing their online sales. We start with an analysis of the current platform: its data, features, integrations, SEO traffic and the processes that run outside the store.
The scope and the way the switch is made are set after an analysis of the current platform.
- data and catalogue
- customers and orders
- sales features
- integrations
- SEO and redirects
- launch
- products and variants
- customers
- orders
- content
- URLs
- integrations
- inventory
- data mapping
- feature matrix
- acceptance criteria
Shopifytarget platform
Recreated in Shopify
- catalogue
- customer accounts
- sales features
- integrations
- orders
- redirects
- synchronisations
- indexing
When should you migrate a store to Shopify?
When the current platform takes too much of your team's time. The reason for migrating can be the cost of maintenance, the slow pace of change, an awkward admin, or an architecture larger than the company actually needs. Each of those reasons has to be checked before the decision is made.
- 01
Changes in the store need too much technical work
The e‑commerce team waits for simple changes it needs for campaigns, catalogue work or day-to-day selling.
- 02
Maintaining the current solution takes an ever larger budget
Updates, infrastructure and customisations cost more than the store's current scale and operating model justify.
- 03
The company wants to grow D2C sales faster
It needs a platform its own team can run and extend more easily, with the support of the apps available.
- 04
The current architecture no longer matches the organisation
The store was built for different processes, a different catalogue or an earlier sales model. Every further change means working around old assumptions.
When Shopify is not the right direction
Shopify may not be the right direction when a company's advantage rests on a heavily customised checkout, complex pricing logic, unusual order processes, or features that cannot reasonably be recreated through apps and the extension model currently supported.
Changing platform should remove the cause of the problem, not carry it into Shopify
Before we prepare the migration scope, we separate the symptom from the cause.
The store grows too slowly
What to check before deciding
The cause may be the technology, the way you work with your provider, a lack of priorities, or years of technical debt. A migration on its own will not solve an organisational problem.
Maintenance costs too much
What to check before deciding
Spending on infrastructure and updates has to be separated from the cost of features, integrations and the team's work. Only then can the current model be compared with Shopify.
The admin is hard for the team
What to check before deciding
A new platform can simplify day-to-day work, but the range of data and processes still has to be put in order.
The company wants to enter new markets
What to check before deciding
Shopify supports international selling, but the structure of stores, domains, currencies, languages, taxes and data sources has to be designed for the specific organisation.
If the store already runs on Shopify and the problem is the pace of change and control over the backlog, the right path is often Shopify maintenance and growth rather than a migration. The full catalogue sits under Shopify services.
We move the data, recreate the processes you need and prepare the store for the switch
The final scope depends on the current platform, the quality of the data, the number of integrations and the degree of customisation. The areas below are the starting point for the analysis.
The catalogue moves once we know which fields have a counterpart in the Shopify model
The scope can cover products, variants, collections, attributes, media, metafields, prices and everything else needed to publish the catalogue.
Before the import we establish which data needs cleaning, mapping or a change of structure.
Acceptance criterion: The number of products, variants and media assets in Shopify matches the agreed set of source data.
Accounts and orders migrate as far as the source data allows them to be recreated
We check whether customers, addresses, consents and order data can be migrated. How the history moves depends on the source platform and on access to the data.
Customer passwords need a separate path. They usually cannot simply be moved between different authentication systems.
Acceptance criterion: The agreed set of accounts and orders is available in Shopify, and the account activation flow has been tested.
Every feature of the current store gets a decision before the build starts
We list the discounts, payment methods, delivery options, cart rules, promotions, loyalty programmes, subscriptions and any other mechanisms in use.
Each feature is assigned a decision: native configuration, an app, an extension, an integration, or dropping it.
Acceptance criterion: The feature list is closed, and every item has a way of delivering it and a person responsible for accepting it.
The frontend scope follows the UX requirements, the budget and the plan for further growth
The project can use an off-the-shelf theme, a theme adapted to the brand, or a frontend layer built specifically for it. The decision depends on UX requirements, budget, deadline and the plan for further growth.
Acceptance criterion: The key views of the store are accepted on a test environment, on data close to production.
For every connection we set the source of truth, the direction and the way errors are handled
The store may exchange data with an ERP, PIM, WMS or CRM, an accounting system, marketplaces, marketing automation and analytics tools.
We check the direction of the flow, how often it synchronises, where the source of truth sits, and how errors are handled.
Acceptance criterion: Every integration has been tested on test data, and synchronisation errors are visible in the logs.
URLs, metadata and analytics are ready before the day of the switch
We prepare the URL map, the redirects, the metadata, the structured data, the analytics and the launch plan. After the switch we watch the most important journeys and the errors.
Acceptance criterion: The redirect map is complete for the pages that drive traffic and sales, and analytics collects data from day one.
The catalogue moves once we know which fields have a counterpart in the Shopify model
The scope can cover products, variants, collections, attributes, media, metafields, prices and everything else needed to publish the catalogue.
Before the import we establish which data needs cleaning, mapping or a change of structure.
Acceptance criterion: The number of products, variants and media assets in Shopify matches the agreed set of source data.
Accounts and orders migrate as far as the source data allows them to be recreated
We check whether customers, addresses, consents and order data can be migrated. How the history moves depends on the source platform and on access to the data.
Customer passwords need a separate path. They usually cannot simply be moved between different authentication systems.
Acceptance criterion: The agreed set of accounts and orders is available in Shopify, and the account activation flow has been tested.
Every feature of the current store gets a decision before the build starts
We list the discounts, payment methods, delivery options, cart rules, promotions, loyalty programmes, subscriptions and any other mechanisms in use.
Each feature is assigned a decision: native configuration, an app, an extension, an integration, or dropping it.
Acceptance criterion: The feature list is closed, and every item has a way of delivering it and a person responsible for accepting it.
The frontend scope follows the UX requirements, the budget and the plan for further growth
The project can use an off-the-shelf theme, a theme adapted to the brand, or a frontend layer built specifically for it. The decision depends on UX requirements, budget, deadline and the plan for further growth.
Acceptance criterion: The key views of the store are accepted on a test environment, on data close to production.
For every connection we set the source of truth, the direction and the way errors are handled
The store may exchange data with an ERP, PIM, WMS or CRM, an accounting system, marketplaces, marketing automation and analytics tools.
We check the direction of the flow, how often it synchronises, where the source of truth sits, and how errors are handled.
Acceptance criterion: Every integration has been tested on test data, and synchronisation errors are visible in the logs.
URLs, metadata and analytics are ready before the day of the switch
We prepare the URL map, the redirects, the metadata, the structured data, the analytics and the launch plan. After the switch we watch the most important journeys and the errors.
Acceptance criterion: The redirect map is complete for the pages that drive traffic and sales, and analytics collects data from day one.
Migrating from Magento, WooCommerce and PrestaShop to Shopify
Data moves across from all three. What differs is two other things: how much of it needs mapping onto the Shopify model, and how many features have to be rebuilt because they have no direct counterpart.
Magento
The richest data model of the three, so most of the work goes into simplifying it into the Shopify structure. Extensive attributes, attribute sets and pricing rules rarely have a one-to-one counterpart.
Moves across
- products and variants
- categories
- customer accounts
- orders as historical data
- CMS content and the blog
Needs mapping
- attribute sets and custom attributes onto options and metafields
- configurable and grouped products onto the Shopify variant model
- customer groups and pricing rules onto the Shopify price model
- the URL structure, which is free-form in Magento and fixed-prefix in Shopify
Has to be rebuilt
- modules and customisations in the PHP layer
- extensive cart and promotion rules
- B2B processes: company accounts, limits, approvals
WooCommerce
The store is a plugin inside WordPress, so part of the store's features and part of its content live outside WooCommerce itself. The migration covers both worlds, and most of the surprises hide in the plugins.
Moves across
- products and variants
- categories and tags
- customer accounts
- orders as historical data
- blog posts and pages
Needs mapping
- attributes and custom fields (ACF) onto options and metafields
- variable products onto Shopify variants
- the WordPress URL structure onto Shopify addresses
- user roles onto the Shopify customer and staff permission model
Has to be rebuilt
- features coming from plugins with no counterpart among Shopify apps
- WordPress theme templates and hooks
- forms, calculators and logic written in PHP
PrestaShop
A data model closer to Shopify than Magento's, but multi-language and multi-store are built differently in PrestaShop — and they are usually what decides the scope.
Moves across
- products and combinations
- categories
- customer accounts
- orders as historical data
- CMS pages
Needs mapping
- product combinations onto Shopify variants
- features and attributes onto options and metafields
- language versions onto Shopify markets and languages
- URLs, which in PrestaShop depend on the store's SEO settings
Has to be rebuilt
- PrestaShop modules and their configuration
- cart rules and vouchers beyond the Shopify standard
- customisations in the template and the PHP layer
We do not promise that every feature carries over one to one, because no migration between platforms keeps that promise. The contents of all three columns are settled after analysing the specific store — only that shows how many features are genuinely in use.
Not every feature of the current store will have a direct counterpart in Shopify
Shopify offers a wide range of ready features and apps, but it works to its own data model, checkout and extension model. A migration calls for decisions about which elements to keep and how to recreate them.
Keep
The feature is available natively, or the way it works today can be recreated without a significant change to the process.
Replace
The current module is replaced by an app or by a solution that fits Shopify better.
Rebuild
The process still matters, but it needs to work differently, needs an integration, or needs a change on the external system's side.
Retire
The feature is no longer used, it duplicates another tool, or maintaining it has no business justification.
This classification happens before the scope is approved. It avoids the situation where a significant limitation only surfaces during testing or just before launch.
B2B projects also need the Shopify plan verified, along with the model for company accounts, catalogues, price lists and payment terms. If wholesale is a significant part of the model, the scope is described on the Shopify B2B implementation and combined B2C and B2B pages.
The biggest risks surface before the store is finally switched over
First the inventory and the platform qualification, then the build, a trial migration and a controlled switch. The order is fixed, and the client confirms the scope of every stage.
The new environment is built alongside the store that is still selling. The moment of the switch follows from the readiness of the data, the integrations, the tests and the company's own team.
- 01
Analysis of the current platform
We take an inventory of the data, features, integrations, content, SEO traffic and the processes that run outside the store.
Resulta scope list and the areas that need a decision
Artefactlist of systems and data
- 02
Shopify qualification
We check whether Shopify, and the plan under consideration, will handle the company's requirements within a sensible cost and operating model.
Resulta recommended path together with a description of the limits
Artefactfeature matrix with decisions
- 03
Migration map and architecture
We settle the data sources, the way the migration runs, the apps, the integrations, the frontend scope and the acceptance criteria.
Resultan agreed scope for the solution
Artefactsolution diagram and data map
- 04
Building the store and the integrations
We configure Shopify, prepare the frontend, deliver the features needed and connect the store to the company's systems.
Resultan environment ready for a trial migration
Artefacttest environment and work backlog
- 05
Trial migration and testing
We import the agreed set of data and check the purchase flow, the accounts, payments, delivery, integrations and reporting.
Resulta list of errors and fixes, and a decision on readiness to switch
Artefacttrial migration report and test checklist
- 06
Synchronisation and launch
We run the final import of data changed since the trial, turn on the redirects and switch traffic over according to the plan agreed earlier.
Resultthe new store available to customers
Artefactlaunch checklist
- 07
Watch after go-live
We check orders, payments, synchronisations, errors, indexing and the behaviour of the most important user journeys.
Resulta list of observations and stabilisation work
Artefactlist of observations after launch
SEO migration to Shopify — URLs, redirects and indexation
Old URLs should not lead customers and crawlers to empty pages. Changing platform usually changes the structure of some URLs. So before launch the old URLs have to be matched to the right counterparts in Shopify, and the most important pages checked for content, metadata and indexability.
The SEO scope should cover an export of the current URLs, data from analytics and webmaster tools, the redirect map, and checks on canonical tags, metadata, robots, the sitemap and the structured data.
After launch we monitor 404 errors, redirects, indexing and the behaviour of the pages that generate sales or organic traffic. Visibility can fluctuate even after a well-prepared migration, so we do not promise that every ranking will hold.
Scope of the SEO migration work
- inventory of the existing URLs
- matching them to new counterparts
- preparing the 301 redirects
- recreating metadata and content
- checking canonical tags and indexing
- re-implementing structured data
- testing internal links
- monitoring after launch
| Page type | Current URL | URL in Shopify | Status |
|---|---|---|---|
| product | /catalog/product-123.html | /products/product-123 | 301 |
| category | /catalog/accessories/ | /collections/accessories | 301 |
| article | /blog/choosing-a-size/ | /blogs/advice/choosing-a-size | 301 |
| information page | /delivery-and-returns/ | /pages/delivery-and-returns | 301 |
| URL with no counterpart | /promo-2019/ | — | decision |
product
301- Current URL
- /catalog/product-123.html
- URL in Shopify
- /products/product-123
category
301- Current URL
- /catalog/accessories/
- URL in Shopify
- /collections/accessories
article
301- Current URL
- /blog/choosing-a-size/
- URL in Shopify
- /blogs/advice/choosing-a-size
information page
301- Current URL
- /delivery-and-returns/
- URL in Shopify
- /pages/delivery-and-returns
URL with no counterpart
decision- Current URL
- /promo-2019/
- URL in Shopify
- —
Example data. A URL with no counterpart needs a decision: point it at the closest page, or deliberately leave a 404. We do not redirect everything to the homepage.
ERP, PIM and WMS have to exchange data with the store on clearly agreed terms
A migration changes the connection point for many processes. Every integration needs a decision on the source of data, the direction of synchronisation, how often it updates and how it reacts to errors.
Systems that feed the store
- ERPtwo-way
prices, stock, records
- PIMinto Shopify
product data, media
- WMStwo-way
stock, fulfilment, shipments
- CRMtwo-way
customers, segments
Shopifystore and checkout
Systems the store feeds
- Marketplacesout of Shopify
catalogue, orders
- Marketing automationout of Shopify
customers, events
- Analyticsout of Shopify
orders, revenue
One source of data for each area
Before the build we establish where information about products, prices, stock levels, customers and orders originates. Shopify should not overwrite data managed in an ERP or PIM on its own.
Error handling is part of the integration
A broken connection must not stay invisible until a customer reports it. The scope should define error logging, synchronisation retries and who is responsible for reacting.
An app will not always replace an existing integration
A ready-made app can shorten delivery when its scope matches the company's processes. With non-standard data or your own order logic, a separate integration layer may be needed.
How much does migrating a store to Shopify cost, and how long does it take?
We do not quote one figure or one timeline, because a migration is not one piece of work. It is eight, and their proportions change with every store.
What moves the cost and the timeline
- Products and variants
- The sheer number of items weighs less than how many variants a product has and how they are built. A catalogue of simple products migrates faster than a smaller one with elaborate option combinations.
- Customers and orders
- Customer accounts move without passwords, so the plan has to cover the first login in the new store. Order history lands in Shopify as historical data — deciding how many years back to move genuinely changes the scope.
- Integrations
- Every connection to an ERP, PIM, WMS, marketing automation platform or sales channel needs its own decision about the source of data, the direction and error handling. This is most often the most expensive part of a migration.
- Features to rebuild
- The more features of the current store have no counterpart in the Shopify standard, the more of the project goes into apps or custom development.
- The SEO scope
- A store with a few hundred URLs and one with tens of thousands are different jobs when it comes to the redirect map, the metadata and checking indexation after launch.
- Data quality
- Data that has to be cleaned, unified or filled in first can take longer than the import itself. This is the part a trial migration usually uncovers.
- UX/UI changes
- Migrating on the store's current layout costs less than a migration combined with redesigning the purchase path. Both are justified, but they are two different budgets.
- How the switch is run
- Switching in a single window costs less than moving over in stages with both stores running in parallel. The choice depends on the volume of sales and how much the company can risk on launch day.
We prepare the quote and the schedule after analysing the current store, and refine them after the trial migration — that is what shows how much of the data needs fixing and how long the import really takes. What that analysis covers is set out in the migration process.
FAQ — migrating a store to Shopify
The scope of the data, the way the switch runs and the list of features depend on the current platform and on which processes the company runs outside the store.
Let's discuss migrating your storeWe do not quote one figure, because a migration is eight different pieces of work whose proportions change with every store: products and variants, customers and orders, integrations, features to rebuild, the SEO scope, data quality, UX changes and how the switch is run. The quote follows an analysis of the current store and is refined by the trial migration. What exactly moves the cost is set out in the section on cost and time.
The timeline follows the same factors as the cost — most of all the number of integrations, the quality of the data and how many features have to be rebuilt outside the Shopify standard. We prepare the schedule after analysing the current store and verify it after the trial migration, because only that shows how much of the data needs fixing before the import.
The switch itself is the shortest part of the project: synchronising data changed since the trial migration, repointing the domain, turning the redirects on and checking the first orders. The length of the window depends on the size of the catalogue, the number of integrations and whether the store keeps taking orders throughout. We do not declare a duration before the switchover test — that is what the test is for.
They can, and often it is worth it, because a migration is the moment when changing the layout does not need a project of its own. It is two different budgets, though: moving the store on its current layout costs less than a migration combined with redesigning the purchase path. We take the decision before the start, because it drives both the scope of the design work and the number of URLs the redirects have to cover.
Yes. The scope covers an inventory of the current URLs, the 301 redirect map, recreating metadata and content, checks on canonical tags and indexation, re-implementing the structured data and monitoring after launch. The detail is in the SEO migration section. We do not promise every ranking will hold — visibility can move even after a well-run migration.
It depends on the structure of the current catalogue and on how variants, attributes, bundles and additional data are used. Before the migration we map the source fields onto the Shopify model and point out the elements that need rebuilding.
Customer account data can be migrated within an agreed scope, but passwords usually cannot be moved between different authentication systems. An account activation or password reset flow has to be prepared.
Whether and how the history can be moved depends on the source platform, the quality of the export and how the data is expected to be presented in Shopify. The scope is agreed before the quote.
Most of the work can run in parallel on the new environment. The final switch needs an agreed window, a synchronisation of the data changed since the trial migration, and a check on the first orders. How long that stage takes depends on the project's architecture.
We prepare the redirect map, move the content and metadata that are needed, and check indexing after launch. Shopify allows URL redirects (opens in a new tab) to be created, and they should point old URLs at the matching pages of the new store. No one can credibly guarantee that rankings will not move, because the search engine re-evaluates a changed site structure.
Not always. Some features are available natively, some through apps, and the rest may need an extension or a change of process. Assessing an app covers its scope, its pricing model, access to the data and the dependency it creates on its vendor.
The migration scope can cover different source platforms. How we work depends on access to the database, the API, the exports and the quality of the current data. The first stage is an analysis of the source store. If staying on Magento is also under consideration, compare the route with migration to Magento 2.
Shopify has B2B features (opens in a new tab), but their scope depends on the plan and on the company's requirements. The customer model, catalogues, prices, payment terms, company locations and the way B2B and B2C sales are combined all have to be checked. The wider scope is described on the Shopify B2B implementation page.
After the switch we check orders, payments, delivery, integrations, analytics, redirects and any reported errors. Further growth and ongoing care fall under Shopify maintenance.
Let's establish what has to move and whether Shopify fits your current sales model
In the first call we go through the source platform, the size of the catalogue, the most important features, the integrations and the reason for the planned change. After that we can say which information is still missing before a scope can be prepared.
Worth preparing
- the current store's address and platform name
- roughly how many products and variants there are
- a list of the systems connected to the store
- a description of the features that must work after launch
- details of any B2B sales, markets and currencies