Consolidating regional stores is less a migration than a negotiation between markets. Each store has accumulated its own catalog structure, pricing logic, payment providers and compliance obligations, and the technical work is usually the easy part.

What to settle before writing code

• Catalog strategy — one master catalog with regional overrides, or genuinely separate catalogs per market.
• Pricing model — centrally managed price lists versus market-controlled pricing, and who owns the decision.
• Tax and payments — which providers survive the consolidation and which markets need local alternatives.
• Fulfilment — single warehouse, regional hubs, or a mix, and how inventory is exposed to each storefront.
• Governance — who approves changes once markets share a platform.

How to evaluate a partner

Ask for two things: a production reference in at least three countries, and a written cutover plan from a previous consolidation. Agencies that have done this work have both on hand. Agencies that have not will talk about the platform instead of the rollout.

Expect discovery to take longer than you would like. Six to eight weeks of mapping before development starts is normal on a five-market consolidation, and skipping it is the single most reliable way to blow the timeline later.

Hybrid commerce fails in predictable places. The catalog is usually fine; the trouble starts at pricing, visibility and checkout, where B2B and B2C expectations pull in opposite directions.

The four pressure points

1. Pricing — B2C sees one price, B2B sees contract pricing, volume breaks and negotiated terms. This has to be driven by customer group, not by duplicated products.
2. Catalog visibility — some SKUs are B2B-only, some are B2C-only, and a few are both at different prices.
3. Checkout — B2C wants one page and a card payment; B2B wants purchase orders, credit terms, approval workflows and quote requests.
4. Accounts — B2B buyers need company accounts with multiple users and roles; B2C accounts are individual.

What a good answer sounds like

A partner who has built this will describe the customer-group model first and the theme second. If the conversation starts with storefront design, the architecture has not been thought through.

Be wary of proposals that solve hybrid by running two separate stores. It works, but you now maintain two catalogs, two inventory syncs and two deployment pipelines, which is usually more expensive over three years than doing it properly once.

Most architecture audits arrive at the same conclusion as the auditor’s primary partnership. That is not always dishonesty; it is what happens when a team only knows one platform deeply.

What a real audit covers

• Codebase health — customisation depth, upgrade debt, test coverage.
• Infrastructure and performance under realistic peak load.
• Integration map — every system touching orders, inventory, customers and finance.
• Data model problems that will constrain future work.
• Team capability and where delivery actually slows down.

What you should receive

A prioritised roadmap: what to fix in the next quarter, what to plan for the next year, what to leave alone, and roughly what each costs. Anything less specific is hard to act on and harder to get budget approved for.

A useful audit sometimes concludes that your current platform is fine and the problem is process. A partner willing to say that is worth keeping.

Every ERP integration eventually reduces to one question: when the storefront and the ERP hold different values for the same field, which one wins?

Decide ownership first

Sync patterns that hold up

Real-time for inventory checks at cart and checkout, scheduled batches for catalog and pricing, and queued retries for orders so a brief ERP outage does not lose a sale. Anything that requires the ERP to be reachable for a customer to browse will eventually take your storefront down with it.

Questions worth asking

Ask how they handle a failed order push, how they reconcile inventory drift, and whether they have integrated your specific ERP version. Version matters more than vendor.

B2B buyers are not shopping. They are executing a purchase decision that was already made, usually under a contract, often on someone else’s budget.

Features that actually get used

• Company accounts with multiple users, roles and permissions.
• Contract pricing visible per account, including volume breaks.
• Reorder from order history and saved lists — often the most-used screen in the entire portal.
• Quote requests for non-standard configurations or quantities.
• Approval workflows where orders above a threshold route to a manager.
• Self-service invoices and payment status, which quietly removes a lot of support load.

What to prioritise

Reorder and account management first. Approval workflows second. Elaborate product discovery last — B2B buyers usually know exactly what they want and search by SKU.

Measure success by reduction in phone and email orders, not by time on site.

Three systems, each convinced it owns the product description, is a support ticket generator. The fix is boring and organisational rather than technical.

The ownership matrix

Produce a table listing every shared object — product, price, stock, customer, order, invoice — and for each one record the owning system, the direction of sync, the frequency, and the conflict rule. Get it signed off by the people who own each system, not just by IT.

One direction wherever possible

Bi-directional sync is occasionally unavoidable, but each bi-directional flow roughly doubles the debugging surface. Where you cannot avoid it, define the conflict rule explicitly: last-write-wins, or system-of-record-wins, and never “whichever ran most recently”.

Build for observability

Log every sync with a correlation ID, keep failed payloads, and give the operations team a screen where they can see what failed and retry it without a developer. Integrations that can only be debugged by reading server logs become the first thing nobody wants to touch.

Every agency says they are agile. The useful questions are about what happens when something goes wrong.

Questions that separate the field

• Who is my delivery lead, and how many other accounts do they carry?
• What is your change request process, and what does a mid-sprint scope change cost me?
• Can I see a burndown or velocity chart from a completed project of similar size?
• How do you handle a sprint that misses its commitment — what changes next sprint?
• What is your escalation path when I am unhappy, and how fast does it move?

Warning signs

A single fixed price with no change process, no named individuals in the proposal, and estimates that arrive without any stated assumptions. Each of these transfers risk to you quietly.

What good looks like

Two-week sprints with a demo at the end, a shared backlog you can see, a written definition of done, and a weekly status that reports variance honestly rather than reporting green until the week before launch.

A build quote without a three-year view is not a budget; it is a deposit.

Where the real money goes

1. Platform licence — often revenue-based, and it escalates as you grow. Model it at your projected volume, not today’s.
2. Hosting and infrastructure — including the environments you need for staging and QA.
3. Third-party services — search, tax, payments, reviews, personalisation. Each one is small; together they are not.
4. Integration maintenance — connectors break when either side upgrades. Budget for it annually.
5. Support and enhancement — the retainer that starts the month after launch.

Questions to ask before signing

What is not included in this number? What happens to the price if scope grows by twenty percent? What does year two cost if we change nothing? A partner who answers these plainly is easier to work with than one who quotes low and reconciles later.

Support contracts tend to be signed in the relief of having launched. That is exactly when they should be read carefully.

Clauses that matter

• Severity definitions — who decides that checkout being slow is a P1 rather than a P3.
• Response versus resolution — a one-hour response with no resolution commitment is close to meaningless.
• Coverage hours — whether the SLA holds during your peak trading period, including weekends.
• Bug versus change — the most common source of billing disputes.
• Rollover — whether unused hours expire monthly, quarterly or not at all.
• Security patching — included, or quoted separately each time.

A practical test

Ask what happens if checkout breaks at 9pm on your busiest Friday of the year. The answer, and whether it is written down anywhere, tells you more than the rest of the document.

Platform choice is usually decided by organisational capacity rather than feature lists. Any of the three can run a large store; not all of them fit every team.

Rough fit

• Shopify Plus — fastest to market, lowest operational burden, strong ecosystem. Constraints appear at complex B2B pricing and deeply custom checkout.
• Adobe Commerce — strong native B2B, multi-store and complex catalog handling. Requires real engineering capacity and a genuine upgrade discipline.
• commercetools — maximum flexibility through composable services. Requires an in-house team; without one, the flexibility becomes a liability.

The question people skip

Who maintains this in year three? A platform that fits your requirements but not your team will be re-platformed again within four years, which is the most expensive possible outcome.

Build a scorecard

Weight your genuine requirements, score each platform against them, and include total cost of ownership and hiring difficulty as scored lines. A scorecard makes the trade-off visible and makes the decision defensible internally.