eCommerce replatforming means moving your online store to a different commerce platform. It can improve customer experience, simplify operations and give your business room to grow. It also requires careful decisions about investment, technology and the people responsible for delivery.
A successful move starts with a clear business case. Before comparing platforms or requesting proposals, understand what is holding your store back, what improvement is worth and how you will measure success.
At OSE, we approach replatforming as a review of the complete commerce operation: the customer experience, the systems behind it and the team responsible for keeping it reliable. This guide explains how to assess your current agency, evaluate prospective partners, compare platform capabilities and plan the cost and timeline of a migration.
1. Decide whether you need to replatform
Slow development, rising maintenance costs and frustrating customer experiences can all trigger a platform review. However, those symptoms can also come from poor implementation, unnecessary apps, weak product data or an agency that lacks the right expertise.
Audit your current store across four areas:
- Commercial performance: Conversion rate, average order value, repeat purchases and contribution margin.
- Customer experience: Mobile usability, search, navigation, checkout and accessibility.
- Operations: Manual work, stock accuracy, order processing and integration reliability.
- Technology: Performance, maintenance burden, security responsibilities and development constraints.
Separate problems the existing platform can reasonably solve from structural limitations. If a focused improvement programme can achieve your goals at lower cost and risk, include that option in the business case.
For trade businesses, include customer adoption in that assessment. Our article on moving B2B phone orders online explores the practical changes that help customers use the digital channel. A migration business case should explain how the new experience will support that behaviour.
Define the trigger for moving in concrete terms: supporting wholesale pricing, entering new markets, reducing order-processing work or removing a checkout constraint. “We need a better website” is too vague to guide a major investment.
2. Assess your current agency before changing partners
Your current agency holds valuable knowledge about your store. Assess its performance objectively before deciding whether it should lead the migration, support the transition or be replaced.
Review delivery against agreed scope, budget and timing. Ask whether recommendations address business outcomes, whether recurring issues are resolved and whether documentation allows another team to maintain the store.
A useful review should establish:
- Who owns and controls the code, domains, accounts, data and integration credentials.
- Whether you receive clear reporting on development work and results.
- How confidently the agency works with your proposed platform and integrations.
- Whether performance problems reflect platform constraints or implementation decisions.
- How handover, documentation and transition support would work.
If you decide to change partners, our guide to changing eCommerce agencies without disrupting your business explains how to organise access, documentation and a controlled handover. Build that transition into the migration plan early.
An agency may be excellent at maintaining your current store but lack experience with a complex migration. Equally, replacing a capable team will not fix an unsuitable platform or unclear internal decision-making.
3. Compare prospective agencies using the same brief
Give shortlisted agencies a consistent brief covering your objectives, current architecture, integration requirements, budget parameters and preferred launch window. This makes proposals easier to compare.
Ask to meet the people who will deliver the work. Request relevant references and examples of migrations with similar operational complexity, then ask what happened after launch.
Evaluate discovery quality, integration experience, migration planning, SEO capability, quality assurance and ongoing support. Ask each agency to explain its assumptions, exclusions, dependencies and process for approving scope changes.
Evaluate the relationship beyond the launch project. Our eCommerce support agreement checklist sets out questions about coverage, incident ownership, maintenance and reporting. Discuss these responsibilities while selecting the implementation partner.
A low quote may exclude content migration, redirects, data cleansing, testing or internal training. Compare the complete delivery obligation and ongoing commercial arrangement, including support hours, response expectations, warranties and exit provisions.
4. Look beyond platform feature lists
A feature checklist is a starting point. The more useful question is how each platform supports your actual workflows and what happens as those workflows become more demanding.
For every critical requirement, identify whether it is delivered natively, through an app, through an integration or through custom development. Confirm which subscription tier is required and who maintains each dependency.
Test realistic scenarios: complex variants, customer-specific prices, multiple warehouses, international catalogues, subscriptions, promotions, returns and high order volumes.
Technical ceilings can include API limits, checkout restrictions, catalogue structures, search behaviour and constraints on custom business logic. These vary by platform, plan and implementation, so validate them against current documentation and a practical demonstration.
B2B pricing is a useful example. Our article on contract pricing, customer price groups and ERP integration explains why the meaning and precedence of a price matter throughout the buying journey. Use representative customer agreements to test platform fit.
Ask agencies to show how the proposed architecture handles your hardest workflow. A proof of concept for a critical integration can expose a costly assumption before the full build begins.
5. Understand total cost of ownership
The build fee is only one part of total cost of ownership, or TCO. Compare options over a consistent period, such as three years, using the same assumptions for order volumes, markets and growth.
| Cost category | What to include |
|---|---|
| Initial delivery | Discovery, design, development, integrations, migration, SEO and testing |
| Platform and infrastructure | Subscriptions, hosting where applicable, environments and usage charges |
| Apps and services | Search, reviews, subscriptions, personalisation and other paid tools |
| Transactions | Payment processing and applicable platform transaction charges |
| Ongoing delivery | Support, maintenance, upgrades, monitoring and optimisation |
| Internal effort | Content, data preparation, approvals, training and project management |
| Transition and risk | Overlapping contracts, contingency, cutover and stabilisation |
Model likely cost increases as transaction volumes, contacts or catalogue size grow. Avoid counting costs twice when they are already included in a platform or support agreement.
For wholesalers and distributors, our guide to B2B eCommerce costs, platforms and ERP integration provides further context for scoping the investment. Use it alongside a project-specific estimate that reflects your catalogue, customer accounts and integrations.
Compare the migration against the cost of continuing with your current setup. The relevant investment is the difference between realistic alternatives.
6. Build the return around profit and measurable savings
Revenue growth alone does not establish a return. Estimate incremental contribution after variable costs, verified operating savings and additional ongoing expenses.
For example, suppose a migration requires an incremental investment of $120,000. If it generates $8,000 in additional monthly contribution and $2,000 in monthly operating savings, while adding $3,000 in monthly running costs, the estimated net benefit is $7,000 per month. Simple payback is approximately 17 months after those benefits are fully achieved.
This is an illustrative calculation, not a forecast. A fuller model should account for implementation timing, gradual adoption, transition disruption and the time value of money.
Build conservative, expected and optimistic scenarios. Document assumptions about traffic, conversion, margin and staff time, and avoid counting the same benefit twice. Assign an owner and measurement method to each expected improvement.
7. Use discovery to resolve uncertainty
Discovery should produce decisions and evidence that make delivery more predictable.
Bring eCommerce, marketing, operations, finance and technology stakeholders into the process. Map customer journeys and business processes, inspect data quality and document how systems exchange information.
Expected outputs should include a prioritised scope, proposed architecture, integration specifications, data migration plan, SEO requirements, acceptance criteria, delivery schedule and revised cost estimate.
Separate launch requirements from later improvements. Resolve major uncertainties through technical investigation or prototypes, and record who owns each dependency.
The result should give both your team and the agency a shared definition of what must be delivered before launch.
8. Make performance an acceptance criterion
Set measurable performance expectations before design and development begin. Test representative product, category, search and checkout journeys with realistic catalogue data, third-party scripts and mobile conditions.
Core Web Vitals assess loading performance, responsiveness and visual stability. Google’s published “good” thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, assessed at the 75th percentile. Use these alongside journey testing and operational monitoring.
Lab tests help diagnose problems before launch; field measurements show what actual visitors experience once sufficient data is available. Include peak-load testing where your architecture and sales patterns warrant it.
Speed should sit alongside usability in your acceptance criteria. Our guide to mobile product page design explores how product information, options and buying controls work on smaller screens. Include these journeys in design reviews and user acceptance testing.
Assign ownership for images, scripts, app selection and ongoing monitoring. A fast launch can become a slow store if every new marketing tool is added without review.
9. Protect SEO and prepare content for answer engines
SEO migration planning belongs in discovery. Record existing URLs, valuable landing pages, content, metadata and organic performance before making changes.
Preserve useful URLs where practical. When URLs change, map old pages to relevant replacements, implement permanent server-side redirects and update internal links, canonicals and sitemaps. Test crawl access and indexing settings before launch, then monitor errors and search performance afterwards. Google advises keeping migration redirects for at least a year.
Answer engine optimisation, or AEO, focuses on making information useful and understandable in answer-led discovery experiences. Prioritise accurate product specifications, clear buying advice, useful comparisons and consistent shipping and returns information. Structured data should reflect visible content.
For Google’s AI Overviews and AI Mode, existing SEO fundamentals remain applicable; Google says no special schema or additional technical optimisation is required. Other answer engines have their own systems, and inclusion cannot be guaranteed.
10. Plan a realistic eCommerce replatforming timeline
Complexity matters more than business size alone. A small retailer with unusual integrations may require more work than a larger business using standard functionality.
The following are illustrative planning ranges from discovery to launch, not industry benchmarks or delivery guarantees. They assume timely approvals and an available delivery team; procurement and partner selection may add time beforehand.
| Project | Indicative timeline | Typical scope |
|---|---|---|
| Small | 2–4 months | One storefront, established theme, limited integrations and straightforward data migration |
| Medium | 4–8 months | Custom design, several integrations, more complex catalogue, content and customer migration |
| Large | 8–18+ months | Multiple markets or storefronts, complex ERP/PIM connections, B2B workflows and substantial custom development |
Every project needs discovery, design and solution planning, development, migration rehearsals, testing, training and launch preparation. Some work can overlap; dependent tasks still need clear approval points.
Common schedule risks include poor source data, unavailable integration providers, delayed content, changing scope and slow internal approvals. Reserve time for stabilisation after launch and avoid major trading periods unless the business has explicitly accepted the exposure.
Confirm the launch date after discovery has established the critical dependencies and delivery scope.
11. Launch against evidence and measure the result
Before launch, validate payments, tax, shipping, promotions, stock, order flows, refunds, analytics and redirects. Reconcile migrated records and test representative customer journeys, including account access where migration changes the sign-in process.
Agree a cutover plan covering final data synchronisation, go/no-go authority, monitoring, escalation and recovery. A rollback plan must account for orders and data created after the new store becomes live.
After launch, track conversion, contribution, organic landing-page performance, errors and operational workload against your baseline. Review results at 30, 60 and 90 days while accounting for seasonality and marketing changes.
Your next step is a documented assessment of the current store, followed by a business case and discovery brief. These give your team the evidence needed to choose a platform, appoint an agency and commit to a delivery plan that supports the business.
Planning your next eCommerce platform?
OSE works with retailers, wholesalers and manufacturers across Shopify Plus, Adobe Commerce and connected business systems. If you are reviewing your current platform or agency, speak with OSE about assessing the existing environment and defining the requirements for your next stage of growth.