Skip to content

( /services/shopify-migration )

Platform migration

  • 01Redirect map from a crawl
  • 02Baseline kept across cutover
  • 03Reconciled, then handed over

Carrtel Solutions is a Shopify Partner. We build stores on Shopify.

Replatform to Shopify with your SEO and your data intact

Moving the catalog is the easy part, and it is the part every migration quote is about. The URLs, the canonical structure, the analytics baseline and the proof that nothing was dropped are the parts that decide whether the new store keeps the traffic the old one earned.

  • From WooCommerce, Magento, BigCommerce, Wix or Squarespace
  • A 301 map built by crawling your live site, not by exporting products
  • Analytics identity kept continuous, so before and after compare
  • A reconciliation report that names every difference, or numbers it
$14,000, 5 weeks — what that coversSend your store URL for scoping
The short answer

What does migrating to Shopify actually involve?

Four things, in this order. Map every URL the old store ever answered on to a counterpart on the new one, using a crawl rather than a product export. Decide the canonical structure before the import runs, because Shopify will otherwise decide it for you. Keep the analytics identity continuous across the cutover so the before and after can be compared at all. Then reconcile both stores, matched by identifier rather than by count, and hand over a report. Platform Migration is $14,000 for five weeks and up to 2,000 SKUs, from WooCommerce, Magento, BigCommerce, Wix or Squarespace.

Last updated: August 2026

What decides it

The catalog moves either way. These four are the project.

A migration that goes wrong rarely looks wrong on launch day. The store is fast, the products are there, and the damage is in the traffic that stops arriving over the following weeks.

01

The 301 redirect map

Every old URL to its new counterpart. Not a sample of them.

A map generated from your product export covers product pages and nothing else. The URLs that carry the rest of your traffic — category pages, their paginated and filtered variants, blog posts and their archives, the landing pages your ads point at — are simply absent from that export, so they are absent from the map, so on cutover day they are 404s.

02

The canonical structure

One thing, one address, decided before the import runs.

Shopify will serve the same product at more than one path, flatten your nested categories, and generate a handle from whatever the title happens to be on import day. Each of those is a decision. Left undecided, it is still a decision — just one made by a default rather than by you, and expensive to reverse once the URLs are live and linked.

03

The analytics baseline

So the before and after are actually comparable.

If the measurement changes on the same day the store changes, nothing that happens next can be attributed to either. You lose the ability to answer the only question that matters after a launch: is this better or worse than what we had? We freeze the baseline first and keep the measurement identity continuous across the cutover.

04

The data-integrity reconciliation

Proof nothing was dropped, matched by identifier.

Imports report how many rows they wrote, not which rows they skipped. Counts can match while the contents do not. After cutover we reconcile both stores field by field on a sample and identifier by identifier on the whole, and hand you a report where every difference is either explained or numbered.

By source platform

What is genuinely different about your platform

Six sources, six different shapes of risk. A migration plan that reads the same for all of them was written before anyone looked at your store.

01

WooCommerce

The catalog usually fits. The WordPress site wrapped around it is where the work is.

The data model

Variable products carry attributes that WooCommerce lets you invent freely, in any number. Shopify’s option model is narrower and its limits have moved more than once, so the honest step is to check the current limits against your worst product rather than against your average one. Where a product does not fit, the choices are to split it into several products, or to move an attribute into a line-item property or a metafield. Each choice changes the URL, the reporting and the pick list in the warehouse, so it gets made deliberately and written down.

The URLs

WordPress permalinks are the real project. Products under /product/, categories under /product-category/ with parent and child nesting, /shop/page/2/, tag and author archives, feed URLs, attachment pages, and whatever earlier permalink structure the site used before someone changed it — the old shapes are usually still linked from somewhere. All of it is crawlable, none of it is in the product export.

What catches people

  • Passwords cannot come across. WordPress stores a hash, Shopify cannot import one, and no tool changes that. Every customer resets.
  • Plugin equivalence is where scope hides: subscriptions, bookings, role-based pricing, dynamic discounts and ACF-driven content each need a Shopify answer or an explicit decision to drop.
  • Product data often lives half in WooCommerce and half in custom fields the theme reads. The export sees the first half.
  • Image URLs under /wp-content/uploads/ are linked from posts, emails and other people’s sites. They need targets too.
02

Magento / Adobe Commerce

The richest data model of the six, moving to a deliberately simpler one. Most of the cost is in the mapping decisions.

The data model

Configurable, bundle and grouped products are three different things in Magento and only one of them maps cleanly. A configurable product becomes a Shopify product with variants. A bundle has no native equivalent and becomes either a set of products, an app, or a Shopify Function — a real decision with a real price attached. A grouped product usually becomes a collection or a curated section, which means it stops being one URL and starts being another.

The URLs

Magento appends a suffix to product and category URLs by default, layered navigation adds parameters, and the url_rewrite table has been quietly accumulating historical rewrites for as long as the store has existed. That table is worth reading before you crawl: it is a record of every URL the store has ever answered on, including the ones no page links to any more.

What catches people

  • Multi-store views do not have a one-to-one Shopify equivalent. Regions and languages can map onto Shopify Markets; genuinely different catalogs under one Magento installation may mean more than one Shopify store, which changes both the price and the plan.
  • Customer group pricing is the question to ask on the first call. Shopify’s native B2B pricing sits on a plan tier we do not sell into, so at Basic, Grow or Advanced the answer is an app with its own limits. Sometimes the honest answer is that this migration should not happen.
  • EAV attribute sprawl: a mature store carries hundreds of attributes, most of them unused. They map to metafields, but only after somebody decides which ones still earn their place.
  • Adobe publishes a software lifecycle policy with an end-of-support date per release line, and several of those dates have now passed. Look up the exact version you are running on Adobe’s own page rather than trusting a date on a sales page, including this one.
03

BigCommerce

Close enough to Shopify that the catalog is rarely the risk. The risk concentrates almost entirely in URLs and redirects.

The data model

The catalog concepts line up: products, variants, categories, customer records. The one distinction that catches people is modifiers. A BigCommerce option that creates a SKU becomes a Shopify variant; a modifier that adds a choice without creating a SKU does not, and becomes a line-item property or a Function instead. Older stores may still be on option sets, which means the same option list is shared across many products and has to be unpicked before it can be re-expressed per product.

The URLs

BigCommerce lets you set arbitrary URLs per product and per category, and mature stores have used that freedom. There is no single shape to translate — which is exactly why the map has to come from a crawl of the live site rather than a rule. Price lists and customer-group pricing carry the same caveat as Magento: check what your plan tier can actually do before committing.

What catches people

  • Near-parity is the trap. Because the catalog moves easily, teams skip the URL work and discover the gap in the 404 report a fortnight after launch.
  • Any redirects already configured in BigCommerce are part of your URL history and belong in the new map, not just the URLs currently linked.
  • Multi-storefront setups need the same conversation as Magento multi-store views.
04

Wix

A thin data model, so the catalog is quick. The work is content, design and SEO parity.

The data model

Wix product records are shallow by design: a product, a handful of options, limited variant depth, and not much room for the metadata a larger catalog leans on. That makes the import short. It also means the interesting parts of the site — the pages, the layout, the copy — are not in the catalog at all, and the migration is mostly a rebuild of those in Liquid.

The URLs

Wix serves products and blog posts under fixed path prefixes, which makes the URL translation unusually mechanical once the site has been crawled. The pages you built by hand are the exception: their paths follow whatever the site structure grew into, and they are typically the pages that rank.

What catches people

  • Nothing about the design ports. Liquid is a different templating language and the layout is rebuilt, not converted.
  • Wix-specific features — bookings, member areas, its own form handling — have no direct Shopify equivalent and each needs a named replacement or an explicit decision to drop it.
  • Confirm you can still crawl the live site. A site already taken down cannot be crawled, and the map then has to be reconstructed from whatever records survive. It will be incomplete, and we will say so rather than pretend otherwise.
05

Squarespace

Same thin catalog as Wix, different centre of gravity: the content pages are usually what carries the traffic.

The data model

The store is a section of a content site rather than the other way around. Products, options and inventory move quickly. The number of SKUs is rarely the constraint, so the five-week shape is driven by page count and content complexity instead of catalog size.

The URLs

Squarespace product paths are built from the slug of the store page they sit under, and the blog behaves the same way, so the prefixes differ from site to site rather than following one platform-wide rule. That is a small thing that breaks rule-based mapping and a non-issue for a crawl-based one.

What catches people

  • The ranking pages are usually the essays, guides and landing pages, not the product pages. Content parity is the SEO work here — same page, same intent, same internal links pointing at it.
  • Block-editor layouts are rebuilt as theme sections. A visually identical rebuild is a design decision with a cost; a functionally equivalent one is usually the better trade.
  • Member areas, scheduling and any Squarespace-native commerce extras need replacements named before the project starts.
06

Salesforce Commerce Cloud

Enterprise scope. This one sits at the edge of what we take, and we would rather say so on the first call than in week three.

The data model

An SFCC estate keeps meaningful business logic in cartridges, content in Page Designer, and promotions in an engine considerably more expressive than Shopify’s. Catalogs are shared and assigned rather than owned by a single site. Migrating the data is the straightforward half; deciding what happens to the logic is the half that decides whether the project is possible at the price.

The URLs

Multi-site and multi-locale URL structures multiply the map: every locale variant of every URL is a row, and hreflang has to be rebuilt on the other side rather than inherited. This is the scenario where the redirect map stops being a spreadsheet and becomes the largest single line item in the project.

What catches people

  • We do not bid Shopify Plus enterprise work. Most SFCC merchants land on Plus, which means most SFCC enquiries are not a fit for us — that is the plain answer, given up front.
  • A single-site SFCC store with a catalog that fits, an ordinary promotion set, and a willingness to accept Shopify’s promotion model is something we will quote. A multi-site, multi-locale estate with material logic living in cartridges is not.
  • If the logic in your cartridges is the business, replatforming it is a rebuild wearing a migration’s name. We will tell you that before you spend anything.

Not listed here, or on something older than all six? Say what it is and we will tell you whether it is a migration or a rebuild. Those are different projects with different prices, and finding out which one you have is worth a conversation before it is worth a quote.

The 301 map

Build it from a crawl, never from an export

A product export knows about products. Your traffic does not arrive only on product pages, and it never has.

Where the URL list comes from

  • 01A full crawl of the live old site, followed to every depth rather than to the first few hundred pages
  • 02Every XML sitemap the old platform publishes, including the ones nothing links to
  • 03Search Console’s page report, which knows about URLs that rank but are no longer linked internally
  • 04Server access logs where they can be obtained: the only record of URLs that still receive real traffic
  • 05Final URLs from every live ad campaign, so paid traffic lands on a page rather than on a redirect chain
  • 06Links in email templates, automations, PDFs and packing inserts, which outlive every site they were written for
  • 07The old platform’s own redirect table, which is a history of URLs the store has already answered on
  • 08Backlink data where you have it, for the pages other people decided to point at

Then the rules of the map itself. Every source URL gets a specific counterpart, not the homepage: Google's own site-move documentation says that redirecting old URLs en masse to the homepage is treated as a soft 404, which is a slower way of serving a 404. Every redirect is a single hop to a page that returns 200, because each extra hop is another round trip the visitor waits through and another place a tracking parameter can be lost on a click you paid for. And the map is delivered as something you can read: source URL, status code, final destination, hop count, one row per URL.

Shape translation · illustrative

FromOld shapeShopify
WooCommerce/product/<slug>//products/<handle>
WooCommerce/product-category/<parent>/<child>//collections/<handle>
WooCommerce/shop/page/2/Collection root, or its paginated form
Magento/<category>/<product>.html/products/<handle>
Magento/<parent>/<child>.html/collections/<handle>
BigCommerceArbitrary, set per product/products/<handle>
WixFixed product path prefix/products/<handle>
Squarespace/<store-page>/p/<slug>/products/<handle>
Any/blog/<year>/<month>/<slug>//blogs/<blog>/<handle>

Shapes vary by platform version and by settings. This table shows the kind of translation involved; your map is built from a crawl of your actual site, not from a rule.

The deliverable

The map is a file you keep

One row per source URL: destination, status code, hop count, and for any target that was a judgement call rather than an obvious match, the reason somebody chose it. It is in the CSV shape Shopify's redirect importer accepts, and it is still readable a year later, on the day somebody asks why one particular URL points where it does.

What the five weeks cost
Canonical structure

Decisions taken before the import, not after

Every one of these has a default. The default is not neutral, it is just the option nobody chose.

One product, one address

Shopify serves a product at /products/<handle> and also under a collection path. The canonical has to resolve to the first, and the theme has to actually render the tag in the head — themes have shipped without it. We verify the rendered output rather than the intent.

Handles chosen, not derived

The handle is the URL. Left to itself Shopify derives it from the product title on import day. Choosing handles deliberately at import is a few hours; changing them afterwards is a redirect for every one. Shopify offers to create that redirect when you edit a handle in the admin, and the offer should always be taken.

Nested categories flattened on purpose

Shopify collections do not nest. Every parent-and-child category is therefore a decision: does the child become its own collection with its own URL, a filtered view, or a tag? That decision determines which of your old category URLs still has a counterpart, so it is made before the import rather than discovered after it.

The indexable set defined up front

Filtered and sorted views can multiply into thousands of near-identical URLs. Deciding which of them should be indexable, and which should be reachable but not indexed, is the difference between a clean crawl and a store that spends its crawl budget on colour filters.

Search Console continuity

If the domain does not change, the property carries on and the launch gets an annotation. If it does change, the new property is verified in advance so there is data from day one, and the change of address is submitted through Google’s own tool rather than left to be inferred.

The storefront actually open

A password-protected preview that stays protected, a robots.txt copied across from the old site, a noindex left on a template: three ordinary mistakes with the same outcome. They are on the cutover checklist because each has cost somebody a fortnight.

The pattern underneath all six is the same. A URL is cheap to choose and expensive to change, because every change costs a redirect and every redirect costs a little of what the URL was carrying. So the URLs get chosen once, on purpose, in week two.

The baseline

Keeping the before and after comparable

( 06 steps )

  1. 01

    Freeze the baseline before anything moves

    A dated export of the metrics you will want to argue about later, at the granularity you will want them: sessions, orders, conversion rate and revenue, split by channel, by landing page and by device, over a window long enough to contain your ordinary variation. Held outside both platforms, because one of them is going away.

  2. 02

    Keep the measurement identity

    Same analytics property, same measurement ID, same conversion actions wherever the platform allows it. History that splits into two properties on cutover day cannot be compared without manual stitching, and manual stitching is where convenient conclusions come from.

  3. 03

    Event parity before event improvement

    The new store emits the same event names with the same parameters as the old one. If your taxonomy needs improving, it gets improved after the migration has been measured, not during. Changing the store and the instrument on the same day makes both unmeasurable.

  4. 04

    Ad platforms repointed, not redirected

    Every live campaign’s final URL is updated to the new address. Leaving paid traffic to arrive via a redirect costs you a hop on every click and is a common way for tracking parameters to go missing between the ad and the page.

  5. 05

    One clearly marked cutover

    The launch is annotated in every tool that supports annotations, and the comparison window afterwards is aligned by day of week rather than by date. Seasonality and campaigns still move the numbers; the annotation at least stops the migration being blamed for, or credited with, all of it.

  6. 06

    Export before you cancel

    The old platform’s reporting stops being readable when the account closes. Whatever you might want in eighteen months comes out first, into a format that does not need that platform to open.

Why this is the fourth pillar

Six weeks after a launch, someone will ask whether the migration helped or hurt. If the measurement changed on the same day the store did, that question has no answer, and the argument that follows gets settled by whoever is most confident rather than by the data.

Continuity is cheap to arrange beforehand and impossible to arrange afterwards. That asymmetry is the entire reason it belongs in week one.

Keeping the money path proven after launch is a separate, optional service: tracking and checkout integrity.

Reconciliation

Proof nothing was dropped, matched by identifier

Two stores can hold the same number of products and not the same products. Counting is not checking.

What gets checked

  • 01Product, variant, image and collection counts on both sides, then a sample matched field by field: price, compare-at, SKU, barcode, weight, inventory, tax setting, status and sales-channel publication.
  • 02Every customer record matched by email, with the marketing-consent state carried across as it was — including its original timestamp and source, rather than importing everybody as subscribed.
  • 03Order records matched by order number, with totals, taxes, discounts and financial status compared line by line on a sample.
  • 04Inventory reconciled against the source of truth on cutover day, not against the export taken three weeks earlier.
  • 05Every source URL in the redirect map requested against the live store: one hop, a 301, and a 200 at the end of it.
  • 06Metafield coverage checked for the fields the theme actually reads, because an empty metafield renders as an empty section rather than as an error.
  • 07A crawl of the new store for broken internal links, missing canonical tags, and any template still carrying a noindex from staging.
  • 08Tracking verified against real orders after cutover: orders created reconciled against purchase events recorded, inside an agreed tolerance.

Import tools report what they wrote. They are considerably quieter about what they skipped, and a row rejected for a malformed field looks exactly like a row that was never in the file. So the check runs against both stores after the fact, from outside either import, and every difference ends up either explained in a sentence or carrying an exception number.

Illustrative report · format only

RowOldNewDelta
ProductsMatched by SKU1,8421,8420
VariantsExplained: 3 discontinued, agreed in week 24,3914,388−3
CollectionsExplained: 33 child categories became filters9461−33
CustomersMatched by email22,10422,1040
Orders importedMatched by order number58,73058,7300
Redirects resolvingUnexplained → exception #127,4157,401−14

These numbers are invented to show the layout. Carrtel has no client results to publish.

The limits

What does not come across, whoever does the work

These are constraints of the platforms, not of the agency. Anyone promising otherwise is describing a tool that does not exist.

Customer passwords

Every platform stores a one-way hash, not a password, and no platform can import another’s. Customers reset. Shopify sends account invitations, and the sequencing of those invitations is a decision worth making deliberately rather than firing them all on cutover day.

Analytics history

It stays in the tool that recorded it. This is why the baseline gets frozen and exported before anything moves.

App-owned data

Reviews, loyalty balances and subscriber lists usually live inside an app rather than inside the store. They move only if both the old and the new app support it, and that is a question for those two vendors before it is a line in our quote.

Subscriptions

A subscription is a payment relationship, not a row in a table. Whether it can move depends on your current provider, your gateway and whether payment tokens can be transferred between them. That conversation happens with those parties first; the answer changes the plan and sometimes cancels it.

Theme and template code

Liquid is a different templating language from PHP templates, from Magento layout XML, and from a block editor. The front end is rebuilt. Nothing converts.

Live transactions inside imported orders

Imported historical orders are records. There is no captured payment behind them in Shopify, so they cannot be refunded or re-captured there. Keep the old system’s records, or its exports, for as long as your refund window and your accountant require.

The password one deserves saying twice, because it is the single most common surprise in a migration and it lands on customers rather than on staff. Passwords are stored as one-way hashes and cannot be moved between platforms. Every customer resets. Plan the invitation emails as a campaign with a schedule and a sender reputation to protect, not as a checkbox in an import screen, and expect a share of dormant accounts never to come back.

The schedule

What happens in each of the five weeks

( 05 weeks )

  1. Week 1

    Read the old store

    Full crawl and URL inventory. Catalog and data-model audit. An inventory of every plugin, app and integration, each one marked as replaced, rebuilt or dropped, in writing and signed off. The analytics baseline is frozen and exported in this week, before anything changes.

  2. Week 2

    Decide, then build

    The mapping decisions get made and recorded: options against metafields against separate products, which child categories become collections and which become filters, what every handle will be. The theme, templates and navigation are built against those decisions on a preview theme.

  3. Week 3

    Import and iterate

    Products, collections, customers, orders and content imported into a store nobody can see yet. First reconciliation pass runs against that import, which is where the import script’s quiet omissions surface while there is still time to fix them cheaply.

  4. Week 4

    Redirects, tracking, rehearsal

    The 301 map is assembled from every source and reviewed row by row for the judgement calls. Tracking is wired to parity with the baseline. Then a full dry-run cutover, with a written rollback path that names who executes it and on what trigger.

  5. Week 5

    Cutover and verification

    DNS, redirects live, and then the verification pass: the entire old URL list re-requested against the live store, the reconciliation report produced, tracking verified against real orders rather than test ones. The report is the deliverable, not the launch announcement.

Cutover happens on a day everybody agreed to, with a rollback path written down before it starts. A rollback plan invented during an incident is not a plan, it is a conversation.

Price

$14,000, five weeks, up to 2,000 SKUs

All prices in USD, published in full. Fixed scope, fixed price, stated duration. Everything that would change the number is on this page rather than in a change order later.

Included at $14,000

  • Up to 2,000 SKUs, one source store, one language
  • The store built on a Liquid theme, staged on a preview nobody else can see
  • Catalog, customer and order data imported, with the mapping decisions written down
  • A full 301 redirect map built from a crawl, delivered as a file you can read
  • The analytics baseline frozen, exported, and kept continuous across the cutover
  • A rehearsed cutover with a written rollback path
  • A post-migration data-integrity reconciliation report
  • 30-day bug warranty on the work we delivered

What pushes it above

  • More than 2,000 SKUs, or a modest SKU count carrying a very large number of variants. Variant count is the better predictor of effort than product count.
  • More than one source store: multi-store views, multi-storefront, or several sites being consolidated into one.
  • Multi-currency and multi-language, which brings Markets configuration, hreflang and translated content into scope.
  • Customer-group or B2B pricing that Shopify does not do natively at your plan tier.
  • Subscriptions, wherever the providers will even permit a transfer.
  • An ERP, 3PL or accounting integration. That is the Order Ops Bridge at $9,500 over 4 weeks, quoted separately rather than folded in quietly.
  • Storefront functionality that has to be rebuilt as a custom app rather than replaced with an existing one.
  • Content volume: several hundred posts or landing pages that need rebuilding rather than importing.
  • A design project rather than a build. We do not do brand identity, so a rebrand riding along with a migration needs a designer we are not.
  • An old site that is already offline and can no longer be crawled. The map is then reconstructed from surviving records, it will be incomplete, and we will say which parts are guesses.

Change orders and overage run at $135/hr, scoped and approved in writing before anyone starts.

Not moving platform

A new store on Shopify without a migration is Store Build at $7,500 over 3 weeks, up to 12 templates and 500 SKUs.

Connecting the back office

Shopify to an ERP, 3PL or accounting system is the Order Ops Bridge at $9,500 over 4 weeks. Separate project, separate quote.

After the warranty

Watching the money path daily is optional: Integrity Watch at $1,200/mo, or Order Ops at $3,400/mo where the middleware is ours to run.

Every price we chargeOrder operations
The commitment

What we stand behind, stated plainly

30-day bug warranty

Defects in work we delivered are fixed at no charge for 30 days after delivery.

25% credit on a missed date

If we miss an agreed delivery date, you get a 25% credit toward the next engagement. A credit, not a cash refund.

Three projects at a time

We run a maximum of three concurrent projects. That limit is why a five-week date is meetable in the first place.

Exclusions

The warranty and the credit do not cover defects inside third-party apps, delays on your side (access, approvals, content, decisions), or platform incidents. None of those are ours to control, so we do not price as though they are. Neither one is a promise about rankings or traffic, because no honest agency can make that promise about a search index it does not operate.

We have no case studies to show you, and we say so rather than borrowing someone else's. What you can check instead is on how to verify us.

Who this is for, and who it is not for

( Fit )

A good fit

  • A live store past product-market fit, roughly $40k to $400k USD a month
  • Moving onto Basic, Grow or Advanced with a Liquid theme
  • Real organic traffic and real ad spend, so the URLs are worth protecting
  • No in-house developer, so nobody currently owns the migration
  • A catalog inside 2,000 SKUs, or a willingness to be quoted properly above it
  • Ready to make the mapping decisions in week two rather than defer them

Not a fit

  • Shopify Plus enterprise bids. We do not take that work.
  • Greenfield headless rebuilds for a small merchant
  • A multi-site, multi-locale Salesforce Commerce Cloud estate with business logic in cartridges
  • A migration that is really a rebrand. We do not do brand identity design.
  • Paid media or SEO retainers, and dropshipping store spin-ups
  • An old site already taken offline, if an incomplete redirect map is not acceptable to you

Common questions

( 12 )

01
How long does a Shopify migration take?
Five weeks for the published scope: up to 2,000 SKUs, one source store, one language, a full 301 redirect map and a data-integrity reconciliation, at $14,000. Multi-store views, multi-currency, B2B pricing, subscriptions or an ERP integration each extend it, and each is quoted before the project starts rather than raised as a change order in week three.
02
Will I lose my search rankings when I move to Shopify?
Nobody can honestly promise that rankings hold, and you should be wary of anyone who does. Rankings move for reasons no agency controls: the index, competitors, seasonality, algorithm changes that happen to land the same month. What can be promised is mechanical, and it is the part that most migrations actually get wrong. Every URL that existed resolves in one hop to the right counterpart, the canonical structure is deliberate rather than accidental, and there is a frozen baseline that makes the before and after comparable instead of arguable.
03
Can you migrate my customer passwords?
No, and neither can anyone else. Every platform stores a one-way hash rather than the password itself, and hashes are not portable between platforms. Your customers will need to reset. Shopify sends account invitations for imported customers; we plan when those go out, because sending tens of thousands of them on cutover day is its own kind of incident. Expect a share of dormant accounts never to reactivate, and plan the email around that rather than being surprised by it.
04
What happens to my order history?
Orders can be imported as historical records, and for most merchants that is the right call: support can look up an old order, and lifetime-value reporting keeps working. Understand the limit, though. An imported order is a record, not a live transaction. There is no captured payment behind it in Shopify, so it cannot be refunded or re-captured there. Keep the old system’s data, or a clean export of it, for as long as your refund window and your accountant require.
05
Does the redirect map really cover collection and paginated URLs?
Yes, and that is the difference between a redirect map and a product export with arrows drawn on it. The map is built from a crawl of the live old site, plus its sitemaps, its own redirect table, Search Console’s page report, server logs where we can get them, and the final URLs of every live ad campaign. Category pages, their paginated and filtered variants, blog archives, tag and author pages, image paths and legacy permalink shapes all get a target. Where the right target is a judgement call — a paginated page with no true counterpart, say — it is a call somebody makes on purpose and records, not a 404 discovered later.
06
Do I get the redirect map as a file I can keep?
Yes. It is delivered as a CSV in the shape Shopify’s redirect importer accepts: one row per source URL, with the destination, the status code, the hop count, and the reason behind any target that was a judgement call rather than an obvious match. It is yours, it outlives the project, and it is the document to reach for on the day somebody asks why a particular URL points where it does. We do not publish a self-serve redirect-map generator. If you want a rough sense of the size of the job before you talk to us, crawl your own site with any crawler you like and count the URLs that return 200.
07
Which platforms do you migrate from?
WooCommerce, Magento and Adobe Commerce, BigCommerce, Wix and Squarespace, and — with a caveat — Salesforce Commerce Cloud. WooCommerce work concentrates on the WordPress URL structure and plugin equivalence. Magento work concentrates on product-type mapping, multi-store views and customer group pricing. BigCommerce is close to parity, so the risk sits almost entirely in URLs. Wix and Squarespace have thin catalogs, so the work is content, design and SEO parity instead. SFCC is enterprise scope and usually lands on a Shopify plan tier we do not sell into.
08
Does my analytics history move across?
No. It stays in the tool that recorded it, which is why the first thing we do is freeze and export a baseline while the old store is still running. After that the goal is continuity rather than migration: same property and same measurement identity wherever the platform allows, the same event names and parameters on the new store, campaigns repointed to new URLs rather than left to redirect, and one clearly annotated cutover so the comparison afterwards means something.
09
What is included in the $14,000, and what pushes it above?
Included: up to 2,000 SKUs, five weeks, the store built on a Liquid theme, catalog and customer and order data imported, a full 301 redirect map built from a crawl rather than an export, the analytics baseline preserved across the cutover, a post-migration data-integrity reconciliation report, and the 30-day bug warranty. Above it: more SKUs or a large variant count, more than one source store, multi-currency or multi-language, B2B or customer-group pricing, subscriptions, content volume in the hundreds of pages, and any ERP, 3PL or accounting integration — which is the Order Ops Bridge at $9,500 and is quoted separately. Change orders run at $135/hr, scoped and approved in writing before anyone starts.
10
Do you take Shopify Plus or enterprise projects?
No. We do not bid Shopify Plus enterprise work, and we do not do greenfield headless rebuilds for small merchants. We build on Liquid for live stores on Basic, Grow or Advanced. Saying that plainly costs us some enquiries and saves everybody the ones that would have gone badly.
11
What happens to the old site after cutover?
The domain is what carries the value. In the simple case it points at Shopify after cutover and Shopify serves the redirects from the imported map. If part of the old site stays live on the same domain — a blog on a different host, for instance — that split has to be designed in advance rather than discovered, because two systems answering for one domain is how redirect loops and duplicate content start. Either way, do not decommission the old platform until the reconciliation report is signed off and you have your exports.
12
What if something is wrong after launch?
Defects in work we delivered are fixed at no charge for 30 days. If we miss an agreed delivery date you get a 25% credit toward the next engagement — a credit, not a cash refund. The warranty and the credit do not cover defects inside third-party apps, delays on your side, or platform incidents. If you want the money path watched after the warranty ends, that is Integrity Watch at $1,200/mo, and it is optional.

Start with the URLs

Send the URL of the store you are moving and we will tell you its shape

Three answers decide most of this: which platform you are on, roughly how many SKUs and variants you carry, and whether the old site is still live enough to crawl. They tell us whether this is a five-week project at the published price or something that has to be quoted properly, and they fit in one email rather than a discovery call.

Where to start

Scoping, in one email

Platform, SKU count, whether the old site is still up. You get a yes, a no, or a number back.

Send your store URL for scopingFree scan of a store already on ShopifyShopify development services

Or write to us directly: support@carrtelsolutions.com