Half of the quote you get for moving a store is decided by what you send the developer before they write it. People who search for an e-commerce platform migration price have usually collected two or three offers already and are staring at a single “from” figure with no explanation of where it comes from or what hides underneath it. This is not another price list. It is a guide to reading those offers: what belongs in them as a separate line, which things push the cost up on your side, and what to prepare so that the first number you are given is also the final one.
What an e-commerce platform migration price is made of
The easiest way to understand a quote is to stop treating it as “moving the store” and split it by how much of each line is machine work and how much is a person. In practice the job falls into four buckets, and each one is priced in a completely different way.
- The part a script handles. A product catalogue in a standard shape: name, description, price, image, a simple category. Export, remap the columns, import. Volume matters here, difficulty does not, so two thousand products cost little more than two hundred.
- The part somebody has to rewrite by hand. Variants assembled in the old platform in its own way, custom fields, attributes used for something other than their name suggests, descriptions with markup embedded in them, promotions hard-coded into products. Every one of those is a separate decision about how it should look on the other side. This bucket can end up costing more than the whole catalogue.
- The part built from scratch. The template, shipping and tax configuration, payment gateways and carriers, customer accounts, transactional emails. None of it travels with you, so it is rebuilt regardless of how many products you have.
- The part that happens after the switch. Watching indexing, catching addresses that slipped through, fixing the checkout after the first real orders. The line most often left out of a quote, and the one that decides whether the move ends well.
Rough money brackets I wrote up separately, in the piece on what an online store migration costs. Here I deliberately give no figures, because a price without a breakdown tells you nothing, and with a breakdown you can work it out yourself.
The “from” offer and the lines it usually leaves out
The “from” figure is normally honest: it describes the simplest possible case. The trouble is that your store is almost never the simplest possible case, and you only see the difference once you compare the offer against the list of things a migration has to include. Four lines go missing most often.
The first is a map of old and new addresses with the redirects. Not the word “redirects” buried in a scope description, but an actual line that says where the list of addresses will come from. This is what saves your traffic from Google, and the whole mechanism sits in a separate piece on migrating without losing search positions.
The second is order history and customer data. Plenty of hosted platforms will not hand those over through a normal export, so they have to be extracted another way. If an offer says nothing about them, ask outright whether they are in scope.
The third is testing payments with real money. A gateway in test mode can behave perfectly and then fall over in production on some small piece of configuration. A handful of one-cent transfers before launch is a line nobody enjoys quoting, and it catches the errors before a customer does.
The fourth is the switchover window and cover for the first few days. Flipping the domain on a Wednesday morning and flipping it on a Friday evening are two different levels of risk. Ask when it is meant to happen and who is reachable the next day.
What pushes the cost up: data, integrations, search positions
This is the interesting part, because a good share of it you can reduce yourself before you even send the enquiry. A quote grows less with the size of a store than with the amount of mess inside it.
Products nobody sells any more. In most of the stores I have moved, a sizeable slice of the catalogue turns out to be discontinued items, test entries or duplicates left behind by years of changes. Each of them goes through exactly the same process as a product that actually earns. Reviewing the catalogue and retiring the dead entries before the migration is the cheapest way to bring the price down.
Variants built several different ways. When some products carry size as a variant and others as a separate product with a suffix in the name, migration stops being mapping and becomes tidying up. If you know that is the case, say so in the enquiry rather than letting the developer discover it halfway through.
Integrations nobody uses. When moving, it is tempting to ask for “the same as we have now”. It is worth checking first which plugins and connections actually do anything. Every integration dropped is one configuration and one test fewer in the quote.
The number of addresses sitting in Google. This is the one factor on the list you do not want to shrink artificially, but you do need to know it. A store with three hundred indexed addresses and a store with thirty thousand are completely different jobs for the mapping work, even with the same number of products. Filters, sorting and pagination can multiply addresses in ways the admin panel never shows you.
Content that has to be rewritten. Category copy, information pages, terms with the old platform’s name inside them. It is not development work, but somebody has to do it and it will land somewhere in the quote.
How to prepare a store for a migration quote
This is the heart of the piece. You can gather the list below in one afternoon, and the difference between an enquiry with it and an enquiry without it is the difference between a price and a guess. I described the same logic once for websites, in the piece on what to send to get a concrete quote; with a store, data and integrations come on top.
- The name and version of the current platform. “A store on Shopify” and “Shopify on an old theme from before the rebuild” are different jobs. If the store was ever customised beyond the standard, say so.
- Numbers from the admin panel, not from memory. How many products, how many of them active, how many have variants, how many customers hold accounts, how many orders are in the history. Every one of those numbers takes one just-in-case buffer out of the quote.
- A sample export. Export a hundred products to a file and attach it. Nothing shortens a quote like being able to look at real data instead of imagining it. If the file shows variants stuffed into one comma-separated column, the developer learns more about your store than three paragraphs of description would tell them.
- The integrations, by name. Payment provider, couriers and pickup points, accounting, stock, newsletter, price comparison feeds, suppliers. Next to each, note whether it stays or goes.
- The address list and the traffic data. Your sitemap and a Search Console export for the last three months. That is the raw material for the redirect map, and the only way for anyone to judge how much SEO risk the move carries.
- The deadline and your season. Say when you want it done and when your sales peak. Moving three weeks before the busiest period of the year is possible, but it needs a different schedule than a move in a quiet month.
- Who decides on your side. One contact who can sign off on the design, the copy and the switchover date. Projects stretch more from the absence of that person than from any technical problem.
With that set in hand, the enquiry stops sounding like “how much does it cost to move an online store” and starts reading like a defined project with a defined scope. On my side that package turns into a quote with a date and no discovery call first, and that is how the WooCommerce migrations I run begin.
What cannot be priced upfront, and how to settle it
An honest answer about price also contains a sentence about what nobody knows yet. Usually three things: the real quality of the data in the old database, whether a closed platform will hand everything over through its export, and the state of copy that people have been adding for years. None of that can be judged from the outside without access.
There are two fair ways to handle it. The first is a short discovery pass on a data sample, priced separately and deducted from the project if it goes ahead. The second is staged pricing: a price for the part that is visible, and a separate decision about the rest once a trial export exists. Both beat the third option, where the developer quietly adds an invisible buffer to one number and you pay for their uncertainty even if your data turns out to be fine.
There is only one genuine warning sign: an offer that never mentions uncertainty at all and quotes a price without asking a single question about your data. Either the buffer is in there silently, or the reality will hit halfway through and the conversation about a change order starts then.
Frequently asked questions
Does the price depend mainly on the number of products? Less than people expect. Catalogue size drives import time, but the quote is affected far more by how many different shapes your variants and custom fields come in, and by how many integrations have to be rebuilt.
How do I get a lower quote without cutting scope? Tidy the catalogue before the migration: retire dead products, make variants consistent, and drop integrations nobody uses. Those are the only savings that take nothing away from the finished store.
Can I compare offers on the figure alone? Not until the same lines appear in all of them. Before comparing numbers, check that each offer includes redirects, order history, payment testing and post-launch cover. Usually the cheapest offer is cheapest because two of those four are missing.
How long does it take to gather the material for a quote? An afternoon. Panel numbers, a sample export and the integration list are two or three hours of work, and they cut the road to a price from several days to one.
On Shopify, PrestaShop or a local SaaS and thinking about moving? I run migrations to WooCommerce without losing search positions and without pausing sales. Let’s talk about your project.