No standard export, no documented schema and no migration tool. The project begins by discovering what the system actually holds and proving it can be extracted repeatedly.
Everything else depends on it, and it cannot be assumed.
A bespoke platform has no export standard, no published schema and no migration tool written for it. So the project does not start with mapping. It starts with establishing what the system holds and whether it can be got out reliably more than once.
Access is the first question. A database replica, a read-only account, an API somebody wrote for a partner, or a nightly file drop each imply a different method and a different level of confidence. Systems where extraction can only be done once, by hand, are the hardest to migrate safely, because you cannot rehearse.
Schema discovery follows. In-house systems accumulate meaning in unexpected places: status flags that encode business rules, price fields overridden by a table nobody documents, product relationships expressed by naming convention. Reading the code that writes the data is usually faster than interviewing people about it.
Because of that uncertainty, these projects are staged deliberately. A small sample, validated in detail. A larger segment, validated again. Then a full run with a rehearsed cutover. The scope is fixed after the first two stages rather than promised on day one, and we say so before anyone signs anything.
Six questions. The answers set the price and the method.
| Question | What it establishes | The risk it retires |
|---|---|---|
| How can data be extracted? | Database access, an API, exports or a file drop, and whether it repeats | A one-shot extraction that cannot be rehearsed or corrected |
| What does the schema mean? | Which fields carry business rules rather than values | Migrating data faithfully and losing the logic attached to it |
| Where is the media? | File storage, naming and whether every reference resolves | A catalogue that imports with missing or wrong images |
| What is the URL structure? | Route patterns, read from the routing code and a crawl | A redirect map that misses whole families of routes |
| Who else reads this system? | Integrations, reports and internal tools depending on the source | Breaking a finance or warehouse process nobody mentioned |
| What must survive? | The records the business is legally or operationally required to keep | Discovering a retention obligation after the source is switched off |
Discovery is a bounded piece of work with its own deliverable. It is credited against the migration where the project proceeds, so the diagnosis is not a way of selling the build.
These are the findings that change an estimate.
A status column that changes how a price is calculated, a flag that suppresses a product from one channel, a nullable field that means three different things. These have to be found and turned into explicit destination behaviour.
In-house systems frequently compute price at render time from several tables. Shopify needs a price on a variant, so the calculation has to be either resolved into stored values or reproduced in the destination architecture.
Reports, warehouse screens, customer service tools and spreadsheets that read directly from the source database. Each is a stakeholder in the migration, and they are usually discovered late.
Duplicate customers, orders with no addresses, products in no category. A bespoke system tolerates what it was written to tolerate. Shopify will not, and cleaning is part of the project rather than a prerequisite you are handed.
Find these in the sample stage, where they are cheap.
There is no rewrite table, so both sources are needed.
On a bespoke platform, the route patterns are in the application. Reading them alongside a crawl gives coverage neither method reaches alone.
Bespoke systems commonly serve several generations of URL at once. Finding those layers before the switch is the difference between a clean move and a quarter of unexplained decline.
Under uncertainty, the method matters more than the plan.
Swipe the parts
Design
Bespoke storefronts often have behaviour the business depends on and no theme provides. That behaviour is identified explicitly and either rebuilt or dropped as a decision, not by omission.
Systems
Anything reading the source database needs a destination. Some point at Shopify’s API, some need an intermediate, and some are retired because the system replaces them.
Proof
A sample, then a segment, then the full run. Each stage validated in detail, with the transformation scripts versioned so a run can be repeated exactly.
Switch
The cutover is rehearsed at least once. The source stays running read-only afterwards, because on a bespoke system it is the only copy of the history.
Uncertainty is the cost. Discovery is how it is reduced.
These projects are priced after discovery, and these are the factors that decide the figure.
The estimator routes bespoke and export-only sources to manual scoping deliberately. A band produced from five questions would be too wide to inform a decision, and quoting one anyway would be dishonest.
Published starting figures in GBP and USD, excluding VAT.
Scoped in stages, after source access
One bounded piece
£1,500$2,000
One bounded improvement: landing pages, a template rebuild, an analytics implementation, or a build-readiness review credited against a larger project.
Fixed price
Data only
From £1,000From $1,300
Products, customers, orders and content mapped into a Shopify store that already exists or is priced separately. Fixed once source access and a sample migration are reviewed.
Starting price · scoped after discovery
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Discovery is bounded and priced separately, then credited against the migration where the project proceeds. Fixed scope follows the sample stage rather than preceding it.
Usually, provided the data can be reached. A database replica, a read-only account or a scheduled export is enough to work with. What matters more than support is whether extraction can be repeated, because a one-shot export cannot be rehearsed.
That is the normal case. Schema meaning is recovered by reading the code that writes the data and by validating assumptions against a sample. It takes longer than a documented source, which is exactly why discovery is a separate, bounded stage.
We do not. Discovery is quoted on its own and credited against the migration if the project proceeds. Anything quoted as a fixed migration price before source access has been reviewed is a guess that will need revising.
Not always. Bespoke platforms sometimes contain genuine application behaviour that has no business being a storefront. In those cases the honest recommendation is a store plus a separate application, rather than forcing everything into a commerce platform.
A sample of real data tells us more in an hour than a specification document written from memory.
