How to Run an Ecommerce Migration Parallel Run Without Losing Control
A platform migration becomes much less stressful when you do not have to trust the new store immediately with every product, customer and order. That is the role of an ecommerce migration parallel run: operate the old and new ecommerce platform together for a defined period, compare their behaviour and move responsibility in controlled stages.
However, running both platforms at once is not automatically safer. Without clear boundaries, teams can create duplicate orders, conflicting stock values, inconsistent prices and uncertainty about which system should be updated. A parallel run reduces migration risk only when it has a clear purpose, controlled test cases and one agreed source of truth for each operational area.
This guide explains how UK ecommerce project leads can plan a parallel run during replatforming. It focuses on the operating model around the migration, rather than on a particular ecommerce platform or implementation method.
What an ecommerce migration parallel run is designed to prove
A parallel run should answer whether the new platform can support the business process safely before it becomes fully responsible for live trading. It is not simply a period where two websites happen to exist.
Depending on the migration, you may want to prove that the new platform can:
- Display accurate products, variants, prices and availability.
- Preserve customer account and pricing rules.
- Accept baskets, quotes or orders through the intended route.
- Send order information to fulfilment, finance or ERP systems.
- Handle refunds, amendments, cancellations and returns.
- Support analytics, campaign tracking and customer service processes.
Define the proof required before the parallel run begins. Otherwise, the project can continue for weeks while stakeholders disagree about whether the new platform is ready.
Choose the right parallel-run model
There is no single way to operate the old and new ecommerce platform together. Choose a model that matches your traffic, data quality, operational capacity and tolerance for disruption.
Read-only comparison
The new platform receives migrated or synchronised data but does not accept live orders. Teams compare catalogue, pricing, availability and customer-facing pages against the existing store. This is often a sensible early stage because it limits commercial risk.
Controlled user cohort
A defined group of staff, trade customers or invited users access the new platform. Their activity is monitored separately, while the wider customer base remains on the old platform. This can provide useful evidence from realistic journeys without exposing every visitor to an unfinished experience.
Route or region split
Traffic is divided by market, brand, product group, customer type or another agreed boundary. One platform handles the selected cohort and the other remains responsible for the rest. This model can work well when the operational boundary is clear, but it needs careful treatment of stock, pricing and customer accounts.
Dual processing with one operational authority
Both platforms may receive comparable inputs, but only one system is allowed to create the operational order or update a particular record. The second platform acts as a comparison environment rather than a second source of truth.
VERIFY: the safest model depends on the ecommerce platform, ERP, payment setup, fulfilment process and data synchronisation options. Do not send live orders to both platforms unless duplicate handling and operational ownership have been designed explicitly.
Define system ownership before testing the old and new ecommerce platform
The most important parallel-run decision is not which platform looks better. It is which system owns each business fact during the trial.
Create a simple ownership table covering areas such as:
- Product names, descriptions and specifications.
- Variants, SKUs and identifiers.
- Prices, promotions and account-specific terms.
- Stock, reservations and availability.
- Customer accounts and permissions.
- Orders, payments, refunds and returns.
- Delivery and fulfilment status.
- Analytics and campaign attribution.
The old platform may remain authoritative for live orders while the new platform owns a controlled test catalogue. Alternatively, the new platform may become authoritative for selected products from an agreed date. Write the boundary in plain English.
Avoid allowing both platforms to edit the same record without a conflict rule. “The latest update wins” is not a sufficient operating model where price, stock or order status affects customers.
Build a parallel testing matrix around real ecommerce journeys
Replatforming parallel testing should cover complete journeys, not just isolated pages. A product page can match perfectly while the basket, payment callback or fulfilment handoff behaves differently.
Create test cases for the journeys that matter most to your business:
- Catalogue journey: product, variant, image, specification and category data appear correctly.
- Pricing journey: the correct price, VAT treatment, promotion and customer-specific rule are shown from listing through checkout.
- Availability journey: stock changes, low-stock states, backorders and unavailable products behave as intended.
- Basket journey: selected variants, quantities, discounts and delivery choices survive between pages.
- Order journey: the order is created once with the correct customer, line items, totals and payment state.
- Aftercare journey: confirmation, amendments, cancellation, refund and return information reaches the right systems.
For each test, record the input, expected outcome, actual outcome, owner, evidence and decision. Include both a clean scenario and an exception scenario. For example, test a normal in-stock order and an order where availability changes between basket and submission.
Control traffic and user access deliberately
A parallel run becomes difficult to interpret when users can move between platforms without the project team knowing which route they followed. Make the access model deliberate.
Decide:
- Who can access the new platform.
- How users are directed to the new or old experience.
- Whether bookmarks, campaign links or redirects can bypass the intended cohort.
- How support teams identify which platform handled a customer.
- How test orders are labelled and separated from genuine trading activity.
For a controlled cohort, use a reliable identifier such as an account group, invitation list or feature flag where the platform supports it. Keep a record of the cohort and its start date. If the same customer can access both systems, document how pricing, order history and support records will be reconciled.
Prevent duplicate orders and conflicting updates
The highest-risk failure in a parallel run is usually not a visual mismatch. It is an operational record being created or updated twice.
Set explicit controls for:
- Order creation and payment confirmation.
- Webhook retries and delayed callbacks.
- Stock reservations and release timing.
- Customer account creation or matching.
- Refunds, cancellations and order amendments.
- Product and price synchronisation.
Use stable references that can connect the storefront basket, payment transaction, order record and downstream ERP or fulfilment record. If a test order is created, the team should be able to identify it throughout the workflow.
Do not rely on staff recognising test orders from a product name or customer email address. Use an agreed test reference, account, tag or metadata field where appropriate.
VERIFY: payment, webhook, stock reservation and order deduplication behaviour varies by platform and integration. Confirm the exact safeguards in a non-production environment before running live comparisons.
Run daily reconciliation during the parallel period
A parallel run needs a regular comparison routine. Without one, mismatches accumulate until nobody can tell whether they are isolated defects or evidence that the new platform is not ready.
A daily reconciliation should compare a selected sample of:
- Product and variant records.
- Prices and active promotions.
- Stock and availability states.
- Customer account access and pricing context.
- New orders and payment states.
- Dispatch, refund and cancellation updates.
Record the old value, new value, expected result, observed difference and next action. Classify each difference as intentional, blocking, acceptable with monitoring or requiring follow-up.
Use a small number of clear categories. A long list of unexplained mismatches makes the review harder, especially when marketing, ecommerce, development and operations are all involved.
Give every mismatch one owner and a decision
A reconciliation log is useful only when it leads to action. Every mismatch should have one owner, a priority and a decision deadline.
For example:
- Catalogue mismatch: ecommerce or product data owner.
- Price mismatch: trading owner and technical integration owner.
- Stock mismatch: operations or ERP owner.
- Order handoff mismatch: technical and fulfilment owners.
- Tracking mismatch: analytics or marketing owner.
Keep business ownership separate from technical ownership. The ecommerce lead may decide whether a price discrepancy blocks the trial, while the development team investigates the API or mapping issue.
Set exit criteria before the parallel run starts
A parallel run should end because agreed evidence has been collected, not because the project calendar has reached a certain date. Define exit criteria before the first comparison.
Useful criteria may include:
- Priority product and variant records match the approved source.
- Pricing and promotion rules pass representative tests.
- Critical customer journeys work on desktop and mobile.
- No unresolved duplicate-order or payment-state defects remain.
- Required ERP, fulfilment and finance handoffs reconcile correctly.
- Support and operations teams know which system owns each active process.
- Rollback, pause and incident routes have been tested.
- Open exceptions have an accepted owner and documented decision.
Do not hide unresolved high-impact issues inside an “acceptable differences” category. If an exception affects customer price, stock promise, payment or order creation, it should normally require explicit business sign-off.
Plan the move from parallel operation to one platform
The end of the parallel run is another controlled transition. Decide when the old platform becomes read-only, when new orders stop being accepted there and how remaining active records will be handled.
Document:
- The final cutover time and responsible decision-maker.
- Which platform accepts new orders after cutover.
- How existing baskets and customer sessions are handled.
- How open orders, refunds and returns remain accessible.
- When synchronisation jobs are stopped or changed.
- How the old platform is monitored after it becomes read-only.
- What conditions would trigger a pause or rollback.
A parallel run should reduce uncertainty about cutover, not postpone the same decisions. If the team cannot explain how responsibility will move, the trial has not yet achieved its purpose.
Ecommerce migration parallel run checklist
- Define what the parallel run must prove.
- Choose a controlled operating model and user cohort.
- Assign a source of truth for each important domain.
- Map complete customer and operational journeys.
- Prevent duplicate orders and conflicting updates.
- Use stable references for test records and handoffs.
- Run daily reconciliation with evidence and decisions.
- Give every mismatch one owner and deadline.
- Agree launch blockers, acceptable exceptions and exit criteria.
- Plan the move to one operational platform before the trial ends.
Where HOFK can help
An ecommerce migration parallel run can cross platform configuration, full stack development, ERP or PIM integrations, responsive websites, payment handoffs, analytics and operational workflows. HOFK can help review the migration design, improve the technical handoffs or support the ecommerce implementation and monitoring around the transition.
Relevant work may include mapping system ownership, designing comparison checks, improving data synchronisation, testing customer journeys or creating clearer exception handling. HOFK’s ecommerce support and full stack development services may be relevant where the old and new platforms need to work together temporarily without creating permanent duplication.
Conclusion
An ecommerce migration parallel run can reduce the risk of replatforming, but only when it is treated as a controlled operating period rather than two platforms running side by side without rules. Choose the right model, define ownership, test complete journeys, reconcile real outcomes and make every mismatch actionable.
The old and new ecommerce platform should not compete indefinitely. The purpose of parallel operation is to gather enough evidence to move responsibility safely, with clear exit criteria and a known route back if a serious problem appears. That is the practical foundation of replatforming parallel testing and meaningful migration risk reduction.
Frequently asked questions
What is an ecommerce migration parallel run?
It is a controlled period during replatforming when the old and new ecommerce platform operate together or are compared, so the business can validate data, customer journeys and operational handoffs before moving responsibility fully.
Should both ecommerce platforms accept live orders?
Usually, there should be one operational system responsible for creating live orders at any point in the trial. Running dual order creation without strong deduplication and reconciliation controls can create duplicate or conflicting records.
What should be tested during replatforming parallel testing?
Test complete journeys covering catalogue data, pricing, availability, basket behaviour, payment, order creation, fulfilment, refunds, customer accounts and analytics. Include exception cases as well as normal orders.
How long should a parallel run last?
There is no universal duration. It should last long enough to test representative traffic, product, customer and operational scenarios, while remaining short enough to avoid unnecessary duplicate processes. VERIFY the appropriate period against your trading cycle and migration scope.
When should the parallel run end?
End it when agreed exit criteria have been met, critical mismatches are resolved or explicitly accepted, ownership has moved to the new platform and the cutover or rollback route is understood.