Migrating Legacy ERP to Composable Commerce Stack in Asia: A Practitioner's Guide

Quick Answer: Migrating legacy ERP to a composable commerce stack in Asia requires decomposing ERP modules into bounded contexts, building an integration mesh that handles APAC protocol diversity, extracting tax logic for multi-jurisdiction compliance first, then rolling out market by market starting with your lowest-complexity market.

According to IDC's 2024 Asia/Pacific Digital Commerce Survey, 67% of enterprises across APAC are still running monolithic ERP systems that were deployed before 2015 — and 41% of those organizations cite their legacy ERP as the single biggest blocker to composable commerce adoption (IDC FutureScape, 2024). Migrating legacy ERP to a composable commerce stack in Asia introduces complications that most vendor-agnostic frameworks conveniently ignore: multi-entity tax structures spanning six or more jurisdictions, real-time currency conversion across unstable exchange corridors, and integration with regional third-party logistics providers whose APIs range from RESTful to flat-file FTP drops.

Related reading: React Native App Performance Benchmarks Across APAC Markets: 2026 Field Data

Related reading: Snowflake Data Sharing for APAC Retail Group Analytics: A Step-by-Step Guide

Related reading: AI Agent Orchestration for E-Commerce Ops Teams: A Step-by-Step Build Guide

Related reading: Customer Lifetime Value Modelling for APAC Retail: A Step-by-Step Guide

Related reading: Instagram YouTube Addiction Design Legal Liability: What APAC Businesses Must Learn

This guide is the playbook I wish I'd had five years ago. It reflects direct architecture decisions from engagements with enterprises operating across Hong Kong, Singapore, Taiwan, Australia, Vietnam, and Indonesia — organizations where a single order might touch three tax regimes, two currencies, and a warehouse management system that still speaks SOAP.

Prerequisites Before You Begin

Before touching a single integration point, three foundational elements must be in place. Skipping these is the fastest way to turn a migration into a multi-year money pit.

Audit Your Current ERP's Integration Surface

Map every inbound and outbound data flow from your existing ERP. In a recent Branch8 engagement with a mid-market consumer electronics brand operating across five APAC markets, we discovered 23 undocumented integrations during this phase — including a legacy EDI connection to a Taiwanese distributor that processed 12% of total order volume. Use a tool like MuleSoft Anypoint's API Catalog or Postman's API landscape mapping to create a dependency graph.

Capture these specifics for each integration:

• Protocol (REST, SOAP, SFTP, EDI X12/EDIFACT)
• Data format (JSON, XML, CSV, IDOC for SAP)
• Frequency (real-time, batch hourly, batch nightly)
• Volume (transactions per hour at peak)
• Owning team and escalation contact

Establish Your Multi-Entity Tax and Currency Baseline

APAC is not one market. Singapore's GST (9% as of January 2024), Taiwan's VAT (5%), Indonesia's PPN (11%), Vietnam's VAT (8-10%), and Australia's GST (10%) each have distinct invoicing requirements, digital tax obligations, and cross-border withholding rules. According to Deloitte's 2024 Asia Pacific Tax Complexity Report, APAC has the highest tax compliance complexity score globally at 68 out of 100.

Document your current ERP's tax calculation logic — particularly where it's hardcoded versus configuration-driven. Many SAP ECC 6.0 and Oracle E-Business Suite 12.2 implementations have tax logic buried in custom ABAP or PL/SQL that no current team member wrote.

Define Your Composable Target Architecture

A composable commerce stack is not a product — it's an architecture pattern. For APAC enterprises, I typically recommend this capability map as a starting reference:

• Commerce Engine: commercetools, Adobe Commerce (Magento), or Shopify Plus (for B2C-heavy)
• OMS/ERP Layer: SAP S/4HANA, Oracle Cloud ERP, or NetSuite (with APAC localizations)
• Integration Middleware: MuleSoft Anypoint, Apache Camel on Kubernetes, or AWS EventBridge
• Tax Engine: Avalara AvaTax (with APAC modules) or Vertex O Series
• PIM: Akeneo PIM or Salsify (for marketplace-heavy models)
• Storefront: Adobe Experience Manager Sites 6.5+ (AEM as a Cloud Service preferred) or a headless frontend via Next.js

Step 1: Decompose the Monolith into Bounded Contexts

The first real work is not writing code — it's drawing boundaries.

Apply Domain-Driven Design to Your ERP Modules

Take your ERP's module map (Finance, Procurement, Inventory, Order Management, CRM) and overlay it with domain-driven design bounded contexts. Each bounded context becomes a candidate microservice or managed service in your composable stack.

For a typical APAC multi-entity setup, the bounded contexts usually look like this:

• Order Context: Order capture, validation, splitting (by warehouse/market)
• Inventory Context: Stock levels, ATP (available-to-promise), warehouse allocation
• Pricing Context: Multi-currency pricing, promotions, regional discount rules
• Tax Context: Tax calculation, tax reporting, e-invoicing (mandatory in Taiwan and Indonesia)
• Fulfillment Context: 3PL dispatch, shipping label generation, customs documentation
• Finance Context: Revenue recognition, intercompany transfers, GL posting

Identify the Strangler Fig Candidates

Martin Fowler's Strangler Fig pattern remains the most reliable approach for ERP decomposition. The key question for each bounded context: can this context operate independently with an anti-corruption layer translating to and from the legacy ERP?

In practice, for APAC deployments, the safest first candidate is usually the Pricing Context. Here's why: pricing logic in legacy ERPs is frequently the most tangled (condition records in SAP, modifier lists in Oracle), yet it has a clean input/output contract — given a cart, return prices.

1# Example: Pricing service contract (OpenAPI 3.0 snippet)
2paths:
3  /v1/pricing/calculate:
4    post:
5      summary: Calculate cart prices with regional rules
6      requestBody:
7        content:
8          application/json:
9            schema:
10              type: object
11              properties:
12                market:
13                  type: string
14                  enum: [HK, SG, TW, AU, VN, ID, MY, PH]
15                currency:
16                  type: string
17                  enum: [HKD, SGD, TWD, AUD, VND, IDR, MYR, PHP]
18                lineItems:
19                  type: array
20                  items:
21                    $ref: '#/components/schemas/LineItem'
22                customerSegment:
23                  type: string
24      responses:
25        '200':
26          description: Calculated prices with tax breakdown by jurisdiction

Map Data Ownership During the Transition

During migration, you will have dual-write scenarios. This is unavoidable but must be controlled. Define explicitly: which system is the master of record for each data entity, and for how long?

A common anti-pattern I see in APAC migrations: teams allow the legacy ERP to remain master of product data while the new PIM is "also" receiving updates. This creates divergence within weeks. Pick one master per entity. Use CDC (Change Data Capture) tools like Debezium to stream changes unidirectionally.

Step 2: Architect the Integration Mesh for APAC Realities

Generic composable commerce guides assume clean REST APIs everywhere. APAC enterprise reality is different.

Build for Protocol Diversity

In a Branch8 project migrating a Hong Kong-based fashion retailer from SAP ECC 6.0 to a composable stack (commercetools + AEM as a Cloud Service + MuleSoft), we encountered five distinct integration protocols across their APAC supply chain:

• RESTful JSON APIs (commercetools, Stripe)
• SOAP/XML (SAP PI/PO middleware)
• SFTP flat files (a major Indonesian 3PL, JNE Express)
• EDI EDIFACT (a Taiwanese logistics partner)
• Webhook callbacks (Shopee and Lazada marketplace connectors)

MuleSoft Anypoint handled protocol translation effectively, but the critical architecture decision was implementing a canonical data model at the integration layer. Every message entering the mesh gets transformed into a canonical format before routing:

1{
2  "canonicalOrder": {
3    "orderId": "ORD-2024-HK-00421",
4    "market": "HK",
5    "currency": "HKD",
6    "taxJurisdiction": "HK-IRD",
7    "lineItems": [
8      {
9        "sku": "PROD-A1-BLK-M",
10        "quantity": 2,
11        "unitPrice": 450.00,
12        "taxRate": 0.0,
13        "warehouseCode": "WH-HK-TST"
14      }
15    ],
16    "fulfillmentMethod": "3PL_DISPATCH",
17    "3plProvider": "SF_EXPRESS",
18    "timestamps": {
19      "created": "2024-11-15T08:30:00+08:00",
20      "timezone": "Asia/Hong_Kong"
21    }
22  }
23}

Handle Multi-Currency at the Integration Layer, Not the Commerce Engine

A mistake I see repeatedly: letting the commerce engine handle currency conversion. Commerce engines like commercetools support multi-currency natively, but the conversion rates and rounding rules need to be governed centrally — especially when you're reconciling against an ERP that posts to the general ledger in a base currency.

Implement a currency service that sources rates from a treasury feed (or a provider like Currencylayer or Open Exchange Rates) and applies market-specific rounding rules. Indonesian Rupiah, for example, requires rounding to the nearest 100 IDR for consumer-facing prices — a rule that Gartner's 2023 Digital Commerce report notes is frequently missed in APAC implementations.

Design for APAC Latency and Data Residency

According to Cloudflare's 2024 Network Performance Report, average latency between Singapore and Sydney is 96ms, while Singapore to Jakarta averages 22ms. These numbers matter when your integration mesh is making synchronous calls across services.

For APAC composable stacks, deploy your integration middleware in at least two regions: one in Northeast Asia (Hong Kong or Tokyo) and one in Southeast Asia (Singapore). Use event-driven architecture (Apache Kafka or AWS EventBridge) for non-time-critical flows, and keep synchronous REST calls within the same region.

Data residency is also non-negotiable. Vietnam's Decree 13/2023 requires certain personal data categories to be stored within Vietnam. Indonesia's Government Regulation 71/2019 has similar provisions. Your integration architecture must support data partitioning by jurisdiction.

Step 3: Execute the Tax and Compliance Layer First

Tax is the boring part that kills projects when done wrong.

Deploy a Dedicated Tax Calculation Service

Rip tax logic out of your legacy ERP and into a dedicated service before migrating anything else. This is counterintuitive — most teams want to start with the storefront — but in APAC, getting tax wrong means invoices that don't comply with local regulations, which means you can't legally sell.

Avalara AvaTax supports APAC tax jurisdictions, but its coverage varies by market. As of 2024, Avalara covers Singapore, Australia, India, Japan, and South Korea comprehensively, but Taiwan and Vietnam require supplementary configuration. Vertex O Series offers stronger coverage in certain APAC markets — evaluate both against your specific market footprint.

1// Example: Tax calculation call with APAC jurisdiction handling
2const calculateTax = async (order) => {
3  const taxRequest = {
4    companyCode: order.entityCode, // e.g., 'BRANCH8-SG', 'BRANCH8-HK'
5    customerCode: order.customerId,
6    date: order.orderDate,
7    currencyCode: order.currency,
8    addresses: {
9      shipFrom: getWarehouseAddress(order.warehouseCode),
10      shipTo: order.shippingAddress,
11    },
12    lines: order.lineItems.map((item, idx) => ({
13      number: idx + 1,
14      quantity: item.quantity,
15      amount: item.unitPrice * item.quantity,
16      taxCode: mapToAvalaraTaxCode(item.productCategory, order.market),
17      // Critical for APAC: HSN/HS code for cross-border
18      hsCode: item.hsCode,
19    })),
20  };
21
22  // Route to appropriate tax engine based on jurisdiction
23  if (['TW', 'VN'].includes(order.market)) {
24    return await localTaxEngine.calculate(taxRequest);
25  }
26  return await avalaraClient.createTransaction({ model: taxRequest });
27};

Implement E-Invoicing for Mandated Markets

Taiwan's Uniform Invoice system (managed by the Ministry of Finance) requires electronic invoice reporting in a specific XML format via the Turnkey Service. Indonesia's e-Faktur system, managed by the Directorate General of Taxes, has its own format requirements. These are not optional features — they're legal requirements that must be in your composable stack from day one.

Build e-invoicing as a separate bounded context that subscribes to the order completion event and generates jurisdiction-specific invoice documents.

Step 4: Migrate Fulfillment and 3PL Integrations Market by Market

This is where migrating legacy ERP to a composable commerce stack in Asia gets genuinely difficult, because fulfillment partners vary wildly by market.

Map Your 3PL Integration Landscape

APAC 3PL providers range from global operators (DHL eCommerce, FedEx) with well-documented REST APIs to regional players with integration capabilities that require patience. In our Branch8 engagements across Southeast Asia, we've catalogued the typical integration maturity:

• Tier 1 (REST API, webhooks): DHL eCommerce, Ninja Van, Lalamove
• Tier 2 (REST API, limited webhooks): Kerry Logistics, SF Express, J&T Express
• Tier 3 (SFTP/flat file): JNE Express (Indonesia), Viettel Post (Vietnam), certain Taiwan convenience store pickup networks (7-Eleven ibon, FamilyMart)

For Tier 3 providers, you need an adapter pattern in your integration layer that polls SFTP directories, parses flat files, and converts them into domain events.

Roll Out Market by Market, Not Big Bang

McKinsey's 2023 analysis of APAC digital transformations found that phased market-by-market rollouts had a 73% success rate versus 31% for big-bang approaches. Pick your highest-volume, lowest-complexity market first.

For most APAC enterprises, Singapore or Hong Kong is the ideal pilot market: relatively simple tax rules (Hong Kong has no VAT/GST on most goods; Singapore has a single GST rate), mature 3PL partners with good APIs, and English-speaking teams for easier UAT cycles.

After stabilizing the pilot market for 4-6 weeks, expand to the next market. The canonical data model you built in Step 2 makes this possible — each new market adds localized configuration (tax rules, currency, 3PL adapters) rather than requiring new architecture.

Handle Order Splitting for Cross-Border Fulfillment

A single order from a customer in Australia might be fulfilled from a warehouse in Hong Kong (for electronics) and a warehouse in Vietnam (for apparel). Your composable stack needs an Order Splitting Service that:

• Determines optimal fulfillment location based on inventory ATP, shipping cost, and delivery SLA
• Splits the order into sub-orders per fulfillment location
• Handles customs documentation for cross-border shipments (commercial invoices, HS codes, declared values)
• Reconciles payment capture against split shipments

This is functionality that monolithic ERPs like SAP typically handle within a single transaction (ATP check + delivery split in SD module). In a composable stack, it becomes an orchestration service that coordinates across inventory, pricing, and fulfillment contexts.

Step 5: Migrate the Storefront and Experience Layer

Note that the storefront is Step 5, not Step 1. Too many teams start here because it's visible and exciting. But a beautiful headless storefront connected to a broken integration layer is a liability.

Choose Your Storefront Architecture

For APAC enterprises, I recommend evaluating three patterns:

• AEM as a Cloud Service + Edge Delivery Services: Best for content-heavy brands that need localized experiences per market. Adobe's Edge Delivery Services delivers sub-second LCP (Largest Contentful Paint) scores. We've measured 0.8s LCP for a Cathay Pacific ancillary commerce page served from Adobe's Hong Kong edge node.
• Next.js + Vercel: Best for engineering-led organizations comfortable with React. Vercel's edge network has PoPs in Hong Kong, Singapore, Tokyo, and Sydney.
• Shopify Hydrogen: Best for pure-play D2C brands with simpler requirements. Limited in B2B and complex multi-entity scenarios.

Implement Localization Beyond Translation

Localization in APAC means more than translating strings. It includes:

• Payment methods: Alipay HK and Octopus for Hong Kong, GrabPay and PayNow for Singapore, LINE Pay for Taiwan, MoMo for Vietnam, GoPay/OVO/DANA for Indonesia
• Address formats: Taiwan uses a district-based system; Vietnam addresses are structured differently from Western formats; Japanese addresses read in reverse order
• Date and number formatting: Taiwan uses the Minguo calendar in some contexts; different markets use different decimal separators

Build a localization configuration service that the storefront queries at runtime:

1// Localization config for each APAC market
2interface MarketConfig {
3  market: string;
4  currency: { code: string; symbol: string; decimalPlaces: number; rounding?: number };
5  paymentMethods: string[];
6  addressFormat: AddressFieldConfig[];
7  taxDisplay: 'inclusive' | 'exclusive';
8  dateFormat: string;
9  defaultLanguages: string[];
10}
11
12const MARKET_CONFIGS: Record<string, MarketConfig> = {
13  HK: {
14    market: 'HK',
15    currency: { code: 'HKD', symbol: 'HK$', decimalPlaces: 2 },
16    paymentMethods: ['credit_card', 'alipay_hk', 'wechat_pay', 'octopus', 'fps'],
17    addressFormat: [/* district, street, building, floor, flat */],
18    taxDisplay: 'inclusive',
19    dateFormat: 'DD/MM/YYYY',
20    defaultLanguages: ['en-HK', 'zh-Hant-HK'],
21  },
22  ID: {
23    market: 'ID',
24    currency: { code: 'IDR', symbol: 'Rp', decimalPlaces: 0, rounding: 100 },
25    paymentMethods: ['credit_card', 'gopay', 'ovo', 'dana', 'bank_transfer_va'],
26    addressFormat: [/* province, city, district, postal, street */],
27    taxDisplay: 'exclusive',
28    dateFormat: 'DD/MM/YYYY',
29    defaultLanguages: ['id-ID', 'en-ID'],
30  },
31};

Step 6: Decommission Legacy ERP Modules Incrementally

The legacy ERP doesn't die in one day. It fades module by module.

Implement Circuit Breakers for the Transition Period

During the transition, your composable services will coexist with legacy ERP modules. Implement circuit breaker patterns (using libraries like resilience4j for Java or Polly for .NET) so that if a new composable service fails, the system can fall back to the legacy ERP path.

1// Circuit breaker for pricing service fallback to legacy SAP
2@CircuitBreaker(name = "pricingService", fallbackMethod = "legacyPricingFallback")
3public PricingResponse calculatePrice(PricingRequest request) {
4    return composablePricingClient.calculate(request);
5}
6
7public PricingResponse legacyPricingFallback(PricingRequest request, Throwable t) {
8    log.warn("Composable pricing unavailable, falling back to SAP. Error: {}", t.getMessage());
9    // Transform request to SAP BAPI format
10    SapPricingRequest sapRequest = SapRequestMapper.toPricingBapi(request);
11    return sapConnector.callBapi("BAPI_PRICING_CALCULATE", sapRequest);
12}

Validate Financial Reconciliation Before Cutover

Before decommissioning any ERP module that touches financials, run parallel processing for at least one full accounting period (monthly close). Compare GL postings, intercompany eliminations, and tax filings between the legacy path and the composable path.

PwC's 2024 Global ERP Survey found that 58% of ERP migration failures in APAC were traced to financial reconciliation gaps discovered post-cutover. Don't join that statistic.

Plan Your Data Archival Strategy

Most APAC jurisdictions require financial records to be retained for 5-7 years (Australia requires 5 years per ATO guidelines; Hong Kong's IRD requires 7 years). Before decommissioning legacy ERP modules, ensure historical data is archived in a queryable format. SAP's Data Archiving capabilities (transaction SARA) or a data lake approach using AWS S3 + Athena both work — the key is that auditors can access historical records without spinning up the legacy system.

Common Mistakes and How to Avoid Them

Mistake 1: Treating Composable Commerce as a Technology Decision

Composable commerce is an operating model change. Your procurement team needs to manage 8-12 vendor contracts instead of one. Your platform team becomes an integration team. Your release process shifts from quarterly big-bang deployments to continuous delivery per service. According to Forrester's 2024 Composable Commerce report, organizations that restructured their teams before migration were 2.4x more likely to meet their ROI targets.

Mistake 2: Ignoring APAC Marketplace Integration Requirements

In Southeast Asia, marketplace channels (Shopee, Lazada, Tokopedia) often account for 40-60% of digital revenue (Bain & Company's e-Conomy SEA 2023 report). Your composable stack must treat marketplace order ingestion as a first-class integration, not an afterthought. This means marketplace orders flow through the same canonical order model, same inventory checks, and same fulfillment orchestration as your direct-to-consumer orders.

Mistake 3: Underestimating Character Encoding Complexity

CJK (Chinese, Japanese, Korean) character encoding issues will surface in every layer: product names in Traditional Chinese (Hong Kong/Taiwan), Simplified Chinese (some Singapore customers), Vietnamese diacritics (e.g., the difference between "phở" and "pho" matters), and Bahasa Indonesia/Malay with occasional Arabic script for certain product categories. Ensure UTF-8 encoding is enforced end-to-end, from database collation (use utf8mb4 in MySQL, not utf8) to API response headers to search index analyzers.

Mistake 4: Building Custom When Managed Services Exist

Don't build a custom payment orchestration layer when providers like Adyen (strong APAC coverage with local acquiring in 8+ APAC markets), Stripe (expanding APAC presence), or local aggregators like 2C2P (Southeast Asia specialist) exist. Every custom component is a maintenance burden. Reserve your engineering effort for the integrations that are genuinely unique to your business.

Mistake 5: Neglecting Observability from Day One

In a composable stack with 10+ services, debugging a failed order requires distributed tracing. Implement OpenTelemetry from the first service you deploy. Use Datadog, Grafana Cloud, or AWS X-Ray — but choose one and instrument everything. A Branch8 post-mortem from an early engagement taught us this the hard way: a 3-hour outage during a 11.11 sale was caused by a timeout cascade between the pricing service and a 3PL adapter, and without distributed tracing it took 90 minutes just to identify the root cause.

What to Do Monday Morning

If migrating legacy ERP to a composable commerce stack in Asia is on your roadmap, here are three actions you can take this week:

• Run an integration audit: Assign two senior engineers to map every inbound and outbound integration from your current ERP. Use the protocol/format/frequency/volume framework from the prerequisites section. Give them two weeks and a Miro board.
• Quantify your tax complexity: List every APAC market you sell into, each market's tax rate(s), e-invoicing requirements, and data residency rules. This document becomes your requirements spec for the tax calculation service in Step 3.
• Identify your pilot market: Pick the market with the highest order volume and lowest regulatory complexity. Build your composable stack business case around this market, then use it as the proof point for board-level funding of the full rollout.

Branch8 has guided multi-market APAC enterprises through this exact process — from integration audits through to production cutover. If you want a structured assessment of your legacy ERP landscape and a composable migration roadmap tailored to your APAC market footprint, reach out to our architecture team.

Sources

• IDC FutureScape: Worldwide Digital Commerce 2024 Predictions — Asia/Pacific: https://www.idc.com/getdoc.jsp?containerId=AP50293223
• Deloitte Asia Pacific Tax Complexity Report 2024: https://www.deloitte.com/global/en/services/tax/perspectives/asia-pacific-tax-complexity.html
• Cloudflare Network Performance Report 2024: https://blog.cloudflare.com/network-performance-update-2024
• McKinsey & Company — Digital Transformation in Asia-Pacific (2023): https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights
• PwC Global ERP Survey 2024: https://www.pwc.com/gx/en/services/consulting/erp-survey.html
• Forrester — The State of Composable Commerce, 2024: https://www.forrester.com/report/the-state-of-composable-commerce-2024
• Bain & Company — e-Conomy SEA 2023: https://www.bain.com/insights/e-conomy-sea-2023/
• Gartner — Digital Commerce Technology Trends 2023: https://www.gartner.com/en/documents/4021078