Will I lose my Google rankings?

Not if the redirect work is done before the switch rather than after it. Every old URL is crawled and mapped to its new address, the map is uploaded before anything else on cutover day, and Search Console is watched for thirty days afterwards. Expect a couple of weeks of visible movement while Google re-crawls — that is normal and it settles. Expect a permanent drop only if the redirects were skipped.

Do my customers keep their logins?

No. Passwords are stored in a form that cannot be transferred between platforms, so every customer has to set a new one. This is not a flaw in the migration, it is how password storage works everywhere. It does need an email to your list explaining it before they find out at checkout, and writing that email is part of the job.

Does my order history come across?

Usually yes, as records. Past orders can be imported so your history, reporting and customer lifetime value survive, but they arrive as historical entries rather than live orders you can refund or fulfil through the new platform. Refunding an old order still happens in the old system or directly in the gateway. That distinction needs to be clear before we start.

What about my subscriptions?

Assume they do not move. Recurring billing is tied to card tokens held by the original gateway, and those tokens belong to the gateway, not to your store. Sometimes a token migration is possible between accounts on the same processor, but it is a separate request with its own timeline and its own approval process. Any quote that treats subscriptions as part of a standard migration has not read the problem.

Will the shop be offline during the switch?

There is a short window where orders are paused so the final data export is clean, and it is planned rather than improvised. The new store is built and tested in full before that window opens, so the switch itself is DNS and redirects rather than construction.

When do you do the cutover?

Tuesday or Wednesday morning, never Thursday or Friday. If something surfaces afterwards — a redirect pattern that missed a page type, a payment setting that behaves differently under load — we want a full working week to deal with it rather than discovering it on a Saturday with nobody available.

E-commerce

Store migration

Moving a shop between platforms with the products, the customers, the order history and — most importantly — your position in Google still intact.

From: $800–$5,000
Typical time: 2–4 weeks
Usually bought by: Growing stores

Why owners pay well for this

Nobody migrates a working store for fun. They migrate because the current platform has become a tax — it is slow, it breaks, the maintenance bill keeps climbing, or the business has grown past what the setup can carry and every new requirement turns into a fight.

And yet they hesitate for a long time before doing it, because the store is the business and the fear is entirely rational. Three years of orders. A customer list. A Google position built slowly and paid for in effort. The genuine possibility of waking up two weeks after the switch to a traffic graph that has fallen off a shelf and no idea which of four hundred URLs is responsible.

That fear is the service. What is being bought is not a data transfer — data transfer is the easy part and there are tools that do most of it. What is being bought is somebody who knows in advance which parts of the store do not survive the journey, says so before the contract is signed rather than after the switch, and treats the redirect map as the centre of the project rather than a task at the end.

Three things reliably do not move, and all three have to be on the table in the first conversation. Customer passwords do not transfer — everyone re-registers, and that needs an email that explains why without sounding apologetic. Subscriptions do not transfer — the card tokens belong to the old gateway. Reviews usually live inside an app rather than in the store, so they need a separate export and import, and if the app is being replaced they may need re-matching to products by SKU.

How the work runs

Count everything, then crawl everything. Products, variants, customers, orders, blog posts, static pages, and every URL currently indexed. The crawl is the foundation of the redirect map and it happens at the start, while the old store is still live and complete. Two to three days.
Build the destination. Structure, collections, navigation, templates and theme on the new platform, so there is somewhere correct for the data to land. Payment and shipping are configured here and tested independently, because they behave differently on every platform and are a common source of post-launch surprises. Three to five days.
Move the data, in a rehearsal first. Products with variants, images and SKUs, customer records, order history as records, blog and pages. Run once into a test store, check the failures, fix the mapping, then run again. Matrixify or a migration service handles the volume, but the checking is manual — a spot check on the largest, the strangest and the ones with the most variants. Three to six days.
Build the redirect map and read it. Every old URL pattern mapped to its new address in a spreadsheet, then checked by hand for the patterns tools always miss — paginated category pages, filtered URLs that got indexed, old blog paths, and whatever legacy structure the site carried from a previous life. Two to four days.
Cutover, on a Tuesday or Wednesday morning. Orders paused, final delta export, DNS switched, redirect map uploaded first, then a live crawl to confirm nothing is returning a 404 or chaining through three hops. A live test order placed and refunded before the shop is reopened. One day.
Thirty days in Search Console. Watching coverage, 404s and impressions, fixing what surfaces, and telling you plainly which movements are the normal re-crawl settling and which are a signal. Thirty days elapsed.

The tools — a crawler for the URL inventory, Matrixify or a migration service for the bulk data, a spreadsheet for the redirect map because it needs to be readable by a human, and Search Console for the aftermath.

What moves the price

The range is $800–$5,000 over 2–4 weeks.

How much organic traffic is at stake. This is the single biggest factor. A store with no search traffic is effectively a new build with imported data, and it prices like one. A store with substantial organic traffic makes the redirect work close to half the project, because every URL pattern has to be found, mapped and verified rather than approximated.

Catalogue size and data hygiene. Three hundred products with clean SKUs is straightforward. The same three hundred with duplicate SKUs, prices living in image files, and variants that were faked with separate products is a data cleaning job first and a migration second. That cleaning is billed separately and honestly, because it is genuinely separate work.

Whether history, subscriptions and reviews are in scope. Products and customers are the baseline. Importing years of order history, arranging a token migration for recurring billing, or moving a review archive and re-matching it to products each add their own workstream.

Where migrations go wrong

Redirects are treated as a finishing task. The new store looks good, it launches, everyone is pleased, and the redirect map is on the list for next week. Two weeks later organic traffic has fallen sharply, the owner calls in a panic, and now the old URLs have to be reconstructed backwards from Search Console and archive pages — slower, incomplete, and after the damage. The map is built before cutover from a crawl of the live site, and it is the first thing uploaded on the day.

Somebody promises nothing will change. It is a comfortable thing to say and it is not true. Passwords go. Some layout changes because the new platform's templates are not the old ones. Search results move for a fortnight while Google re-crawls. Stating all three in the first meeting costs nothing and turns a normal event into an expected one. Not stating them turns a successful migration into a complaint.

The switch happens on a Thursday or a Friday. It feels sensible to launch heading into a quiet weekend. It is the opposite. Payment settings under real load, a redirect pattern that missed a page type, an email template that did not carry over — these surface within twenty-four hours and need people available. Cutting over on a Tuesday or Wednesday morning buys a full working week to fix anything the rehearsal did not catch.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Will I lose my Google rankings?: Not if the redirect work is done before the switch rather than after it. Every old URL is crawled and mapped to its new address, the map is uploaded before anything else on cutover day, and Search Console is watched for thirty days afterwards. Expect a couple of weeks of visible movement while Google re-crawls — that is normal and it settles. Expect a permanent drop only if the redirects were skipped.
Do my customers keep their logins?: No. Passwords are stored in a form that cannot be transferred between platforms, so every customer has to set a new one. This is not a flaw in the migration, it is how password storage works everywhere. It does need an email to your list explaining it before they find out at checkout, and writing that email is part of the job.
Does my order history come across?: Usually yes, as records. Past orders can be imported so your history, reporting and customer lifetime value survive, but they arrive as historical entries rather than live orders you can refund or fulfil through the new platform. Refunding an old order still happens in the old system or directly in the gateway. That distinction needs to be clear before we start.
What about my subscriptions?: Assume they do not move. Recurring billing is tied to card tokens held by the original gateway, and those tokens belong to the gateway, not to your store. Sometimes a token migration is possible between accounts on the same processor, but it is a separate request with its own timeline and its own approval process. Any quote that treats subscriptions as part of a standard migration has not read the problem.
Will the shop be offline during the switch?: There is a short window where orders are paused so the final data export is clean, and it is planned rather than improvised. The new store is built and tested in full before that window opens, so the switch itself is DNS and redirects rather than construction.
When do you do the cutover?: Tuesday or Wednesday morning, never Thursday or Friday. If something surfaces afterwards — a redirect pattern that missed a page type, a payment setting that behaves differently under load — we want a full working week to deal with it rather than discovering it on a Saturday with nobody available.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Store migration All E-commerce services