Salesforce Marketing Cloud Data Migration

Marketing Cloud Data Migration, Reconciled Before Anyone Sends

Data migration is where a Marketing Cloud move is won or lost. It is not one load but four, and the order is deliberate: consent before subscribers, suppression before any send is enabled, and reconciliation against source before anyone declares it finished. Twopir Consulting runs it that way because the alternative is finding out from a customer.

Scope Your Data Migration Platform Migration
  • 12+ Years of CRM and platform migrations
  • 250+ Platform deployments delivered
  • 98% Client retention rate
Load Order
WHAT LOADS, AND IN WHAT ORDER Consent and preference Channel opt-ins, lawful basis, topics Load 01 Suppression and bounce Hard bounces, complaints, manual blocks Load 02 Subscribers and identity Keys, addresses, deduplication Load 03 Profile and relational Attributes, products, transactions Load 04 Historical engagement Opens, clicks, sends going back years Archive TWOPIR DATA MIGRATION METHOD Field-Level Mapping Signed off before a row moves Staged Loads Each validated before the next Reconciliation Counts, checksums, sampled records 2πr BEFORE THE FIRST SEND Consent state provably intact, not approximately right Every opt-out honoured from the first message Counts that agree with source, and someone who signed Reconciliation as a gate, not as a closing formality
Sequence

Load in This Order, and Validate Between Each

Data migration plans usually sequence by size, because size is what project plans measure. The correct sequence is by consequence — anything that could result in mailing somebody who asked not to be mailed loads before sending is possible at all.

Marketing Cloud data migration load sequence
OrderWhat loadsValidated byWhat goes wrong without it
01Consent and preference stateRecord-level comparison against source for every channel and every market, before anything else is enabled.Someone receives a message they opted out of. That is a compliance matter rather than a data defect, and it cannot be corrected retrospectively.
02Suppression, bounce and complaint historyCount reconciliation plus a sample check that known-suppressed addresses are genuinely blocked in the target.Mailing addresses the previous platform had already suppressed — the fastest available way to damage a new sending reputation.
03Subscribers and identityCounts, checksums and a duplicate analysis against the agreed definition of a duplicate.Duplicate identities that only surface once journeys are running against them, by which point every downstream number is wrong.
04Profile and relational attributesField-level sampling, null-rate comparison against source, and a render test of anything used in personalization.Personalization failing silently at send time, or segments quietly excluding people because an attribute did not arrive.
ArchiveHistorical engagement dataA verified archive outside the platform, with a documented location and retention period.Losing the reporting baseline entirely, which is irreversible once the source platform is switched off.

Capabilities verified against Salesforce documentation Last reviewed 23 September 2026

The Work

What Data Migration Actually Involves

Four bodies of work. The first is the one most plans skip and the one that determines whether the rest is possible — you cannot map data you have not looked at.

Workstream 01

Profiling the source before mapping it

Before any mapping document is written, we look at what is actually in the source: null rates, format variation, encoding, how many records share an email address, how consent is really stored versus how it is described. Every migration that overran did so because this step was assumed rather than done.

  • Null and completeness rates per field, not per table
  • Format and encoding variation, including the rows nobody knew about
  • Duplicate analysis against several candidate definitions
  • How consent is actually represented — flags, dates, separate tables
  • Volume and growth, so the load window can be estimated honestly
  • A written statement of what is wrong with the data, for the client to rule on
Workstream 02

Consent and preference mapping

The workstream with the highest consequence and the least tolerance for approximation. Two platforms almost never model consent the same way — one holds a global flag, another per-channel records, a third infers it from subscription lists — and the reconciliation rule has to be written down and agreed, not improvised during load.

  • Channel-level opt-in and opt-out state mapped explicitly
  • Global unsubscribe handling across every business unit
  • Topic and subscription preferences where they exist
  • Lawful basis and consent timestamp where the market requires it
  • The reconciliation rule for each mismatch, signed off before load
  • Twopir implements the obligation; your legal or privacy team determines it
Workstream 03

Loading into a designed model

Records land in data extensions built for the target architecture with relationships defined in Contact Builder — not in a flat import that mirrors the old platform's tables. Recreating the source schema is faster by a week and costs years.

  • Data extensions designed for the target, not copied from source
  • Subscriber key strategy decided deliberately and documented
  • Relationships defined in Contact Builder before the load, not after
  • Staged loads with a validation gate between each
  • Rollback position at every stage, so a bad load is not a crisis
  • Alignment with the contact model from the implementation
Workstream 04

Reconciliation and sign-off

The migration is finished when the numbers agree and a named person has signed that they agree — not when the last file has been uploaded. Reconciliation runs after every load rather than once at the end, because a discrepancy found at stage two is a fix and the same discrepancy found at stage five is a rebuild.

  • Record counts and checksums per load stage
  • Sampled record-level comparison against source
  • Null-rate comparison, to catch fields that silently arrived empty
  • Suppression spot-checks: is a known-blocked address genuinely blocked
  • A reconciliation report someone signs, naming what was compared
  • Documented variance: what did not match, and why that is acceptable
Decisions

Four Mapping Decisions Only You Can Make

Most of a data migration is mechanical. These four are not — they are business decisions dressed as technical ones, and a partner who makes them for you has quietly decided something about your customers on your behalf.

We will bring the analysis, the options and a recommendation for each. The decision itself stays with you, and it gets recorded, because in two years somebody will ask why the data looks the way it does.

The surrounding platform move — cutover, journey rebuild, reputation warming — is covered on the migration page, and the architecture these decisions feed into on the Marketing Cloud consulting page.

What counts as a duplicate

Same email address? Same person across two addresses? Same household? Each answer produces a different customer count, a different audience size and a different contact count on the invoice. There is no universally correct answer — there is only the one that matches how your business thinks about a customer, and it has to be stated before the load rather than discovered after it.

What to do when the two systems disagree about consent

One platform says subscribed, the other says unsubscribed, and the timestamps are ambiguous. The conservative rule — treat any recorded opt-out as authoritative — costs you reachable audience. The permissive rule costs you something considerably more expensive. This is your call, made with your privacy team, and we will implement whichever rule you set.

Which attributes are worth bringing

Source systems accumulate fields that were populated once for a campaign in 2019. Bringing everything is the default because it feels safe, and it produces a target model as cluttered as the one you are leaving. The useful test is whether marketing segments on it, personalizes with it, or triggers on it — and everything else is archived rather than migrated.

How far back history is worth keeping

Engagement history inflates storage and contact counts without being used operationally, so it belongs in an archive rather than in the platform. But the baseline it represents is genuinely valuable and irreversibly lost if nobody exports it before the old system is switched off. Deciding the retention period deliberately is a five-minute conversation that is impossible to have retrospectively.

12+
Years delivering CRM and marketing platform transformation
250+
Platform deployments delivered
500+
Clients served across global markets
98%
Client retention rate
Failure Modes

Four Ways a Data Load Becomes an Incident

Every one of these has a cheap preventative and an expensive cure, and all four are produced by the same underlying decision: treating the data work as a task inside the project rather than as the thing the project depends on.

If a migration is already underway and one of these is familiar, an audit of what has loaded so far is faster than pressing on.

Consent mapped approximately — The two systems model it differently, the mapping was "close enough", and someone receives mail they had opted out of. It is discovered by the recipient, it is a compliance matter rather than a data defect, and no amount of subsequent correction undoes the message that was sent.

Suppression loaded after sending was enabled — Scheduled late because it looked like historical data. The first send goes to addresses the previous platform had already blocked — including complainants — and a brand-new sending reputation takes the damage on day one.

The source schema recreated in the target — Faster by a week, because no design was needed. Every constraint of the platform you are leaving arrives with the data, permanently, and the first attempt to build a segment reveals it.

Reconciliation left to the end — Five loads run, then the counts are compared and they do not agree. Nobody can say which load introduced the variance, so the only safe option is to unpick all five. Reconciling between stages costs hours; reconciling at the end costs the schedule.

Before You Load

Five Signs the Data Is Not Ready to Move

All five are answerable before a single row is loaded, and every one of them is cheaper to resolve now than after go-live. If two or more are true, the load date is optimistic regardless of what the plan says.

Nobody has profiled the source data, so the null rates, format variation and duplicate volume are assumptions rather than findings.
Consent is described as "in the platform" but nobody can say which field holds it, or what a blank in that field means.
There is no agreed definition of a duplicate, and two people in the business give different answers when asked.
Suppression and bounce history is scheduled as a late task because it was classified as historical rather than operational data.
The plan has one reconciliation step, at the end, after every load has run.
Related

Platform Migration

The surrounding move: inventory, target architecture, journey rebuild, parallel run and staged cutover.

Marketing Cloud Implementation

Where the contact model that this data lands in gets designed.

Integration

Once migrated, the data has to keep arriving — that is a different discipline from moving it once.

Audit

Establishing what is actually in the source, or what state a part-finished load is in.

Data Cloud

Where identity resolution should live when the answer is bigger than one marketing platform.

Marketing Cloud Case Study

A worked example of the architecture-first approach on a real client engagement.

Common Questions

Questions About Moving the Data

Technically yes, and we would usually advise against it. Historical opens, clicks and sends are not used operationally, they inflate storage, and in some configurations they inflate contact count — so they cost money to keep somewhere they earn nothing.

The right home is a warehouse or archive outside the platform. What matters is doing it deliberately and before the source system is switched off, because that baseline is irreversibly lost otherwise. Suppression, bounce and complaint history is the exception: that is operational data and it migrates.

We map it explicitly, field by field, and write down the reconciliation rule for every case where the two disagree — then your privacy or legal team signs that rule before a row moves. That document is the deliverable, more than the load itself.

To be direct about the boundary: we implement the obligation you set. We do not determine what your obligation is in a given market, and any partner who offers to is offering something they are not positioned to give.

They surface during profiling, which is why profiling comes first. What happens next is a business decision: whether a duplicate is the same email address, the same person across several addresses, or the same household, and which record wins when two disagree.

We bring the analysis and a recommendation, and we implement whatever you decide. What we will not do is silently pick a rule — the answer changes your customer count, your audience sizes and your contact count, and it should be a decision rather than a side effect.

Volume is rarely the constraint; a large subscriber file is a straightforward load. What sets the duration is how differently the two systems model consent, how much cleaning the source needs, and how many decisions are waiting on someone in the business.

The load windows themselves are usually a small part of the calendar. Profiling, mapping, decision-making and reconciliation are the bulk of it, and compressing those is what produces the failures on this page.

Yes, and it is a common engagement. Some teams run their own platform move and want the data workstream done properly; others are consolidating business units, loading a newly acquired brand, or rebuilding a contact model in an org they already have.

The method is the same in all of those cases. The surrounding platform work — cutover strategy, journey rebuilds, sending reputation — is on the migration page if you need it.

By a reconciliation report that names what was compared, at what stage, with what result — record counts, checksums, sampled record-level comparison, null-rate comparison against source, and spot-checks that known-suppressed addresses are genuinely blocked.

Someone signs it. That is deliberate: a migration declared complete because the files finished uploading is a migration whose defects will be found by customers instead.

Next Step

Profile the Data Before You Plan the Load

Tell us where the data is coming from, roughly how many records, and how consent is stored today. That is enough to say what the load order should be and where the difficulty will actually sit.

Scope Your Data Migration Platform Migration

Serving: US | Canada | UK | UAE | Australia | New Zealand

Relatable? We should definitely talk.

What we'll cover:

From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.
  • Identify revenue leaks across CRM, integrations, and GTM
  • Design and optimize complex systems (CRM to Custom Apps)
  • Apply practical AI to improve operations and pipeline conversion
  • Eliminate silos and build a unified revenue system
  • Assess GTM performance and key bottlenecks
  • Align teams with clear processes and ownership
  • Define a scalable RevOps model
  • Improve forecasting and reporting
  • Review your HubSpot/Salesforce setup for scale