Enterprise MA Platform Migration (120M+ Customers)
from Salesforce Marketing Cloud (SFMC) to Adobe Experience Platform (AEP) / Journey Optimizer (AJO).

1. Overview

• Company: Dip Corporation
• Role: Section Manager / CRM Director
• MA Migration: from Salesforce Marketing Cloud to Adobe Experience Platform / Journey Optimizer
• Scale: Large-scale recruitment platform with 120M+ users
• Objective: Redesign CRM orchestration architecture beyond legacy automation constraints
  
  This project came with a lot of pressure, as the company had made a significant investment and, like most projects, there was a tight timeline.
  Many engineers were initially strongly against replacing the existing system due to its complexity, with concerns that the project would take too long or that something might go wrong.
  

🟥 BEFORE：Legacy MA（Salesforce Marketing Cloud）

Concept

Rule-based / Step-driven Automation

Trigger
  ↓
Filter / Split
  ↓
Action (Send)
  ↓
Wait
  ↓
Next Step

Characteristics

• Automation = Flixed flow
• ビジネスロジックと実装が密結合
• 分岐が増えるほどブラックボックス化
• 「止められない」「捨てられない」オートメーション

Organizational Reality

• なぜ動いているか分からない処理が残る
• 新規施策は既存フローへの“継ぎ足し”

🟩 AFTER：Event-driven MA（Adobe AEP / Journey Optimizer）

Concept

Intent-based / Event-driven Orchestration

Event / State Change
        ↓
Intent Evaluation
        ↓
Decision Logic
        ↓
Best Action

Characteristics

• Automation = 意思決定ルール
• ビジネス意図と実装を分離
• イベント・状態・スコアで再利用可能
• 「止められる」「捨てられる」設計

Organizational Reality

• なぜ配信されたか説明できる
• 施策追加＝ルール追加（フロー改修不要）

2. Core Challenge — Automation Logic, Not Tooling

The most critical challenge was not data migration, but how to reinterpret and re-implement existing automation logic under a fundamentally different execution model.

Key friction:

• Legacy MA relied on tightly coupled, step-based automations
• New platform required event-driven, profile-centric orchestration
• Direct 1:1 migration would reproduce architectural debt

👉 The real question:

Which automations should be migrated as-is, redesigned, or intentionally abandoned?

3. Strategic Decision Under Conflict

The most debated decision was how to migrate automation logic without freezing innovation.

I led the decision to:

• Decouple business intent from implementation logic

• Classify existing automations into:

  • Reusable intent (retain)
  • Structural dependency (redesign)
  • Volume-driven legacy logic (sunset)

• Avoid “mechanical migration” in favor of conceptual re-architecture

This decision initially created friction due to:

• Increased short-term workload
• Uncertainty around undocumented legacy behavior

But it prevented long-term lock-in and operational fragility.

4. Architecture & Implementation (Hands-on Leadership)

What I personally owned:

• Reverse-engineering undocumented Salesforce Marketing Cloud automations

• Designing event schemas and profile update logic

• Defining orchestration patterns compatible with Journey Optimizer

• Establishing decision rules for when to use:

  • Event-based triggers
  • Profile attribute evaluation
  • External scoring inputs

Critical contribution:

New platform capabilities were not pre-defined. I proactively explored, validated, and operationalized them while the migration was ongoing.

5. Why This Required Me

This project could not be delegated or outsourced because it required simultaneous understanding of:

• Business intent behind each automation
• Technical constraints of both platforms
• Organizational risk tolerance during migration

I acted as:

• Translator between legacy logic and future architecture
• Decision-maker when documentation did not exist
• Early adopter defining how the new platform should be used

In practice, the platform’s final operating model was co-created during the migration, not beforehand.

6. Outcome

• Successful transition from volume-based automation to lifecycle-oriented orchestration
• Automation logic simplified and standardized
• Increased flexibility for experimentation and KPI-driven iteration
• Foundation established for LTV-focused CRM operations

7. Transferable Insights

• MA migration fails when treated as a technical porting task
• Automation logic must be abstracted from tooling
• New platforms require exploratory adoption, not just implementation
• Long-term scalability depends on intentional loss of legacy behavior

This project came with a lot of pressure, as the company had made a significant investment and, like most projects, there was a tight timeline.
Many engineers were initially against replacing the existing system due to its complexity, with concerns that the project would take too long or that something might go wrong.


In the end, we completed the project on time, and I genuinely enjoyed working on it. While it was intense, I liked exploring new tools, learning along the way, and tackling problems—especially when we faced critical issues.