Branch8

Salesforce Marketing Cloud to Braze Migration Guide for APAC Retail

Matt Li
July 12, 2026
16 mins read
Salesforce Marketing Cloud to Braze Migration Guide for APAC Retail - Hero Image

Key Takeaways

  • Map SFMC data extensions to Braze attributes, events, and catalogs — not 1:1 field copies
  • Resolve cross-market identity duplication before migrating any user data
  • Migrate suppression lists first and validate compliance across HK, SG, AU, TW regulations
  • Use phased migration (market-by-market) to reduce risk over big-bang cutover
  • Budget 10-16 weeks total for mid-size APAC retail migrations

Quick Answer: A Salesforce Marketing Cloud to Braze migration for APAC retail brands takes 10-16 weeks and involves six phases: data model mapping, journey-to-Canvas redesign, suppression list migration, integration reconfiguration, phased data migration, and parallel-run go-live. Resolve cross-market identity duplication and regional compliance requirements before moving any data.


Last year, a Hong Kong-based multi-brand retailer with 200+ stores across Greater China and Southeast Asia asked us to evaluate their martech stack. They were spending USD 380K annually on Salesforce Marketing Cloud (SFMC) — and their marketing team still needed three days to launch a simple triggered campaign. Journey Builder had become a labyrinth of nested decision splits that nobody fully understood, and their data extensions were riddled with duplicates across regional business units in Hong Kong, Singapore, and Taiwan.

Related reading: Customer Data Management CRM CDP Strategy Integration 2026: A Step-by-Step APAC Playbook

Six months later, after a structured Salesforce Marketing Cloud to Braze migration, their campaign launch time dropped to under four hours, and they consolidated five regional SFMC business units into a single Braze workspace with localized content blocks. This guide walks through exactly how we approached that migration — and the dozens of others we've executed for APAC retail and e-commerce brands.

Related reading: Global E-Commerce Expansion Trends & Operations for 2026: An APAC-First Playbook

Related reading: Health Wellness E-Commerce Platform Selection APAC 2026: A Step-by-Step Guide

Related reading: E-Commerce Subscription Model Platforms Features 2026: APAC Implementation Guide

Related reading: Best E-Commerce Development Agencies APAC 2026: A Strategic Comparison

Prerequisites Before You Start

Migrating platforms is not a technology project alone. It is a business operations project that happens to involve technology. Before writing a single line of migration code, you need three things locked down.

Stakeholder Alignment and Decision Rights

Get explicit sign-off from marketing leadership, IT/engineering, data privacy (DPO if you have one), and finance. In APAC, this often means navigating matrix organizations where regional marketing heads in Singapore or Australia have different priorities than HQ in Hong Kong or Tokyo. Document who owns the final go/no-go decision for each migration phase.

Full Audit of Your SFMC Footprint

You cannot migrate what you have not inventoried. Export a complete list of:

  • Data extensions — every DE, including shared data extensions across business units
  • Journeys — active, paused, and draft Journey Builder journeys with entry source details
  • Automations — Automation Studio workflows, including SQL queries, file drops, and script activities
  • Content — email templates, content blocks, CloudPages, AMPscript personalization logic
  • Subscriber lists and suppression lists — including region-specific opt-out lists required under Hong Kong's PDPO, Singapore's PDPA, and Australia's Spam Act 2003
  • API integrations — connected systems like commerce platforms (Shopify Plus, Magento/Adobe Commerce, VTEX), CDPs (Segment, mParticle), and loyalty systems

We typically run this audit using SFMC's SOAP API to programmatically extract metadata. Here is a simplified Python snippet we use to pull all data extension names and field schemas:

1import FuelSDK
2
3client = FuelSDK.ET_Client()
4de = FuelSDK.ET_DataExtension()
5de.auth_stub = client
6de.props = ['Name', 'CustomerKey', 'CategoryID']
7response = de.get()
8
9for item in response.results:
10 print(f"DE: {item.Name} | Key: {item.CustomerKey}")
11 # Fetch fields for each DE
12 de_col = FuelSDK.ET_DataExtension_Column()
13 de_col.auth_stub = client
14 de_col.search_filter = {
15 'Property': 'DataExtension.CustomerKey',
16 'SimpleOperator': 'equals',
17 'Value': item.CustomerKey
18 }
19 col_response = de_col.get()
20 for col in col_response.results:
21 print(f" Field: {col.Name} | Type: {col.FieldType}")

Braze Workspace Architecture Decision

Before migration, decide your Braze workspace topology. For APAC multi-market brands, the two common patterns are:

  • Single workspace with custom attributes for market segmentation — works well when product catalogs and campaigns overlap significantly (e.g., a fashion brand with shared collections across HK, SG, TW)
  • Multiple workspaces per market — necessary when data residency requirements demand it, or when business units operate with fundamentally different data models

According to Braze's own documentation, a single workspace with segmentation filters is recommended for most use cases to avoid content and user profile fragmentation. We default to single-workspace unless regulatory requirements force otherwise.

Step 1: Map Your Data Model from SFMC to Braze

This is where most migrations either succeed or fail. SFMC's relational data extension model is fundamentally different from Braze's user-profile-centric data model, and treating this as a simple field-mapping exercise will cost you weeks of rework.

Translating Data Extensions to Braze User Profiles and Custom Events

SFMC stores data in flat or loosely related data extensions — essentially SQL tables. Braze organizes everything around a user profile with three data types:

  • Standard attributes — email, phone, first name, last name, country, language
  • Custom attributes — stored directly on the user profile (e.g., loyalty_tier, preferred_store_id, last_purchase_date)
  • Custom events — time-stamped behavioral data with properties (e.g., "purchase" event with properties like product_id, amount, currency)

The critical decision: what currently lives in SFMC data extensions should become a custom attribute versus a custom event versus data stored in your Connected Content / Catalogs layer?

Our rule of thumb for APAC retail clients:

  • Static or slowly changing data (loyalty tier, preferred language, home market) → Custom attributes
  • Transactional or behavioral data (purchases, page views, cart events) → Custom events
  • Product catalog data (SKU details, pricing, inventory) → Braze Catalogs or Connected Content pulling from your commerce API

Handling Multi-Market Subscriber Keys

APAC brands often have the same customer registered across multiple markets with different subscriber keys in SFMC. A shopper might have one SubscriberKey in the Hong Kong business unit and another in the Singapore business unit.

In Braze, you need a single external_id per user. This means you must resolve identity before migration — not during, not after. We use a deterministic matching approach: match on email + phone number combination, then deduplicate with preference rules (most recent purchase market wins as primary market, earliest registration date wins as profile of record).

According to a 2023 Segment report on identity resolution, 64% of APAC retailers have duplicate customer profiles across regional systems. Solving this during migration is an opportunity, not just a burden.

Building Your Field Mapping Document

Create a spreadsheet (we use Airtable for collaborative mapping) with these columns:

  • SFMC Data Extension name
  • SFMC Field name and type
  • Braze destination (attribute, event, catalog, or "do not migrate")
  • Braze field name (following Braze's snake_case convention)
  • Transformation logic (e.g., "convert SFMC datetime to ISO 8601", "map loyalty codes A/B/C to gold/silver/bronze")
  • Data volume estimate

For a typical APAC retailer with 500K-2M profiles, we budget 5-8 working days for this mapping exercise across the data and marketing teams.

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

Step 2: Rebuild Journeys as Braze Canvases

Journey Builder to Canvas translation is the most intellectually demanding part of this Salesforce Marketing Cloud to Braze migration guide. You are not copying journeys — you are rethinking them.

Audit and Prioritize Active Journeys

Most SFMC instances we encounter have 30-80 journeys, but only 10-20 are actively driving meaningful engagement. Start by categorizing every journey:

  • Tier 1 — Revenue-critical: Abandon cart, post-purchase, welcome series, win-back. Migrate these first.
  • Tier 2 — Operationally important: Transactional confirmations, loyalty point notifications, appointment reminders.
  • Tier 3 — Nice to have: Seasonal campaigns, one-off promotions that can wait or be rebuilt fresh.

For a mid-size APAC e-commerce brand, Tier 1 typically covers 6-10 journeys that drive 70-80% of email/push revenue.

Translating Journey Builder Logic to Canvas Flow

SFMC Journey Builder uses entry sources, decision splits, wait steps, and activities. Braze Canvas uses entry criteria (via segments or API triggers), decision splits (Audience Path and Action Path steps), delay steps, and message steps.

Key differences to watch:

  • Entry sources: SFMC journeys often use data extension injection or Salesforce CRM entry events. In Braze, entries are typically segment-based (audience enters when they match filter criteria) or API-triggered. If you relied on Automation Studio to inject contacts into journeys via DE updates, you will need to redesign the trigger mechanism — often by sending a custom event from your backend or CDP when the qualifying action occurs.
  • AMPscript to Liquid: SFMC uses AMPscript for personalization. Braze uses Liquid templating. This is not a find-and-replace operation. AMPscript's Lookup() and LookupRows() functions for pulling data from related DEs need to be replaced with Braze's Connected Content calls or Catalog lookups.

Here is a common conversion example:

1// SFMC AMPscript
2%%[
3SET @firstName = AttributeValue("FirstName")
4SET @loyaltyTier = Lookup("LoyaltyDE", "Tier", "SubscriberKey", _subscriberkey)
5IF @loyaltyTier == "Gold" THEN
6 SET @offer = "20% off"
7ELSE
8 SET @offer = "10% off"
9ENDIF
10]%%
11Hi %%=v(@firstName)=%%, enjoy your exclusive %%=v(@offer)=%%!
1// Braze Liquid equivalent
2{% assign firstName = {{${first_name}}} %}
3{% if {{custom_attribute.${loyalty_tier}}} == "gold" %}
4 {% assign offer = "20% off" %}
5{% else %}
6 {% assign offer = "10% off" %}
7{% endif %}
8Hi {{ firstName }}, enjoy your exclusive {{ offer }}!

Handling Wait Steps and Timing Differences

SFMC Journey Builder wait steps are calendar-based (wait 3 days) or event-based (wait until email opened). Braze Canvas delay steps work similarly but with one important nuance: Braze's Intelligent Timing feature can automatically optimize send times per user based on engagement history. According to Braze's 2024 Global Customer Engagement Review, brands using Intelligent Timing see 15-25% higher open rates compared to fixed-time sends.

For APAC specifically, this matters because your audience spans UTC+8 (Hong Kong, Singapore, Taiwan) to UTC+10/+11 (Australia), and manually managing send windows across time zones in SFMC was likely painful. In Braze, configure Intelligent Timing or use local time zone delivery — it handles the math.

Step 3: Migrate Suppression Lists and Compliance Data

This step is non-negotiable and uniquely complex for APAC operations. Get it wrong and you face regulatory penalties under multiple jurisdictions simultaneously.

Mapping Regulatory Requirements by Market

APAC has no unified data protection framework. Your migration must respect:

  • Hong Kong PDPO: Opt-out must be honored; no requirement for explicit opt-in for existing customers (implied consent model for existing business relationships)
  • Singapore PDPA: DNC registry checks required; consent records must be transferable
  • Australia Spam Act 2003: Explicit consent required; unsubscribe must work within 5 business days
  • Taiwan PIPA: Amended in 2023 to require purpose-specific consent
  • GDPR (if you serve EU customers from APAC): Right to erasure must be preserved across platform migration

Export your SFMC All Subscribers list with status flags (Active, Unsubscribed, Bounced, Held). Export your publication-level unsubscribe lists. Export any custom suppression data extensions.

Braze manages consent through subscription groups (for email and SMS) and push enablement flags. Create subscription groups in Braze that mirror your SFMC publication lists before importing any user data.

Use Braze's /users/track endpoint or CSV import to set subscription states:

1{
2 "attributes": [
3 {
4 "external_id": "user_12345",
5 "email": "[email protected]",
6 "email_subscribe": "unsubscribed",
7 "subscription_groups": [
8 {
9 "subscription_group_id": "sg_marketing_hk",
10 "subscription_state": "unsubscribed"
11 },
12 {
13 "subscription_group_id": "sg_transactional_hk",
14 "subscription_state": "subscribed"
15 }
16 ]
17 }
18 ]
19}

Validating Suppression Accuracy

After import, run a reconciliation check. Pull a count of unsubscribed users per subscription group from Braze and compare against your SFMC suppression list counts. Any discrepancy above 0.1% needs investigation. We built an internal validation script that compares SHA-256 hashed email lists between source and destination — this avoids exposing PII during QA while confirming exact matches.

In our experience, the most common failure mode here is timezone-related: SFMC stores unsubscribe timestamps in Central Standard Time (CST) by default, while Braze uses UTC. If you have compliance processes that depend on exact unsubscribe timing (Australia's 5-business-day rule), convert all timestamps to UTC during migration.

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

Step 4: Set Up Integration Architecture

SFMC likely sat at the center of a web of integrations — commerce platform, CRM, loyalty system, data warehouse. Each of these connections needs to be redirected to Braze.

Commerce Platform Integration

For Shopify Plus merchants (common among our APAC D2C clients), replace SFMC's Marketing Cloud Connector with Braze's native Shopify integration or a CDP-mediated connection through Segment or mParticle.

If you are on Magento/Adobe Commerce or a custom commerce platform, you will need to instrument Braze's SDK and send purchase events via the REST API. Here is the basic event structure:

1{
2 "events": [
3 {
4 "external_id": "user_12345",
5 "name": "purchase",
6 "time": "2024-11-15T14:30:00+08:00",
7 "properties": {
8 "product_id": "SKU-HK-001",
9 "product_name": "Classic Gold Necklace",
10 "currency": "HKD",
11 "price": 2800.00,
12 "store_id": "TST-001"
13 }
14 }
15 ]
16}

CDP and Data Warehouse Connections

If you use Segment, reconfigure your Segment destination from SFMC to Braze. Segment's Braze destination supports identify calls (mapped to user attributes) and track calls (mapped to custom events). According to Segment's integration documentation, the Braze destination processes events in near real-time with median latency under 2 seconds — a significant improvement over SFMC's batch-oriented data extension updates.

For data warehouse integrations (BigQuery, Snowflake, Redshift), evaluate Braze's Cloud Data Ingestion (CDI) feature, which launched broadly in 2023. CDI allows you to sync segments and attributes directly from your warehouse to Braze without building custom ETL pipelines — this is particularly valuable for APAC enterprises that have invested in centralized data platforms.

Webhook and API Endpoint Migration

Audit every SFMC webhook activity and script activity that calls external systems. Each one needs a Braze equivalent — typically a Braze webhook campaign or a Connected Content call. Document endpoint URLs, authentication methods (API keys, OAuth tokens), and payload schemas. Recreate these in Braze's webhook templates.

Step 5: Execute the Data Migration

With your data model mapped, journeys redesigned, compliance data structured, and integrations configured, you are ready to move actual user data.

Phased Migration vs. Big Bang

We strongly advocate phased migration for APAC retail brands. Our standard approach:

  • Phase 1: Migrate a single market (typically your smallest market by volume — often Taiwan or Malaysia for our clients) with Tier 1 journeys only. Run in parallel with SFMC for 2 weeks.
  • Phase 2: Migrate your largest market (Hong Kong or Australia typically). Parallel run for 1 week.
  • Phase 3: Remaining markets. Cut over SFMC.

This approach adds 3-4 weeks to the total timeline but dramatically reduces risk. According to Gartner's 2023 Marketing Technology Survey, organizations that use phased migration approaches report 40% fewer post-migration incidents compared to big-bang transitions.

Data Extraction and Transformation

Extract user data from SFMC using the REST API (for subscriber data) and SOAP API (for data extension rows). For large data volumes — anything over 500K profiles — use SFMC's file-based extract activity to dump data to SFMC's Enhanced FTP, then pull files for transformation.

Transformation pipeline (we typically use Python with pandas, or dbt if the client has a warehouse-first architecture):

  1. Deduplicate profiles using your identity resolution rules from Step 1
  2. Convert field names and types to match your Braze mapping document
  3. Convert all timestamps to ISO 8601 UTC format
  4. Validate email format and phone number format (E.164 for Braze)
  5. Split output into Braze-compatible CSV files (max 500MB per file for Braze's CSV import) or JSON payloads for the /users/track API

Loading Data into Braze

For initial bulk load, Braze's CSV import via the dashboard works for datasets under 1M rows. For larger datasets, use the /users/track API in batches of 75 users per request (Braze's rate limit). At 75 users per request with a sustained rate of 250K requests per hour (standard Braze API rate limit), migrating 2M profiles takes approximately 10-11 hours.

1# Example: batch API import using curl
2curl -X POST "https://rest.iad-01.braze.com/users/track" \
3 -H "Content-Type: application/json" \
4 -H "Authorization: Bearer YOUR_API_KEY" \
5 -d '{
6 "attributes": [
7 {"external_id": "u001", "first_name": "Wing", "email": "[email protected]", "loyalty_tier": "gold", "home_market": "HK"},
8 {"external_id": "u002", "first_name": "Mei", "email": "[email protected]", "loyalty_tier": "silver", "home_market": "SG"}
9 ]
10 }'

Monitor Braze's Developer Console for import errors. Common failure reasons: malformed email addresses, external_id conflicts, and exceeding the 256 custom attribute limit per user.

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

Step 6: QA, Parallel Run, and Go-Live Sequencing

Go-live is not a single moment — it is a controlled sequence that typically spans 1-2 weeks.

Quality Assurance Checklist

Run these checks before enabling any live sends from Braze:

  • Profile count reconciliation: Total migrated profiles in Braze vs. source count (accept no more than 0.5% variance)
  • Segment validation: Recreate your top 10 SFMC segments as Braze segments and compare user counts
  • Email rendering: Test every migrated template across clients (Litmus or Email on Acid — we use Litmus v4.x)
  • Personalization accuracy: Send test emails to seed lists verifying that Liquid personalization renders correctly for edge cases (empty fields, special characters in CJK names)
  • Suppression validation: Attempt to send to known unsubscribed addresses — confirm Braze blocks the send
  • Event tracking: Trigger test purchase and browse events from your staging environment; verify they appear on user profiles within 60 seconds

Parallel Run Protocol

During parallel run, both SFMC and Braze are active but sending to non-overlapping audiences. Split your audience 80/20 (80% stays on SFMC, 20% goes to Braze) for the first week, then flip to 20/80 in the second week.

Critical rule: configure frequency capping across both platforms during the parallel period. The easiest approach is to add a custom attribute in both platforms (migration_cohort = "braze" or "sfmc") and use it as an exclusion filter. A customer should never receive duplicate messages from both platforms.

Go-Live and SFMC Decommissioning

Once parallel run metrics confirm parity (open rates within 1-2 percentage points, click rates stable, unsubscribe rates not spiking), cut over remaining traffic to Braze. Keep SFMC active in read-only mode for 90 days — you will need it for historical reporting and any compliance-related lookbacks.

Cancel or downgrade your SFMC contract only after the 90-day archival period. Salesforce contracts in APAC typically have annual renewal cycles — time your migration completion to align with your renewal date. According to Salesforce's standard enterprise agreement terms, notice of non-renewal is required 60 days before the contract anniversary.

Common Mistakes and Troubleshooting

After completing multiple SFMC-to-Braze migrations for APAC retail brands, these are the problems that recur most often.

Mistake 1: Migrating Every Data Extension

Not all SFMC data should move to Braze. Braze is an engagement platform, not a data warehouse. We have seen teams attempt to migrate 50+ data extensions with years of transactional history into Braze custom attributes, hitting the 256-attribute limit and slowing down segment computation. Migrate only the data Braze needs for personalization and segmentation. Keep historical analytics data in your warehouse.

Mistake 2: Ignoring AMPscript Dynamic Content Complexity

SFMC power users often have deeply nested AMPscript with multiple Lookup() calls, TreatAsContent() blocks, and dynamic subject lines. A quick Liquid translation might miss edge cases. We budget 2-3 days specifically for AMPscript-to-Liquid conversion QA on complex templates, testing every conditional branch.

Mistake 3: Forgetting SMS Sender ID Registration

In Singapore, you must register your SMS Sender ID with the SSIR (Singapore SMS Sender ID Registry) before sending. If your SFMC instance was sending SMS via a registered Sender ID and you switch to Braze's SMS infrastructure (Twilio-based), you need to re-register or port your Sender ID. This process takes 3-5 business weeks — start it at the beginning of your migration, not the end.

Mistake 4: Underestimating CJK Character Handling

Chinese, Japanese, and Korean characters in user names, content, and subject lines behave differently across platforms. Braze handles UTF-8 natively, but ensure your extraction scripts preserve encoding correctly. We encountered an issue where a bulk CSV export from SFMC defaulted to Windows-1252 encoding, corrupting Traditional Chinese characters during import. Always specify UTF-8 encoding explicitly:

1df.to_csv('braze_import.csv', encoding='utf-8-sig', index=False)

The utf-8-sig variant adds a BOM (Byte Order Mark) that helps Braze's CSV parser handle CJK characters correctly.

Mistake 5: Not Planning for IP Warming

If you are moving to Braze's email infrastructure (rather than keeping your existing ESP), you need to warm your new sending IPs. Start with your most engaged segment (opened email in last 30 days) and gradually increase volume over 2-4 weeks. Braze's IP Warming Schedule documentation recommends starting at 25-50 emails per day and doubling daily. For an APAC retailer with 1M+ subscribers, full IP warm-up typically takes 3-4 weeks.

Skipping this will land you in spam folders. We saw one client's open rates drop to 3% during their first week because they sent 500K emails on day one with cold IPs. It took 6 weeks to recover their sender reputation.

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

Branch8's Migration Approach in Practice

When we migrated the multi-brand retailer mentioned at the start of this article, the total project ran 14 weeks from kickoff to SFMC decommissioning. The team was two Branch8 engineers, one data analyst, and three client-side marketers working part-time.

Breakdown:

  • Weeks 1-2: Audit and data model mapping
  • Weeks 3-4: Identity resolution and deduplication (this was the hardest part — they had 340K duplicate profiles across five SFMC business units)
  • Weeks 5-7: Journey redesign and Liquid template conversion
  • Weeks 8-9: Integration reconfiguration (Shopify Plus, Segment, custom loyalty API)
  • Weeks 10-11: Data migration and QA
  • Weeks 12-13: Parallel run
  • Week 14: Full cutover and SFMC read-only transition

The client's annual martech cost dropped from USD 380K (SFMC Enterprise) to USD 210K (Braze Growth tier) — a 45% reduction. More importantly, their marketing team went from requiring engineering support for every campaign change to self-serving 90% of their needs directly in Braze's Canvas UI.

Further Reading

If you are an APAC retail or e-commerce brand evaluating a Salesforce Marketing Cloud to Braze migration, reach out to Branch8. We scope migrations in 5 business days and provide fixed-fee project pricing — no open-ended consulting engagements.

FAQ

For mid-size APAC retail brands with 500K-2M profiles and 10-20 active journeys, expect 10-16 weeks end-to-end. The timeline depends primarily on data complexity, number of integrations, and how many markets you operate in. Phased migration adds 3-4 weeks but significantly reduces risk.

About the Author

Matt Li

Co-Founder & CEO, Branch8 & Second Talent

Matt Li is Co-Founder and CEO of Branch8, a Y Combinator-backed (S15) Adobe Solution Partner and e-commerce consultancy headquartered in Hong Kong, and Co-Founder of Second Talent, a global tech hiring platform ranked #1 in Global Hiring on G2. With 12 years of experience in e-commerce strategy, platform implementation, and digital operations, he has led delivery of Adobe Commerce Cloud projects for enterprise clients including Chow Sang Sang, HomePlus (HKBN), Maxim's, Hong Kong International Airport, Hotai/Toyota, and Evisu. Prior to founding Branch8, Matt served as Vice President of Mid-Market Enterprises at HSBC. He serves as Vice Chairman of the Hong Kong E-Commerce Business Association (HKEBA). A self-taught software engineer, Matt graduated from the University of Toronto with a Bachelor of Commerce in Finance and Economics.