B2B Ecommerce Platform Replatforming: An APAC Buyer's Guide

Quick Answer: B2B ecommerce platform replatforming is migrating your catalogue, company accounts, contract pricing and ERP integrations to a new platform. Evaluate on B2B account model depth, ERP integration surface, multi-entity capability and five-year TCO — then prove the three hardest requirements in a paid proof of concept before signing.

Success in a B2B ecommerce platform replatforming project looks unglamorous. Eighteen months after go-live, your dealers place 70% of their reorders without calling anyone. Your ERP is the single source of truth for stock and pricing, and nobody maintains a spreadsheet of contract prices. Your sales team spends its time on new accounts instead of typing purchase orders. Finance can close the month without reconciling three systems. And the platform bill has not grown faster than order volume.

Related reading: Ecommerce Platform Comparison Cost 2026: Shopify Plus vs Adobe vs SHOPLINE

Related reading: Claude Spotify Instacart API Integration: An APAC Commerce Blueprint

Work backwards from that and most of the decisions get easier. The platform question — Shopify Plus versus Adobe Commerce versus SAP Commerce Cloud versus a composable stack — is genuinely important, but it is the fourth or fifth decision, not the first. For manufacturers and distributors across Hong Kong, Singapore, Taiwan, Malaysia, Vietnam and Australia, the harder questions are about who owns the integration layer, how many entities and currencies the catalogue has to serve, and whether your organisation can staff the system after the implementation partner leaves.

Related reading: Claude AI Production Integration Risks: An Engineering Playbook

This guide is written for that decision. It covers the evaluation criteria that actually predict outcomes, real cost ranges, a weighted scoring framework you can run in a spreadsheet, and the operating model question that most replatforming content skips entirely.

Why APAC B2B replatforming is accelerating now

The pressure is partly generational and partly structural. Gartner has forecast that by 2025, 80% of B2B sales interactions between suppliers and buyers would occur in digital channels — a shift driven by buyers who now research, configure and reorder without wanting a conversation. Forrester's B2B research has consistently found that the majority of B2B buyers are now millennial or younger, a cohort that treats a phone-and-fax reorder process as a defect.

The structural driver in Asia-Pacific is supply chain reconfiguration. As manufacturing distributes across Vietnam, Malaysia, Indonesia and India alongside China, a distributor that once served one market from one entity now runs three or four legal entities, each with its own tax treatment, currency and price book. Legacy platforms built for a single-country catalogue break on exactly this. According to UNCTAD's estimates of global ecommerce, B2B accounts for the large majority of total ecommerce value worldwide — the volume is not new, but the expectation that it runs self-service is.

Related reading: Supply Chain Security for LLM Inference: An APAC Checklist

The third driver is end-of-life pressure. Adobe ended support for Magento Open Source 2.4.6 and earlier versions on published schedules, and Adobe Commerce 2.4.7 became the current support baseline — organisations sitting on unsupported versions face a forced upgrade that is often the same cost as a migration to a new platform. That is the moment most replatforming business cases actually get approved.

Evaluation criteria that predict outcomes

After running these projects for listed retail groups, catering operators and dealer-network manufacturers across Greater China and Southeast Asia, the criteria below are the ones where a wrong answer shows up as pain in year two.

1. Native B2B account model depth

The question is not "does it support B2B" — every vendor says yes. The question is what the data model natively expresses:

• Company → location → buyer hierarchy. Can one company have five ship-to locations with different payment terms and tax IDs?
• Role-based permissions. Can a junior buyer draft an order that a controller must approve above a threshold?
• Price lists per company, not per customer group. Customer groups are a 2010-era abstraction. Contract pricing per company with volume-break tiers is the modern requirement.
• Payment terms and credit limits. Net 30/60/90, credit holds, and partial invoicing.

Shopify's B2B feature set on Plus exposes companies, company locations, catalogs and price lists as first-class Admin API objects, which means the account model is queryable rather than bolted on. Adobe Commerce B2B ships shared catalogs, requisition lists, quote negotiation and company account hierarchies. Anything you have to build yourself becomes permanent maintenance.

2. ERP integration surface

This is where projects fail. For a distributor, the platform is a presentation layer over the ERP — SAP, Oracle NetSuite, Microsoft Dynamics 365 Business Central, Infor, or in APAC very often a locally-hosted system like Kingdee, Yonyou, or a customised AS/400 estate.

Related reading: Salesforce Agentforce AI Adoption 2026: The APAC Ops Playbook

Evaluate: does the platform have documented, rate-limit-tolerant APIs for the four flows that matter — customer/company sync, catalogue and pricing sync, inventory availability, and order writeback? Ask for the rate limits in writing. A GraphQL bulk operation endpoint matters more than a UI feature list when you are syncing 400,000 SKUs nightly.

A minimal Shopify company-creation call illustrates the shape of a modern B2B write path:

1mutation createDealer($input: CompanyCreateInput!) {
2  companyCreate(input: $input) {
3    company { id name externalId }
4    userErrors { field message }
5  }
6}

1{
2  "input": {
3    "company": {
4      "name": "Kowloon Industrial Supplies Ltd",
5      "externalId": "ERP-CUST-40218",
6      "note": "Tier 2 dealer, HKD, Net 30"
7    },
8    "companyLocation": {
9      "name": "Tsuen Wan Warehouse",
10      "billingSameAsShipping": false,
11      "buyerExperienceConfiguration": {
12        "paymentTermsTemplateId": "gid://shopify/PaymentTermsTemplate/3",
13        "checkoutToDraft": true
14      }
15    }
16  }
17}

The externalId field is the detail worth noticing. If the platform gives you a native slot for the ERP's customer key, idempotent sync is straightforward. If it does not, you are storing foreign keys in metafields and writing reconciliation jobs.

3. Multi-entity, multi-currency, multi-language reality

A Hong Kong holding company selling into Taiwan, Thailand and Australia needs per-market pricing in HKD, TWD, THB and AUD, Traditional Chinese and Thai storefronts, per-entity invoicing, and market-specific tax logic (GST in Singapore and Australia, VAT in Vietnam, no sales tax in Hong Kong). Ask vendors to demonstrate one company account buying from two entities. Many cannot without separate store instances, which doubles your operational overhead.

4. Total cost of ownership over five years, not licence cost

Licence is typically 20–35% of five-year TCO for a mid-market B2B implementation. Hosting, integration middleware, agency retainers, internal headcount and version upgrades make up the rest. Adobe Commerce on-premise looks cheaper on paper than Adobe Commerce Cloud until you price the DevOps engineer.

5. Upgrade and support burden

SaaS platforms upgrade themselves; you inherit breaking changes on their schedule. Self-hosted platforms upgrade on your schedule; you inherit the entire cost. Neither is free. The honest question is whether you have — or can hire in your market — the engineers to run the self-hosted option. In Hong Kong and Singapore, senior Magento/PHP talent is scarce and expensive relative to the same skill in Vietnam or the Philippines, which is exactly why distributed delivery models have grown.

6. Ability to sunset the legacy system completely

The worst outcome is a replatform that leaves the old system running for one function nobody migrated — usually quotes, returns, or a niche pricing rule. Scope that function on day one or accept a permanent second system.

Composable versus monolithic: choose based on team, not fashion

The MACH Alliance (Microservices, API-first, Cloud-native, Headless) has done an effective job of making composable architecture the default aspiration. It is a genuinely better fit for some B2B businesses and an expensive mistake for others.

When monolithic or SaaS-suite wins

Choose an integrated platform — Shopify Plus with B2B, Adobe Commerce B2B, BigCommerce B2B Edition, or SHOPLINE for Greater China-centric operations — when:

• Your catalogue is under roughly 250,000 SKUs with conventional variant structures.
• Your pricing logic can be expressed as company-level price lists plus volume breaks.
• You have fewer than three developers you can dedicate to commerce, permanently.
• Time-to-value matters more than long-run flexibility. A 4–6 month go-live is realistic; composable rarely is.

When composable wins

Choose commercetools, Elastic Path, or a headless build over Adobe Commerce's GraphQL layer when:

• You have genuinely unusual pricing — configure-price-quote, tender pricing, formula-based pricing on commodity indices, or per-contract rebate accrual.
• Commerce is one channel among several (EDI, punchout via cXML/OCI, marketplace, field-sales app) and no single storefront is authoritative.
• You already run a platform engineering function with CI/CD, observability and on-call. If you cannot name who gets paged at 3am, you are not ready.
• Your catalogue exceeds a million SKUs or requires domain-specific search that the platform's native search cannot express.

The middle path most APAC distributors should consider

Keep the transactional core on a managed SaaS platform, and compose selectively around it: a dedicated search service (Algolia, Elasticsearch), a PIM (Akeneo, Pimcore) for catalogue governance, and a real integration layer (Celigo, Workato, Boomi, or a custom Node/Go service) between the platform and the ERP. This gives you 80% of composable's flexibility at a fraction of the operational load — which is the practical reading of the 80/20 rule as it applies to ecommerce architecture.

What replatforming actually costs

Published pricing in this category is patchy, so treat these as market ranges observed across the region rather than quotes. Currency is USD.

Platform licence and subscription

• Shopify Plus: publicly quoted from around US$2,300 per month on a one-year term, with variable pricing at higher volumes. B2B features are included on Plus at no additional licence cost. Shopify Payments and third-party gateway fees apply on top.
• Adobe Commerce (Cloud): licence is tiered on gross merchandise value and order volume. Publicly reported ranges run from roughly US$40,000 per year at the low end to US$150,000+ annually for larger GMV bands, with B2B modules included in the Commerce edition. Adobe does not publish list pricing; expect a bespoke quote.
• BigCommerce Enterprise / B2B Edition: typically US$1,000–$5,000+ per month depending on GMV band and modules.
• commercetools: consumption-based, commonly starting in the low six figures annually for enterprise B2B usage.
• SAP Commerce Cloud: enterprise-quoted, generally the highest licence tier in this set; usually chosen when SAP S/4HANA is already the ERP.
• SHOPLINE: substantially lower entry cost with strong Greater China payment, logistics and social-commerce coverage; evaluate carefully against complex multi-entity B2B requirements.

Implementation

For a B2B manufacturer or distributor with ERP integration, this is where the money goes:

• Straightforward SaaS replatform — single entity, one ERP, under 20,000 SKUs, standard B2B pricing: US$60,000–$150,000.
• Mid-market multi-entity replatform — 2–4 entities, multi-currency, PIM introduction, custom pricing rules, punchout or EDI for key accounts: US$150,000–$450,000.
• Composable enterprise build — headless frontend, dedicated integration services, custom CPQ: US$500,000–$2,000,000+, typically 9–18 months.

A useful sanity check: data migration and integration usually consume 40–60% of implementation effort on B2B projects. If a proposal allocates 15% to integration, the estimate is wrong or the scope is.

Ongoing run cost

Budget 15–25% of the implementation figure annually for maintenance, enhancement and platform upgrades. Add internal cost: at minimum a product owner at 0.5 FTE, plus a merchandiser or catalogue manager. Self-hosted adds infrastructure and a DevOps allocation.

The cost nobody budgets

Change management with your dealers. If 300 dealers have called the same three sales reps for a decade, adoption does not happen because you launched a portal. Onboarding sessions, bilingual documentation, incentives for first digital order, and a transition period where both channels run — that is real cost and real calendar time. It is also the difference between a working platform and an expensive one.

A weighted scoring framework for platform selection

Run this as a spreadsheet with your actual weights. The point of scoring is not the number — it is forcing the argument about weights to happen before the demo, not after.

Step 1: Set weights (must total 100)

Starting weights for a typical APAC distributor with an established dealer network:

• B2B account and pricing model fit — 20. Company hierarchies, contract pricing, approvals, credit terms.
• ERP and integration fit — 20. Documented APIs, bulk operations, rate limits, existing connectors for your ERP.
• Multi-entity / multi-market capability — 12. Currencies, languages, tax, per-entity invoicing.
• Five-year TCO — 15. Licence plus implementation plus run cost plus internal headcount.
• Time to first revenue — 10. Months to a usable dealer portal, not to full feature parity.
• Talent availability in your markets — 8. Can you hire or contract for this stack in HK, SG, TW, MY, VN?
• Extensibility and exit cost — 8. How hard is it to leave in five years?
• Regional payment, logistics and compliance coverage — 7. Local gateways, 3PL connectors, e-invoicing mandates.

A manufacturer with unusual configure-to-order requirements should raise "extensibility" and lower "time to first revenue". A group under margin pressure should raise TCO.

Step 2: Score each platform 1–5 against evidence, not claims

Score 5 only where the vendor demonstrated the capability in your data during a proof of concept. Score 3 where it exists but requires configuration or an app. Score 1 where it requires custom development. Multiply by weight, sum.

Step 3: Apply the veto rules

Some criteria are pass/fail regardless of total score:

• If it cannot express your contract pricing without custom code, it fails — pricing bugs destroy dealer trust faster than anything else.
• If there is no viable path to your ERP within the project timeline, it fails.
• If you cannot staff it in your region within 90 days of go-live, it fails.

Step 4: Run a costed proof of concept before signing

Take your three hardest requirements — usually a real contract price list, a real ERP order writeback, and one awkward tax or entity case — and build them on the two shortlisted platforms. Two to four weeks of paid work per platform is cheap insurance against a seven-figure mistake. Vendors resisting a paid POC on real data are telling you something.

Replatforming strategy: sequencing that reduces risk

The strategy question is not which platform but in what order. Three patterns work, and one does not.

Pattern 1: Pilot channel first

Migrate one dealer segment or one country onto the new platform while the legacy system serves everyone else. Prove the integration, the pricing and the adoption playbook on 20 accounts before you touch 500. Slower overall, dramatically lower blast radius. This is the default recommendation for dealer networks.

Pattern 2: Strangler pattern around the legacy monolith

Stand up the new platform for catalogue, search and self-service reorder while the legacy system continues to handle quotes or returns, then migrate those functions in later releases. Requires disciplined ownership of which system is authoritative for what — write it down, per entity, per data object.

Pattern 3: Big-bang cutover with a frozen scope

Viable when the legacy system is genuinely simple and the new scope is feature parity plus one or two additions. The failure mode is scope creep: every stakeholder adds their wish to the migration because "we're rebuilding anyway". Freeze scope, ship, then enhance.

The anti-pattern: feature parity plus transformation, all at once

Rebuilding the existing system exactly while also redesigning pricing, introducing a PIM, changing the ERP and launching three new markets. This is the most common shape of a failed programme. Pick one transformation per release.

One engagement shape we see repeatedly: a manufacturer selling through a multi-country dealer network arrives with a decade-old on-premise platform, contract pricing maintained in Excel by three regional sales managers, and an ERP that nobody wants to touch. The correct first move is almost never the platform. It is getting price lists out of spreadsheets and into a governed system with an owner — because until pricing has a single authoritative home, every platform choice inherits the same problem.

Data migration: the part that runs long

Budget more here than feels reasonable.

Migrate: customer/company records with ERP keys, active price lists, product master data, order history for reorder functionality (often 24 months is enough — ask your dealers), invoices if required for compliance, and URL structure for SEO continuity.

Do not migrate: inactive accounts, superseded SKUs, abandoned carts, or historical promotions. A replatform is the only cheap opportunity you will get to delete twenty years of accumulated data debt.

Validate with reconciliation, not sampling. For each migrated object type, run a count and a checksum on key financial fields between source and target, and keep the script:

1# Nightly parity check during dual-run: order counts and value by entity
2psql -h legacy-db -c "SELECT entity, COUNT(*), SUM(total) FROM orders \
3  WHERE created_at >= CURRENT_DATE - 1 GROUP BY entity" > /tmp/legacy.txt
4
5curl -s -X POST "https://$SHOP/admin/api/2025-01/graphql.json" \
6  -H "X-Shopify-Access-Token: $TOKEN" \
7  -H 'Content-Type: application/json' \
8  -d '{"query":"{ orders(first:250, query:\"created_at:>=-1d\") { edges { node { id currentTotalPriceSet { shopMoney { amount currencyCode } } } } } }"}' \
9  | jq -r '.data.orders.edges[].node.currentTotalPriceSet.shopMoney | [.currencyCode,.amount] | @tsv' \
10  | awk '{c[$1]++; s[$1]+=$2} END {for (k in c) print k, c[k], s[k]}' > /tmp/new.txt
11
12diff /tmp/legacy.txt /tmp/new.txt || echo "PARITY MISMATCH — investigate before cutover"

Run it for two weeks before cutover and two weeks after. Finance will ask, and you want the answer ready.

The managed service question: who runs this after go-live

This is the part of B2B ecommerce platform replatforming that determines whether the investment compounds or decays. Most organisations plan the build carefully and the operating model not at all.

Three models, with honest trade-offs:

In-house team

Best control and institutional knowledge. Requires hiring 3–6 people — product owner, two to three engineers, QA, plus catalogue operations — and retaining them. In Hong Kong and Singapore, senior commerce engineering talent is competitive with fintech salaries, and single-person dependencies are a real operational risk when someone resigns.

Project-based agency

Good for the build. Poor for the eighteen months after, when you need someone who understands why a pricing rule was written that way. Every re-engagement rebuilds context, and you pay for that context twice.

Managed contracting / embedded team

A persistent named team — typically distributed across Hong Kong, Vietnam, Malaysia and the Philippines — that operates as an extension of your organisation rather than a vendor delivering a statement of work. The advantage is retained context and a cost base that reflects APAC engineering markets rather than a single expensive city. The trade-off is honest: you are dependent on a partner's retention and continuity, so contract for named individuals and knowledge-transfer obligations, not just SLAs.

For global companies — US, UK, EU — running APAC operations, this model is the practical route to timezone coverage. An Asia-based team hands off to European hours naturally, which matters when your dealers in Taiwan and Australia place orders while your head office sleeps. For APAC groups expanding cross-border, the same structure gives you Traditional Chinese, Bahasa and Vietnamese language capability without building four local teams.

Whichever you pick, define these before signing: who owns production access, who owns the integration code repository, how platform version upgrades are budgeted, and what happens to the code and documentation if the relationship ends.

How to evaluate: your next four weeks

A sequence you can actually execute:

Week 1 — Quantify the cost of doing nothing. Count manual order-entry hours per month, pricing errors per quarter, and orders lost to competitors with self-service. Without this number your business case is a preference, not an investment case.

Week 2 — Write the requirements that are genuinely yours. Not a 400-line feature matrix. Ten to fifteen requirements that describe your pricing, your entities, your ERP and your dealer behaviour. Set the scoring weights and get them signed off by finance and sales before any demo.

Week 3 — Shortlist two platforms and one architecture decision. Composable or integrated, decided on your team's capacity to operate it, not on the architecture's merits in the abstract. Score both platforms against your weights using evidence.

Week 4 — Commission paid proofs of concept on your three hardest requirements. Real price list, real ERP writeback, real awkward tax case. Then decide.

Where this is heading is worth planning for. Two shifts are already visible: agentic buying, where procurement systems query supplier catalogues via API rather than a human browsing a storefront — which makes your product data quality and API surface more commercially important than your storefront design — and e-invoicing mandates spreading across the region, with Malaysia's phased LHDN rollout and Singapore's InvoiceNow adoption pushing structured invoice data into the commerce layer. A platform decision made in 2026 should assume that machines, not just buyers, will read your catalogue, and that tax authorities will read your invoices in real time.

The organisations that get B2B ecommerce platform replatforming right are not the ones that pick the cleverest architecture. They are the ones that fix their pricing data, choose a platform their team can actually operate, and staff it properly for the three years after launch. If you want a second opinion on a shortlist or a scoring framework you have already built, Branch8's commerce team works on exactly these decisions across Hong Kong, Singapore, Taiwan and Australia — get in touch and bring your requirements list.

Sources

• Gartner — Future of Sales research
• Forrester — B2B commerce and buyer research
• Shopify — B2B on Shopify developer documentation
• Adobe — Adobe Commerce B2B documentation
• MACH Alliance — composable architecture principles
• UNCTAD — Digital economy and ecommerce statistics
• Inland Revenue Board of Malaysia — e-Invoice guidelines
• IMDA Singapore — InvoiceNow