Migrate to Shopify without carrying the problems with you
An e-commerce migration isn't just about copying a catalog and swapping the domain.
It means deciding what should be kept, simplified, rebuilt, or dropped. Data, URLs, integrations, and team habits all need to land together at launch.
BlackSwan scopes and runs migrations to Shopify and Shopify Plus. We start from the source platform, how the store actually operates, and the constraints of going live.
The goal is to build a clearer target, not to reproduce every piece of debt from the old system.
A migration starts with an inventory of what exists
Magento, PrestaShop, Salesforce Commerce Cloud, WooCommerce, and proprietary platforms organize products, content, and business rules in different ways. Shopify doesn't mechanically replicate these models. An approximate match can create inconsistent variants, lose useful metadata, or move a business rule into the wrong tool.
We start with an inventory of the scope. That covers the objects to migrate, their volumes where that data is available, proprietary systems, flows, markets, URLs, content, accounts, the history that's needed, and the features actually in use. We separate current requirements from legacy behavior nobody wants to keep.
This inventory feeds a decision log. For each item, the team chooses to carry it over, transform it, rebuild it, or drop it. Exclusions matter as much as what's carried over.
Define the target before you migrate
A script doesn't fix a fuzzy target model. Before moving any data, we define its destination in Shopify: products, variants, metafields, metaobjects, collections, customers, orders, content, and markets, based on the approved scope.
The mapping documents the source, the transformation, the destination, the validation rules, and who owns the data. It also spells out the exceptions. A free-text color in the old catalog may need to become a controlled option. A category may become a collection, a taxonomy, or a merchandising attribute. A legacy page may be carried over, merged, or redirected.
Carry features over with judgment
An older store often accumulates modules, workarounds, and rules whose origin is no longer clear. Reproducing every feature exactly can recreate the same complexity inside Shopify.
We assess the actual need behind each feature. Shopify may cover it natively. An app may fit. An existing integration may need rethinking. Custom development remains justified when the logic differentiates the business or protects something essential to operations.
The target blueprint shows what changes for the customer and for the merchant team. A visible improvement that significantly complicates operations needs to be discussed. An administrative simplification that changes a customer journey needs the same discussion.
Integrations tested down to the exceptions
ERP, PIM, DAM, OMS, WMS, 3PL, CRM, loyalty, and customer service tools aren't boxes to tick. Each one has its own data, direction of sync, frequency, possible failure modes, and owner.
We map the flows included in the project: products, prices, stock, customers, orders, statuses, returns, or content, depending on the need. Scoping defines the system of record, the transformations, the triggers, the checks, and the expected behavior when something fails.
An integration isn't done just because a first data exchange succeeded. It needs to be tested against normal cases and exceptions, with representative data and clear recovery responsibilities.
Protecting your SEO during the migration
A migration often changes URL structure, templates, internal linking, tags, and content. These changes may be necessary, but they need to be inventoried.
We build SEO into the migration plan: crawling the source, classifying URLs, mapping them to destinations, redirect rules, checks on indexable pages, canonicals, robots, sitemaps, structured data, and post-launch monitoring. BlackSwan's exact role, the client's, and any SEO partner's need to be settled before the cutover.
No serious provider can guarantee zero SEO fluctuation. The job is to make the changes explicit, avoid avoidable losses, and catch anomalies quickly.
Rehearse before you switch over
The first data migration run is for learning. It surfaces unexpected formats, missing values, duplicates, undocumented rules, and gaps between the theoretical model and the real data.
We plan rehearsals based on scope and risk. Each pass produces a report: items processed, errors, exceptions, fixes, and acceptance criteria. Business teams check the data they know. Technical teams check the transformations and flows. SEO checks the URL mapping and indexability. Responsibilities are named.
Dates, the number of rehearsals, and exact criteria depend on the project. This page doesn't promise a standard timeline.
Organizing QA that covers the whole business
QA can't stop at the homepage and a few successful orders. It needs to cover products, search, collections, accounts, promotions, markets, payments, taxes, shipping, emails, tracking, integrations, and post-order operations, within scope.
We prepare the test scenarios before development wraps up. Internal issues are fixed before opening client QA. Bugs are logged with context, priority, an owner, and a status. Go/no-go criteria separate what blocks launch from what can move to the roadmap.
Preparing the cutover and the rollback
Launch brings several changes together: the final sync, a possible content freeze, domain configuration, redirects, payments, tracking, integrations, and opening the markets. A runbook sequences the actions, checks, and decisions.
The plan spells out who gives the go-ahead, who checks each system, and how the team responds if a check fails. Rollback options depend on the architecture and shouldn't be promised without study. Some cutovers allow limited coexistence. Others need a stricter window.
After going live, we track errors, orders, payments, flows, and indexing according to agreed responsibilities. Stabilization is for fixing launch issues and confirming that real operations match what was tested.
Shopify or Shopify Plus?
Migration is the right moment to weigh the plan choice against actual needs. Shopify Plus can make sense for certain organizations, certain checkout flows, B2B, international expansion, or governance. It shouldn't be recommended purely on company size or a tagline.
We document the needs that genuinely depend on the plan. Capabilities, terms, and pricing need to be checked as of the decision date. If standard Shopify covers the scope, the migration gains nothing from adding unnecessary contractual complexity.
The Claus Porto case
Claus Porto, a Portuguese soap and perfume house founded in 1887, is known for its artisanal craftsmanship and Art Deco packaging. The brand used to sell online on Magento. BlackSwan led its migration to Shopify.
The new store extends the house's world and opens it to multiple markets: localized storefronts, market-specific catalogs, custom product pages, brand storytelling, and a sample selector.
Claus Porto
Migration to Shopify
FAQ
How long does a migration to Shopify take?
Timing depends on the catalog, the data, the integrations, the markets, the design, SEO, and team availability. A serious timeline follows scoping and the first inventories. We'd rather present milestones, dependencies, and decision points than a generic duration on a sales page.
Can order history and customer accounts be migrated?
Some data can be carried over, but its availability, quality, usefulness, and the target's capabilities need to be checked. The mapping specifies what gets migrated, transformed, archived, or left in a system you can still consult. Data-protection obligations need to be handled with the relevant owners.
Do you have to redo the design during a migration?
Not always, but switching platforms without revisiting the components and journeys can limit the value of the project. We assess what can be kept and what needs adapting for Shopify. The decision depends on the state of the existing design, the objectives, and the timeline constraints.
Does a migration cause you to lose SEO rankings?
Any major change can affect crawling, indexing, and rankings. There's no guarantee of zero movement at all. A complete inventory, precise redirects, SEO QA, and post-launch monitoring reduce avoidable risk and speed up error detection.
How do you handle ERP or PIM integrations?
We define the flows, the systems of record, the transformations, the errors, and who owns what. Development and testing depend on the architecture chosen and any other vendors involved. BlackSwan's responsibilities are set in the scope, not assumed.
Can the old platform and Shopify coexist?
Temporary coexistence is sometimes possible for certain markets, content, or systems. It also adds questions of sync, SEO, and operations. We treat it as an architecture decision, with its own costs and risks, rather than a default solution.
What should you prepare before a scoping workshop?
The most useful things are access to a catalog inventory, the list of markets, connected systems, the main customer journeys, SEO constraints, data owners, and any dates with real operational consequences. A perfect export isn't necessary to get started, but the unknowns need to be named.
Scope the migration before you set a launch date
Tell us about your source platform, your markets, your integrations, and any risks already identified. We'll help you define the inventories, decisions, and evidence needed before building the plan.