Case Study — Compassion Australia

Marketing Cloud re-platform.

Re-platforming Salesforce Marketing Cloud onto a new account and Sales Cloud org — with a governed two-environment architecture and a clean migration of every live supporter journey.

ClientCompassion Australia
SectorFor-purpose / Charity
DisciplineMarketing Cloud architecture & migration
PlatformSalesforce Marketing Cloud
3
Integration patterns proven
2
Governed environments (UAT + Production)
30 days
Go-live hypercare
01 · Context

A platform that speaks to thousands, personally.

Compassion Australia runs child sponsorship — a deeply personal, long-term relationship with hundreds of thousands of supporters. Those communications run on Salesforce Marketing Cloud, tightly integrated with Sales Cloud. As part of a platform-wide move to a new Salesforce environment, Compassion migrated to new Sales and Marketing Cloud instances — and every live supporter communication had to move with it, without disruption.

02 · The challenge

Move the whole engine — without missing a beat.

Re-platforming meant rebuilding the entire Marketing Cloud environment against a new Sales Cloud org and data model, then migrating every triggered send, journey and automation that keeps supporters informed — welcome and confirmation, arrears recovery, return-to-sender, gift-of-compassion e-cards, new-letter and Christmas servicing notifications, the monthly birthday run and payment reminders.

Marketing Cloud offers no true sandbox, so there was no safe, standard way to test integration changes away from production. The migration also had to protect data integrity and marketing permissions, and leave Compassion's own team with a repeatable way to deploy future change.

03 · Discovery

First, we mapped everything.

Before committing to a build, we ran discovery workshops with Compassion to set the goal together: give their own team the ability to run marketing and fundraising campaigns with as little external help as possible — and shape the new platform around that independence.

We started by surfacing the full picture — a dependency register that traced every live Marketing Cloud process back to the Sales Cloud objects and attributes it relied on, over a thousand dependencies in all. Compassion could then review, process by process, exactly what needed to carry across to the new instance and what could be retired.

  • We agreed the integration approach up front — standard, out-of-the-box Marketing Cloud Connect using three communication patterns (Campaign membership, Action-based CRM events, and Segmentation) — and proved each one with a feasibility proof of concept.
  • For every object agreed to carry across, we built an old-to-new mapping — each legacy attribute mapped to its destination object, field and data type in the new schema — to guide the migration team through data migration while preserving the supporter journey experience either side of cutover.
  • Dependencies were tracked collaboratively against owner, status and timeline, so build progressed only as the upstream Salesforce work landed.
04 · The solution

A governed two-environment architecture.

With the dependency picture agreed, we designed the architecture Marketing Cloud doesn't give you out of the box: an administrative parent business unit over governed UAT and Production business units. UAT became a genuine sandbox for integration testing against the new Sales Cloud org; Production became the controlled destination for proven change. Two documented workflows govern it — a System Integration Testing (SIT) workflow for anything touching integrations, schema or marketing permissions, and a Campaign workflow for day-to-day content.

On that foundation we connected Marketing Cloud to the new Sales Cloud org (Marketing Cloud Connect, synchronised data extensions and a clean data model) and rebuilt every live process against the new schema. The self-serve experience — the Preference Centre and a Supporter Survey Cloud Page, the survey carrying a custom scoring model — was recreated. And we re-architected abandoned cart: replacing a brittle payment-failure process with Einstein website feature tagging, a website tagging specification deployed through Google Tag Manager, and custom middleware — including a modified Collect library served from a CDN — opening the door to browse, wishlist and content re-targeting.

Scope rebuilt

Triggered sends3
Journeys6
Automations4
Cloud Pages2

Architecture

Business units3
EnvironmentsUAT + PROD
Governed workflowsSIT + Campaign
IntegrationMC Connect

Delivery

DesignPer-component workshops
BuildUAT → PROD + QA
Hypercare30 days
Warranty30 days
05 · Execution

Designed in UAT, promoted to production.

We ran the build as a managed project — component-level design workshops, a full UAT build and integration test, then a disciplined manual rebuild and QA into a fresh Production business unit with its own naming conventions, credentials and integration user. At go-live we ran an enablement session for Compassion's deployment team so they could own the platform, then provided 30 days of hypercare — daily availability plus proactive monitoring — and a 30-day warranty on delivered work.

Throughout, dependencies were triaged as blocking or partially-blocking — so build could progress on partially-blocked items while end-to-end testing and go-live waited on the upstream Salesforce processes, keeping delivery moving without ever running ahead of its dependencies.

06 · The outcome

A clean migration — and a platform built to evolve.

Compassion moved onto its new Salesforce platform with every supporter communication intact — and with a governed environment model it didn't have before: a real sandbox for integration testing, documented SIT and campaign workflows, and the ability to promote change safely. The re-architected tracking and abandoned-cart foundation opened the way to browse, wishlist and content re-targeting.

Most importantly, it delivered on the goal set in discovery: a well-documented platform Compassion's own team can run and extend — built for self-sufficiency rather than dependence on outside help.

It is also the platform the ongoing email and SMS programme runs on. In 2025 that programme was attributed over $2.6 million in digital revenue (Google Analytics 4) — including over $500,000 from service journeys that carry no marketing call to action (new-letter notifications, birthday-gift notifications and welcome journeys) and approximately $958,000 recovered through arrears journeys. These figures count only the first transaction, while many conversions are recurring sponsorships with an average tenure of around seven years.

$2.6M+
Digital revenue attributed, 2025 (GA4)
$958K
Recovered through arrears journeys, 2025 (GA4)
~7 yrs
Average sponsorship tenure

Re-platforming something critical?

Start a Conversation