Key Takeaways
Platform selection cost sits between software fees and build cost. You're paying for the work that tests technical and commercial fit before implementation starts, and the price moves when integrations, migration risk, B2B logic, or architecture decisions need proper analysis.
| What changes the price | Why it matters |
|---|---|
| Integration complexity | ERP, PIM, and CRM dependencies add scoping overhead fast |
| Migration quality | Data cleanup and rule mapping are rarely simple exports |
| B2B requirements | Customer pricing, permissions, and approval flows need deeper review |
| Architecture decisions | Headless adds API dependency, release complexity, and support overhead |
I have seen it enough times to stop being surprised. A team asks for a platform recommendation, gets a shortlist, and then discovers the real cost was never the shortlist. It was the ERP dependency nobody scoped, the migration mess nobody audited, the B2B pricing rules buried in spreadsheets, and the headless architecture idea that looked clever until someone had to own the support overhead.
The short answer: In the UK, eCommerce platform selection typically costs between £2,000 and £5,000 for a focused discovery and shortlist exercise. When ERP integration, migration planning, B2B eCommerce logic, or headless architecture decisions are in scope, that rises to £8,000 – £15,000 or higher. The price is not set by the platform label – Shopify, WooCommerce, Magento, or headless – it is set by the complexity of the systems, dependencies, and commercial rules the platform has to accommodate.
Keep three budget buckets separate from the start: software licensing fees, selection and discovery cost, and implementation cost. Fold them together and the number looks tidy – right up until delivery starts asking harder questions.
This article is for founders, commercial leads, and eCommerce teams budgeting a shortlist, replatform, or scoped discovery before supplier selection.
What you are actually paying for in platform selection
Platform selection cost is not software cost, and it is not build cost. You are paying for the work needed to test technical and commercial fit before a line of code gets written. That distinction matters because lightweight selection work that misses a critical dependency will cost you far more during build than a thorough scoping exercise would have cost upfront. This is why serious teams bring in eCommerce development expertise before they have finalised their brief, not after.
The real job of selection work is to surface failure modes before they become build costs. A high-level recommendation is cheaper because it stays high level. A recommendation that has to survive procurement challenge, stakeholder scrutiny, ERP integration complexity, and engineering reality needs proper scoping underneath it.
- Usually inside scope: requirements gathering, shortlist logic, architecture fit, ERP integration review, PIM assessment, migration risk checks, and delivery assumptions.
- Usually outside scope: full UX design, build specification, implementation, migration execution, and post-launch support.
Cheap selection work is often the most expensive line in the project. The shortlist is rarely where money is lost. Hidden dependencies are.
What changes the price most in UK eCommerce projects
The biggest cost drivers are not the platform labels. Shopify, WooCommerce, Magento, and headless commerce are starting points, not conclusions. Price moves when the project carries more customisation, more system integrations, more migration risk, more B2B eCommerce logic, or more architecture overhead.
A straightforward Shopify fit with light integrations is one thing. A Magento or Adobe Commerce evaluation with ERP rules, customer-specific account pricing, and complex workflow constraints is something else entirely. Headless commerce adds another layer of scrutiny, because you are not just choosing a storefront – you are choosing API dependency, release complexity, maintainability, and support model. I have reviewed projects where the headless question alone doubled the scoping requirement.
Before integration mapping, a project can look like a clean platform shortlist. Then finance, operations, and technical stakeholders join the conversation, and suddenly stock sync, customer-specific pricing, and order-status rules are all in scope. That is usually when a mid-range selection exercise turns into a wider scoping job – and the original budget no longer covers the actual work.
Cost driver matrix: use this to sense-check whether your budget matches the complexity you are actually dealing with.
| Project type | Complexity | Typical UK price range |
|---|---|---|
| Focused platform selection and discovery | Low to moderate, light integrations, limited migration risk | £2,000 to £5,000 |
| Selection plus integration and migration scoping | Moderate, ERP or PIM review, catalogue cleanup, stakeholder workshops | £5,000 to £10,000 |
| B2B eCommerce or multi-system platform evaluation | High, customer pricing, workflow rules, account structures | £8,000 to £15,000 |
| Architecture-led selection including headless commerce decision | High, front-end separation, API dependency, operational overhead review | £10,000 and up, depending on scope |
If requirements are still unclear when pricing is requested, treat that as a scoping problem first, not a platform problem. A project discovery workshop stops a neat quote from becoming pricing fiction. And if headless commerce is on the shortlist, read how headless eCommerce development changes the budget before anyone presents it as a design preference. It is an architecture and operational cost decision, and the teams who treat it otherwise regret it.
Not sure which platform fits your integrations and migration risk?
Most platform selection mistakes happen before the shortlist, not after. We run focused discovery sessions that test technical fit, integration dependencies, and migration complexity before you commit to a build direction.
No obligation. Just a clearer view of what the project actually needs.
The budget lines most teams forget – and pay for later
The selection exercise is one cost. What comes after it is where most UK eCommerce projects lose control of the budget – because the lines that sit outside the shortlist rarely make it into the original approval.
ERP integration scoping is its own workstream. If your ERP drives pricing logic, inventory rules, or order routing, platform fit cannot be assessed without understanding those dependencies. That work takes time, and it costs money separately from the platform comparison itself.
Migration planning is another standalone item. Export-and-import is not a migration strategy. Catalogue structure cleanup, redirect mapping, URL slug decisions, historical order data, and pricing rule translation all need scoping before a migration figure can be trusted. Skipping this is how replatform projects end up with an agreed build cost and a surprise six-figure migration bill six weeks in.
Ongoing maintenance sits outside all of it. Whether you land on Shopify, WooCommerce, or Magento, the platform choice has a direct bearing on the long-term support model – who owns releases, who handles security patches, and what happens when a third-party integration breaks. If you are already thinking past launch, factor in eCommerce maintenance from the start. Whether a platform makes commercial sense six months after launch depends heavily on what it costs to keep running.
- Check whether discovery includes ERP integration scoping or only platform comparison.
- Establish who owns data mapping, customer pricing rules, and migration cleanup.
- Confirm whether PIM, custom checkout optimisation, or account-level logic has its own budget line.
- Do not leave post-launch maintenance and change request costs out of the total cost of ownership.
For the full delivery picture after selection, compare scope against eCommerce development cost in the UK.
Red flags that usually mean the budget is already wrong
Low budgets usually show up in the brief before they show up in the quote. If someone wants a platform recommendation before requirements, integrations, migration quality, or B2B eCommerce rules are even partially understood, that is a warning. So is any estimate that jumps from shortlist to build confidence without showing the assumptions underneath.
The pattern I see repeatedly: finance approves a low estimate because the shortlist looks simple, technical stakeholders review the actual dependencies, and the number moves fast. Nobody enjoys that meeting. It almost always means the original budget was never based on real scope.
Headless commerce is a consistent trap in this bracket. When it appears in a brief as a visual or brand preference rather than an architecture and operational cost decision, push back immediately. The questions that need answering are: who owns the front end, how does the release cycle work, what happens when an API dependency fails, and what does that add to the support model? Without answers to those, headless is technical debt sold as ambition.
- No integration map for ERP, PIM, CRM, or fulfilment systems in the brief
- Migration scoped as export and import, with no data cleanup or rule mapping
- B2B pricing, account permissions, or approval flows described as minor configuration
- Support costs, maintainability, and operational overhead absent from the total budget
When a free scoping review is the right next step
If the shortlist still feels vague, or the budget keeps shifting every time integrations come into the conversation, do not rush the platform decision. The right move is a scoped review that stress-tests assumptions, clarifies who owns what, and shows where the budget is thin before anyone commits to a build.
Questions teams ask before budgeting platform selection
Common questions about scoping, pricing, and what's actually included in UK ecommerce platform selection work.
1. What does ecommerce platform selection cost in the UK?
A focused discovery and recommendation exercise typically costs between £2,000 and £5,000. When integration scoping, migration planning, B2B rules, or architecture decisions are included, the cost moves into the £5,000 to £15,000 range. The price depends on how much technical and commercial complexity needs testing before the platform decision can be finalised.
2. Is platform selection cost separate from implementation cost?
Yes. Selection cost covers the work needed to test fit and reduce risk before build starts. Implementation cost covers the actual build, migration execution, and launch. Mixing the two budget lines together makes the number look tidy until delivery starts asking harder questions about dependencies, integrations, and operational overhead.
3. What's usually included in platform selection work?
Typically: requirements gathering, shortlist logic, architecture fit assessment, integration review, migration checks, and delivery risk analysis. Full UX design, detailed build specification, implementation, migration execution, and post-launch support usually sit outside the selection scope and need separate budget lines.
4. Why does B2B ecommerce platform selection cost more?
B2B projects carry customer-specific pricing, account structures, approval workflows, and permissions logic that need proper scoping. These requirements change how the platform handles orders, pricing, and user access, so the selection work has to test whether the shortlist can support those rules without heavy customisation or operational workarounds.
5. Does headless commerce change the selection budget?
Yes. Headless adds architecture complexity because you're choosing API dependency, release coordination, front-end ownership, and support overhead, not just a storefront. That means the selection work needs to test maintainability, scalability, and operational risk more deeply than a traditional platform comparison would require.
6. What's the biggest cost driver in UK ecommerce platform selection?
Integration complexity. ERP, PIM, CRM, and fulfilment system dependencies add scoping overhead fast. A project that looks like a simple shortlist can turn into a wider scoping exercise once finance, operations, and technical stakeholders review stock sync, customer pricing, and order-status rules.
7. How do I know if my platform selection budget is too low?
If the brief asks for a platform recommendation before requirements, integrations, migration quality, or B2B rules are understood, the budget is probably thin. Another warning sign is any estimate that jumps from shortlist to build confidence without showing the assumptions, dependencies, or risk factors underneath.
8. Should migration planning be part of the selection budget?
It depends on scope. A lightweight recommendation might stay high level. But if the platform decision has to survive procurement, stakeholder challenge, and engineering reality, migration planning should be included. Data cleanup, rule mapping, and dependency checks are rarely simple exports, and ignoring them early makes the selection less reliable.
Conclusion
The shortlist is rarely the expensive part. The cost shows up when integrations, migration dependencies, and operational overhead get scoped properly. Before finalising the platform decision, make sure the budget reflects the real complexity.
- Separate discovery cost from implementation cost. Selection work should clarify fit and risk before build starts, not during it.
- Map integrations early. ERP, PIM, and fulfilment systems usually add more scoping work than the platform comparison itself.
- Test headless assumptions before committing. If it's being discussed as a design choice rather than an engineering and support decision, push back.
- Budget for post-launch support from the start. Ongoing maintenance and change requests sit outside the selection exercise but determine whether the platform choice still makes commercial sense later.
Ready to scope your platform selection project with proper integration and migration planning?
WEBDIGITA runs ecommerce platform selection and discovery projects across London and the UK. We help teams test technical fit, map integration dependencies, and assess migration risk before build starts. No shortcuts. No guesswork.
See how we approach selectionOr if you prefer,
