Moving your shop: what comes with you, and what does not

The move nobody tells you the truth about

The honest version of a shop migration does not start with a demo. It starts with a list of everything you have accumulated on a platform you rent, and a plain answer, for each item, to one question: does this come with me, does it take work to bring, or is it stuck here.

Most of what you have moves. Some of it moves only with care. A small, important part of it cannot move at all without the losing platform or your old payment provider actively helping, and if you discover that part halfway through, you are in trouble. The whole trick of a calm migration is to find the stuck parts first, before you have committed to anything, not on cutover morning.

This article is the map for the whole series. It walks through the stages of a real migration, gives you one honest table of what moves and what does not across every kind of data a shop holds, and sends you to a deep dive for each one. The destination throughout is a custom store built on Solidus, the open source Rails ecommerce framework,¹ owned by you, with the data kept first party in the UK or the EU. If you want the money side first, I built a five year cost model for exactly this move in the total cost of ownership article, and I compared the platforms themselves in Solidus against Shopify, Shopware, Magento and WooCommerce.

When you should not move at all

I will say this before anything else, because it is the honest answer for a lot of shops. If your shop is new, small, or doing conventional things, a rented platform is genuinely the right call, and a migration would cost you money and attention you should spend elsewhere. The build is a largely fixed cost that does not shrink much with your revenue, while the platform fees that make renting expensive scale up with it. Below roughly half a million a year in turnover, with ordinary needs, stay where you are.

This series is for the shop that has outgrown the rented platform: the one paying more every year for software it cannot change, hitting a wall every time it wants a real trade price list, a custom checkout, or a feature that no app quite delivers. If that is you, read on. If it is not yet, bookmark this and come back when it is.

What a migration actually involves

A migration is not a switch you flip. It is a short project with a known shape, and the shape barely changes from shop to shop.

It begins with audit and discovery. I go through everything the current shop holds and does: the products and their quirks, the integrations, the custom features hiding inside apps, the payment setup, and the one question that decides the timeline, which is whether there are saved cards or live subscriptions to move. The output is an inventory with an owner against each line.

Then comes data mapping. Two shops almost never model the same thing the same way, so every field in the old system has to be matched to a field in the new one, with the gaps and the conversions written down. This is unglamorous and it is where the real work lives.

Then the build, on the Solidus core. The parts of a shop that are genuinely hard to get right, the checkout, the payment handling, the tax calculation, the inventory and the order state machine, are not rebuilt from nothing. They are the battle tested core of a framework that has run real shops for years,¹ so the build is about your catalogue, your rules and your integrations on top of a core that already works.

Then a parallel run. For a few weeks both shops exist. The old one is live and taking orders. The new one is complete on a staging address, loaded with real data, and tested with real products and test payments. The import scripts are run again and again against a copy of the live data until the result is clean and boring.

Then cutover. On a quiet weekday morning the old shop goes into maintenance mode, a final import brings across everything that changed since the last full one, the domain points at the new shop, and a handful of real orders are placed and refunded to prove every payment method and delivery country works. Done this way, not a single order is lost.

Then verification and reconciliation. Counts are compared, old to new: orders, customers, stock. The top redirects are checked by hand. The old shop stays exactly as it was for thirty days as a fallback, and only then, after a clean month end, is it closed.

Each of those stages has a deep dive of its own below. Here is the map.

What moves, what takes work, and what cannot

Here is the honest table. Every row links to its own article, because every one of these has detail that does not fit a cell. Read the row, then read the piece.

Data type	What comes across	The honest limit
Customers and accounts	Names, email addresses, saved delivery and billing addresses, the links from a customer to their orders	Password hashes do not export, so customers either reset once or sign in with a code.² Marketing consent must travel with its timestamp and wording, not as a bare yes or no.
Products and catalogue	Products, variants, prices, images, categories, stock levels, shipping zones and tax settings	Mostly a mapping exercise between two data models, low risk and high effort. The real danger is the URLs: every old address needs a redirect or the rankings go with it.
Orders and purchase history	Past orders as records, with their lines, totals, addresses and status, so staff and customers can look them up	History imports read only. Acting on an old order, a refund or a return, usually stays with the old system or is handled by hand for a while. Bring a few years, not fifteen.
Analytics and forecasting data	The raw order and event history you need to rebuild a demand picture and keep forecasting	A platform's own aggregated dashboards and attribution models do not come across. You export the raw records and rebuild the history, which is why you take it as data, not as reports.
Payment tokens and saved cards	Saved cards, but only gateway to gateway, encrypted, and only to a processor certified at PCI DSS Level 1	You never see a raw card number, and the security code is never stored.³⁴ Sometimes the token cannot move at all, which is the subject of the hard ceiling below.
Subscriptions and recurring payments	Billing schedules can be rebuilt in the new shop, if the payment tokens behind them can move	The hardest thing in any migration. If the platform locked subscriptions to its own payments product, the schedules and the tokens may not move at all. Solve this before you commit.

Two rows in that table are different in kind from the others. Customers, products, orders and analytics are work: careful, sometimes large, but the answer is always yes with effort. Payment tokens and subscriptions are the ones where the answer can be no, and no amount of my effort changes it, because the thing you need is held by someone else. So those two decide whether the move is simple or hard, and they have to be answered first.

The hard ceiling: payment tokens and live subscriptions

When a customer saves a card, your shop does not hold the card number. The payment provider holds it and gives your shop a token, a reference that only that provider can turn back into a real card. That is the point of it, and it keeps you out of the dangerous part of payment security. It is also why a saved card cannot simply be copied to a new shop. Moving it means the old provider sending the real numbers directly to the new provider, encrypted, to a processor certified at the top tier of the card industry's security standard, and the export deliberately excludes things like your subscriptions and payment history.³ The three digit security code never travels at all, because the rules forbid anyone to keep it once the first payment is authorised.⁴

That is the manageable version, where you own your payment provider account and can take it with you. The ceiling appears when you do not. Here is the anonymised, real cautionary example that sits behind this whole series.

A growing subscription business wanted to move to a setup with lower running costs. Its subscriptions ran on its platform's own built in payments product, which only worked with one named gateway, and the cards behind those subscriptions were vaulted inside that gateway, held by the gateway, not by the business. When it tried to move to a less expensive payment provider, there was no route to bring the vaulted tokens across, because the business did not hold them and the platform would not release them. Moving meant losing the active subscriptions and asking every subscriber to set them up again. A painful share never did. The half finished move, new shop, stranded subscribers, was the worst of both worlds.

The lesson is not that migration is dangerous. It is that this specific question has to be asked and answered before you commit a penny: who actually holds the tokens behind my recurring payments, and will they, or the platform, release or transfer them. If the honest answer is no, that does not kill the move, but it changes the plan entirely, and you want to know on day one, not in month three. The full treatment is in migrating payment tokens and saved cards and migrating subscriptions and recurring payments, and the gateway to gateway mechanics, with a worked plan, are in the hidden dangers of switching payment gateways.

A migration does not have to cost you your rankings

The fear that stops many shops is that moving will wipe out their search traffic. It does not have to, and when it does it is almost always because nobody mapped the URLs.

Every product, category, content page and article on the old shop has an address, and some of those addresses carry years of links and rankings. Different platforms build them differently. The job is to map every old URL to its new one and send each old address to its new home with a permanent redirect. Google's own guidance is specific: use permanent server side redirects such as 301 or 308, point each one straight at the final destination rather than through a chain, and keep the redirects in place for as long as possible, at least a year and ideally for good.⁵ If the domain does not change, you do not even need the Change of Address tool, which is only for a move to a different domain.⁵

The deliverable is an unglamorous spreadsheet: every old URL that drew a visit or a link in the last twelve months, the new URL beside it, the redirect type, and a column that says it was tested. Those are the best days of the whole project, because every missing row is a page that returns an error after cutover. The detail lives in migrating products and catalogue data, where the URLs live.

Why a custom Solidus store is the destination

I build on Solidus for reasons that all come back to ownership. The code is yours, under an open source licence,¹ so no one can price you out of your own shop or switch off a feature you depend on. The data is yours, first party, and it can be kept in the UK or the EU rather than wherever a platform happens to host it, which matters for both the law and your own peace of mind. There is no percentage taken on every order for the privilege of using an outside payment provider. And you are not paying anyone to rebuild the genuinely hard machinery, because the checkout, the payment handling, the tax, the inventory and the order state machine are the proven core of the framework rather than something written fresh for you.¹

Who ends up holding your records, and on what terms, is a bigger question than any one migration, and I wrote it up separately in who actually owns your business data. Moving to a store you own is the practical answer to it.

There is a legal housekeeping point that comes with any move, and it is easy. You stay the controller of your customers' data throughout. The platform, the host and I are each processors, and each needs a written processing contract, which the data protection rules require.⁶ The lawful basis for the data does not change because the software did: order history kept to meet accounting duties stays on that basis, a marketing consent stays a consent. You carry the consent records across with their wording and timestamps, update the privacy notice where it names the old platform, and ask for the old copy to be deleted in writing once the move is done.

A worked example: a Leeds homewares shop

Let me make this concrete with an invented business. Marsden Home sells homewares at marsdenhome.example, out of Leeds. Priya runs it. It turns over about one and a half million pounds a year, has roughly four thousand products with variants, and a small but loved candle subscription that bills a few hundred customers every month. It has been on a rented platform for four years, pays more to the platform and its apps than it would like, and has just been told that the trade price list it wants for interior designers needs a higher plan. Nobody real, every figure invented.

Priya does not start by picking a new platform. She starts with the audit. The products, the integrations with her accounting and warehouse tools, the custom bits that live inside three apps, and above all the candle subscription. That is the line that decides everything, so it goes first. We find that the subscription runs through her own payment provider account, and that the saved cards are vaulted in that provider, under an account she controls. That is the good answer: because she owns the provider account, the new Solidus shop can connect to the same account and the tokens never have to move. Had the subscription been locked to the platform's own payments product, the plan would have changed on the spot, and we would have designed the move around rebuilding those subscriptions rather than carrying them.

With the hard part answered, the rest is work with a known shape. The four thousand products map across cleanly, with a week of careful checking. Order history comes in as three years of read only records, the older archive kept as a file for the accountant. Customers come across with their addresses, and because password hashes cannot be exported, every account arrives flagged as not yet activated, with a plain service message going out before cutover telling customers they will set a password on their first visit. The candle subscriptions keep running on the same payment account, their schedules rebuilt in the new shop. The URL map, about four thousand rows, is the longest single task and the one Priya checks herself, because she knows which old product codes carry years of links.

The build runs on the Solidus core, with the trade price list she could never have on the old plan built in rather than bolted on. For three weeks both shops run in parallel, the old catalogue frozen so nothing drifts, the final import rehearsed twice. Cutover is a Tuesday morning in her quietest month. By mid morning she is live, the domain points at the new shop, a real order has gone through every payment method and come back refunded, and the old shop sits untouched as a fallback for thirty days. The whole thing, from the first audit to closing the old account, runs about four months. The candle subscribers never noticed, which is the entire point.

The honest position

A migration goes well when one accountable person runs it, every record is checked and reconciled rather than hoped over, and the hard constraints are named and planned before anyone commits, not discovered in the middle. That is the thread through every article in this series. The stuck parts, the payment tokens and the live subscriptions, are found on day one. The URLs are mapped so the rankings survive. The old shop is kept alive until the new one has proved itself over a full month. Nothing is glossed, because the trust is in not glossing it.

If you have outgrown a rented platform and want to know, honestly, what your own move would involve and whether it is even worth doing, bring it to a free workshop. I will map what moves, what takes work and what is stuck, in your actual shop, and the first two weeks of work are on me. Sometimes the honest answer is to stay where you are, and if it is, I will tell you so.

Solidus, solidusio/solidus on GitHub (a complete open source ecommerce solution built with Ruby on Rails, under the BSD 3 clause licence), checked 14 November 2026, https://github.com/solidusio/solidus ↩ ↩² ↩³ ↩⁴
Shopify Help Center, Importing and exporting customers (customer passwords cannot be migrated via CSV because they are encrypted outside Shopify), checked 14 November 2026, https://help.shopify.com/en/manual/customers/import-export-customers ↩
Stripe, Request a payment data export (card data transferred only to a PCI DSS Level 1 compliant processor; the export excludes payment history and subscriptions), Stripe documentation, checked 14 November 2026, https://docs.stripe.com/get-started/data-migrations/pan-export ↩ ↩²
PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions? (they may not be retained once the transaction is authorised), checked 14 November 2026, https://www.pcisecuritystandards.org/faqs/1280/ ↩ ↩²
Google Search Central, Site moves with URL changes (permanent 301 or 308 redirects, map every URL, redirect to the final destination, keep redirects at least a year, Change of Address only for a domain change), checked 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩ ↩²
UK GDPR, Article 28 (Processor): processing by a processor is governed by a written contract, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/28 ↩