How to Migrate a Marketing Automation Platform Safely

A stack audit establishes that change is justified. A migration plan determines how to make that change without losing operational, customer or measurement integrity.

A marketing automation migration begins after the organisation has approved a replacement or consolidation decision. The migration team should not use the project to reopen the entire martech strategy, unless it discovers a material error in the approved requirements. That restraint is what keeps a migration finishable.

Complete a capability-led martech audit before migration begins. Use the analytics and reporting architecture to define the measurement interfaces and continuity requirements the target platform has to preserve.

A successful migration is not a completed import. It is a controlled transfer of business behaviour and accountability, and the difference between those two definitions is where most of the damage happens.

What the Migration Must Protect

The migration has to account for customer and account records, identifiers and relationships, permissions, consent evidence and suppressions, lists and segments, lead or customer scoring, forms and landing pages, campaigns and automated workflows, templates and reusable assets, integrations, user access and approval processes, historical reporting, audit and operational records, and support and incident procedures.

That list is longer than most plans allow for, and the items at the end are the ones that get discovered late.

1. 1. Start from an approved decision Record why the change was approved, who approved it and what is explicitly out of scope, before any inventory work begins.
2. 2. Freeze undocumented change Put change control on the source platform so the mapping specification does not become obsolete while it is being written.
3. 3. Map, then decide what stays behind Document every object, field and transformation, and give every excluded object an explicit disposition rather than a silent omission.
4. 4. Reconcile permissions separately Consent, objections and suppressions get their own mapping, their own tests and their own sign-off, independent of the general contact import.
5. 5. Cut over through gates Use a runbook with entry criteria, checkpoints, abort criteria and a rollback route that was defined before the change window opened.

Before Anything Moves

Three pieces of groundwork determine whether the rest of the project is measurable: a recorded decision, a frozen baseline and a control register.

Establish the Decision, Scope and Sponsor

Record the approved reason for change, whether that is replacement of an unsupported platform, consolidation, unmet capability requirements, unacceptable risk, a contractual or cost change, or an organisational restructuring.

Then define the target platform and approved modules, the countries, brands and business units in scope, the data populations, the channels, the integrations, the history to retain, the workflows to rebuild, the excluded scope, the success criteria, the budget and the accountable sponsor.

The migration team has to be able to tell required scope from desirable improvement. Without that line, every rebuild becomes an opportunity to fix something that was not in the business case, and the cutover date moves.

Be specific about who actually approved the change, because job titles mislead. I once spent two years on an account at the Turkish arm of a global cosmetics brand where the CMO genuinely liked what we did. The title was convincing enough that I never investigated the decision structure behind her. When the change came, she told me they were moving to another vendor and that she had argued against it. The global team had decided. If your migration sponsor is the person who likes the target platform rather than the person who can fund and enforce the decision, you will find out during cutover, which is the worst possible time.

Freeze Undocumented Change

Before inventory and mapping begin, introduce change control on the source platform.

The point is not to prohibit business change. It is to require that changes are requested, documented, approved, added to the migration inventory, and tested in both source and target where necessary.

Documented baselines and controlled changes are treated as necessary to maintaining system integrity in established configuration management guidance (1). That guidance was written for United States federal information systems and addresses the security aspects of configuration management rather than marketing platform migration, but the underlying failure it describes is exactly the one migrations suffer: without a controlled baseline, workflows, fields or templates change after mapping and quietly make the specification wrong.

Build the Migration Control Register

For every migrated object, record the source platform, object and version; the target object or configuration; the business and technical approvers; the transformation applied to fields, statuses, identifiers and formats; the expected source and target counts; the validation rule that will test correctness and completeness; the effect on consent, subscription status or suppression; the forms, workflows, integrations, reports or users that depend on it; the cutover method; and the rollback method.

The register is the central evidence set for scope, testing, reconciliation and sign-off. If it is not maintained, there is no defensible answer to the question of what moved and what did not.

Mapping Source to Target

This is the longest phase and the one most often compressed, usually because the objects look similar from a distance.

Inventory Assets, Data and Integrations

Inventory active and dormant objects alike: record types and custom objects, fields and permitted values, lifecycle stages and statuses, deduplication rules, lists and segments, scores and models, subscription categories, suppressions, forms, landing pages, workflows, campaigns, programmes, templates, images and documents, tracking domains, integrations, webhooks, API clients, scheduled exports, reports, and users, roles and approvals.

Check specifically for assets maintained by agencies, regional teams and former employees. Those are the ones with no owner to consult and no documentation to inherit.

For each object, decide whether it is active, required historically, obsolete, duplicated, unowned, or unsafe to migrate without remediation.

Define Source-to-Target Mappings

Do not assume that similarly named objects behave identically.

Map object types, field types, field lengths, required fields, enumerated values, identifiers, relationship models, ownership, timestamps, status histories, deletion markers, activity types, campaign membership and channel specific settings. Document every transformation: splitting one source field into several, merging duplicate status values, converting free text into controlled categories, replacing an internal identifier, changing account to contact relationships, or mapping unsupported activity types into an archive.

Official import interfaces show why this precision is necessary. In one major platform’s current import API, the operation type determines whether records are created, updated or upserted, with upsert as the default, while the column mappings separately identify the target object and property for each column and carry the fields that establish associations across multi object or multi file imports (2). Those are two different mechanisms. A team that assumes the mapping alone controls whether a record is created or updated has misunderstood the interface before writing a single row.

Scale limits belong in the mapping work too, not in the cutover week. The same documentation records a daily row ceiling in the tens of millions, a per file limit of just over a million rows or several hundred megabytes, and a small number of imports processing simultaneously before further imports are deferred (2). Those numbers are generous. Other platforms are not, and the difference decides your batching strategy.

Decide What Should Not Migrate

Migration is not an obligation to reproduce every historical defect.

Candidates for exclusion include obsolete templates, expired campaigns, duplicate records, unused fields, test data, unsupported customisations, broken workflows, reports with no users, data that has exceeded its required retention, and records with no valid purpose for continued processing.

Give every excluded object an explicit disposition: delete, archive outside the operational platform, retain temporarily in read only form, transform, or document but do not move. Obtain business, legal, privacy and records management approval where it applies. An object that is simply left behind without a decision is a gap somebody will find during an audit.

Map Permissions, Suppression and Legal Records

Permissions cannot be inferred from activity or engagement, and this is the one part of the migration where a mistake is not merely operational.

Map subscription categories, consent state, consent source, consent timestamp, any recorded permission evidence, channel preferences, brand and regional preferences, objections, unsubscribe events, suppression reasons, do not contact states, and pending or ambiguous records. Do not convert an unknown state into permission.

Where a person objects to direct marketing, the organisation must stop, or not start, sending it to them. On suppression, the regulator’s position is more precise than it is often reported: data protection law and the privacy and electronic communications rules do not expressly require an organisation to maintain a suppression list, but the regulator says an organisation should use one, retaining only the minimum information needed to recognise the person and honour their preference in future (3). The mandatory outcome is that the objection is respected. The suppression list is the recommended method of achieving it, and that distinction matters when a migration team is deciding how much of a suppressed record to carry across.

The target platform’s model will differ from the source. One major platform’s current communication preferences API separates defined subscription types, exposes statuses including subscribed, unsubscribed and not specified, and carries fields describing the lawful basis and an explanation of it (4). That is the vendor’s description of its own data model. It is not a legal conclusion, and selecting a value in a field does not by itself establish a valid lawful basis under applicable law. The same documentation notes that the documented status operations cover email as the supported channel, which is a real constraint if the source platform held preferences across several channels.

For the broader principles, see ethical consumer-data use.

Reconcile permissions independently from the general contact import, with their own tests and their own sign-off.

The source platform may contain workflows that the organisation no longer permits, supports or intends to operate. Regulatory change, risk appetite and internal policy all narrow what a business will actually switch on. Migration scope should therefore reflect current approved use rather than every historical capability or configuration, or the project will spend weeks rebuilding journeys nobody intends to activate.

Rebuilding the System

Configuration first, then data, then behaviour. Reversing that order is the most common way to spend a fortnight loading records into a target that cannot hold them correctly.

Rebuild and Test Integrations

For every integration, specify purpose, source and destination, direction, authentication, objects and fields, frequency, volume, retries, ordering, error handling, monitoring, owner and recovery procedure.

Then test expected success, invalid records, duplicate delivery, timeout, authentication expiry, rate limits, partial failure, downstream unavailability, replay or retry, and changed identifiers.

Do not wait until cutover to discover that a target API has different limits or different update semantics.

Migrate Reference Data and Configuration

Move or recreate foundational configuration before dependent records: business units, brands, domains, currencies, countries and regions, users and teams, roles, field definitions, lifecycle values, campaign classifications, subscription types, naming conventions, integration credentials and controlled lists.

Validate that configuration against the approved target design. Avoid carrying source conventions into the target when the project has explicitly approved a new model, because those conventions are difficult to remove once records reference them.

Migrate Selected Historical Data

Decide which history has to remain operational in the target and which can be archived. The categories usually in question are contacts and accounts, lifecycle changes, activity history, campaign membership, email sends and outcomes, form submissions, score history, preference changes, workflow enrolments and sales hand-offs.

Platform support for those categories is not symmetrical, and the asymmetry is easy to miss because export and import are documented separately. On one major automation platform, the bulk extract interfaces cover leads, activities, programme members and custom objects (6), while the bulk import interfaces cover leads, custom objects and programme members (7). Activities can be extracted and cannot be bulk imported. Any plan that assumes activity history will be round tripped out of the source and into the target through those interfaces is assuming something the documentation does not support.

The operating limits differ too. The same platform’s extract interface documents a small number of concurrent jobs, a queue ceiling, a shared daily export allocation measured in hundreds of megabytes, a file retention window of about a week and a maximum date range per filter of around a month (6), while its import interface documents a file size limit measured in single figure megabytes and describes the operation as an insert or update whose response does not report, record by record, which of the two occurred (7). Those constraints shape the extraction calendar and the reconciliation method, and they need to be read before the plan is written rather than during it.

For every historical object, extract it, preserve an immutable source copy, validate the format, transform, load into a test environment, reconcile counts and key values, investigate exceptions and obtain owner approval. Do not force all history into the target when a governed archive is safer and cheaper.

Rebuild Workflows and Campaigns

A workflow is behaviour, not a diagram.

Document entry criteria, exclusions, timing, waits, branches, precedence, re-enrolment, frequency caps, actions, ownership changes, notifications, external calls, failure handling, exit criteria and measurement events.

Rebuild deliberately rather than translating every configuration one for one. Remove obsolete logic, but record every intentional difference, because the difference between a deliberate change and a migration defect is only visible in the register.

Test workflows against representative records: an eligible record, an ineligible record, a suppressed record, a duplicate record, a record with a missing field, a late event, a re-entry attempt, an integration failure, and a boundary time or date.

Validate Templates and Rendering

Inventory and test email templates, landing pages, forms, preference centres, dynamic content, personalisation tokens, fallback values, links, tracking, sender identities, domains, mobile and desktop rendering, accessibility, localisation, and legal and preference content.

A template that imports successfully can still fail, because the target may use different token syntax, different CSS handling, different content blocks or different tracking behaviour. Use a controlled test matrix covering the relevant clients, devices, languages and dynamic content states.

Test Segmentation and Scoring

For each important segment, compare the source logic, the target logic, the expected population, the actual target population, the additions, the omissions and the reasons for any difference. Run both against the same frozen test population and investigate material divergence rather than accepting broad similarity.

For scoring, document inputs, weights, thresholds, decay, exclusions, recalculation frequency and downstream action. A target score does not have to reproduce a flawed source score indefinitely, but any redesign should be approved as a separate analytical change rather than smuggled in as part of the migration.

Reconcile Reports

Catalogue the reports that have to survive cutover. For each one, document the business owner, audience, metric definitions, source fields, historical period, refresh schedule, filters, attribution or assignment logic, expected totals, tolerance and sign-off.

Decide whether historical and post cutover data will be combined in one governed analytical model, shown as separate periods, restated, or archived.

Import results are the reconciliation evidence, and they are usually asynchronous. One major platform’s documentation on retrieving import results describes processing statuses covering new, processing, completed, error and further intermediate states, and notes that results may not be available immediately because imports are processed asynchronously (8). Build the wait and the retry into the reconciliation procedure rather than treating a submitted import as a finished one.

Do not silently change metric definitions during migration. Where a change is necessary, publish the effective date and explain the limits on comparability.

Cutover and Recovery

Everything above is preparation for a few hours in which the organisation is exposed. Those hours should be boring.

Prepare People Before the Date

Training should follow roles and tasks, covering campaign operators, analysts, administrators, developers, sales or service users, approvers, privacy and compliance teams, and both first line and specialist support.

Provide role based procedures, target state process maps, known differences, escalation routes, the cutover calendar, temporary restrictions, support hours, issue reporting templates and administrator runbooks. Measure readiness through task completion rather than attendance.

Run in Parallel Where Justified

Parallel operation reduces some risks and creates others. Decide deliberately rather than by default.

If you run in parallel, define one system of record for every object and every process during the period, and prevent both platforms from independently changing the same state unless the synchronisation has been designed and tested.

Perform Cutover

Use a runbook containing entry criteria, the approved change window, owners, the communication plan, the source freeze, the final incremental extract, the load sequence, reconciliation, the integration switch, workflow activation, domain changes, monitoring, decision checkpoints, abort criteria and rollback authority.

Record the actual start and finish times, the decisions taken, the exceptions raised and the approvals given.

Do not activate all target workflows because data loading has completed. Cutover should proceed through controlled gates, each with someone empowered to stop it.

Validate Production Behaviour

Immediately after cutover, test record creation and updates, permissions and suppressions, segmentation, workflows, forms, landing pages, integrations, authentication, sending, rendering, tracking, dashboards, user access and alerts.

Monitor at defined intervals: immediately, after the first processing cycle and after the first complete business cycle. Use production control records whose expected outcomes are known in advance, so that a defect is detected by a test rather than reported by a customer.

Retain a Rollback Route

Rollback has to be defined before cutover, not improvised during it.

Specify the trigger conditions, the decision authority, the maximum decision time, the availability of the source platform, the configuration and data restore points, how changes made in the target will be captured, how duplicate communications will be prevented, how users and integrations will be redirected, how permission changes made during the attempted cutover will be preserved, and how stakeholders will be told.

Contingency planning guidance in this area emphasises recovery priorities, alternate arrangements, testing and plan maintenance rather than improvised restoration (9). It was written for United States federal information systems and has to be adapted to your service and risk profile, but the discipline holds: rollback does not mean reversing every record. It means restoring an approved level of business operation while preserving the changes that must not be lost, and permission changes are almost always in the second category.

After the Cutover

Decommission Safely

Do not terminate the source immediately after the first successful send.

Before decommissioning, complete the agreed stabilisation period, close unresolved reconciliation exceptions, export required records and configuration, preserve audit, permission and suppression evidence, verify report continuity, revoke credentials and tokens, disable integrations and scheduled jobs, remove user and agency access, confirm contractual deletion and return obligations, terminate licences and support arrangements, update records of processing and architecture documents, and assign ownership of any retained archives.

Maintain read only access only where it has a defined purpose, an owner, a retention period and access control.

Stabilise and Hand Over

Stabilisation is where migrations are quietly judged, because the project team’s attention moves before the users’ problems do.

Prioritise stabilisation issues by frequency, customer impact, operational effort and risk, not by how minor they appear in programme reporting. A defect costing one team ten minutes every morning outranks a cosmetic fault that appears once on a status slide, and the queue will not sort itself into that order without someone insisting on it.

Review Outcomes

Conduct a post migration review against the approved case for change.

Measure migrated object reconciliation, permission and suppression reconciliation, workflow parity, integration failures, deliverability, rendering defects, reporting continuity, user readiness, incidents, rollback events, post cutover business continuity, migration and dual running cost, and the capability gained or lost.

Licence savings alone do not establish success. A cheaper target that creates data loss, operational delay or control failures has not delivered the intended outcome.

Document what changed, the remaining defects, the accepted differences, the lessons, the ownership transferred to operations, future remediation, and the final source decommissioning evidence.

Migration Acceptance Checklist

Do not declare completion until the approved scope is accounted for; every migrated object has an owner and a validation rule; source and target counts reconcile within approved tolerances; permissions and suppressions have separate sign-off; critical workflows pass both expected and failure path tests; integrations are monitored; templates and forms are validated; reports remain explainable across the cutover; users and support teams are ready; rollback criteria were retained through stabilisation; the source has been decommissioned or retained under an explicit archive decision; and operational ownership has formally accepted the target.

A safe migration is one where the organisation can explain what moved, what did not move, how correctness was tested, who accepted each difference, and how service would have been restored if cutover had failed.

Frequently Asked Questions

References

1. L. Johnson, Kelley Dempsey, Ron Ross, Sarbari Gupta and Dennis Bailey, Guide for Security-Focused Configuration Management of Information Systems. NIST Special Publication, reference NIST SP 800-128, DOI 10.6028/NIST.SP.800-128. Originally published 12 August 2011; errata update published 10 October 2019, which NIST describes as making no significant or technical change to the recommended guidance. Status Final; the original 2011 record was withdrawn and superseded by the updated issue. No formal revision number: this publication is not “Revision 1”. Not UK law: issued for United States federal information systems. https://csrc.nist.gov/pubs/sp/800/128/upd1/final

2. HubSpot, CRM API | Imports. Official developer API guide, version 2026-03. Publication date not shown; last updated 31 March 2026. Current page, not marked legacy or deprecated; an earlier version 3 guide remains available at a separate legacy path and should not be used for new development. Vendor technical documentation: HubSpot has a commercial interest in its own platform, and the page establishes supported API behaviour only, not migration quality or platform superiority. https://developers.hubspot.com/docs/api-reference/latest/crm/imports/guide

3. Information Commissioner’s Office, Respect people’s preferences. Section of the standalone Direct marketing guidance, not of the Guide to PECR. No reference number. No section specific publication or last-updated date shown; the parent Direct marketing guidance was published 5 December 2022 and last updated 28 April 2026. No under review notice shown on this section at the date of writing. UK regulator guidance, not legislation. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/respect-peoples-preferences/

4. HubSpot, Communication preferences API guide. Official developer API guide, version 2026-03. Publication date not shown; last updated 14 April 2026. Current page, not marked legacy or deprecated; an earlier version 3 guide remains at a separate legacy path. Vendor technical documentation: it describes HubSpot’s own data model and does not establish that a given lawful basis value satisfies UK data protection or PECR requirements in any particular case. https://developers.hubspot.com/docs/api-reference/latest/communication-preferences/guide

5. Adobe, Authentication. Official Marketo Engage REST API developer guide. Publication date not shown; last updated 13 May 2026. Current page, not marked legacy, deprecated or preview. States that support for authentication using the access token query parameter is being removed on 31 July 2026 and that new development should use the authorization header exclusively. This deprecation date has been revised more than once, so it should be re-checked rather than assumed. Vendor technical documentation: Adobe has a commercial interest in Marketo Engage. https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/authentication

6. Adobe, Bulk Extract. Official Marketo Engage REST API developer guide. Publication date not shown; last updated 13 May 2026. Current page, not marked legacy, deprecated or preview. Note that this page carries a stale authentication notice referring to a 2025 date that has already elapsed; the central authentication guide at reference 5 is the current instruction. Vendor technical documentation: Adobe has a commercial interest in Marketo Engage, and the page describes export interfaces and limits rather than the completeness of any particular customer’s export. https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/bulk-extract/bulk-extract

7. Adobe, Bulk Import. Official Marketo Engage REST API developer guide. Publication date not shown; last updated 13 May 2026. Current page, not marked legacy, deprecated or preview. This page carries the same stale authentication notice referring to a 2025 date that has already elapsed. Vendor technical documentation: it describes supported imports and limits, and does not establish that all extracted data can be restored. https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/bulk-import/bulk-import

8. Salesforce, Retrieve the Results of an Import. Official Marketing Cloud Engagement developer documentation. No API version, publication date or last-updated date shown. Current page, not marked legacy, deprecated or archived. Vendor technical documentation: Salesforce has a commercial interest in Marketing Cloud, and the page covers import result retrieval only, not complete migration reconciliation. https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/retrieving_the_results_of_an_import.html

9. Marianne Swanson, Pauline Bowen, Amy Phillips, Dean Gallup and David Lynes, Contingency Planning Guide for Federal Information Systems. NIST Special Publication, reference NIST SP 800-34 Revision 1, DOI 10.6028/NIST.SP.800-34r1. Revision 1 published 31 May 2010; update published 11 November 2010. Status Final; no Revision 2 draft, initial public draft or pre-draft call for comments found on the NIST publications and public drafts indexes. Not UK law: issued for United States federal information systems and requiring adaptation to any other service and risk profile. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final

Position dated 29 July 2026. Vendor documentation changes without notice, and references 2 and 4 to 8 describe platform behaviour and limits that may be revised at any time. Reference 5 records an authentication change stated to take effect on 31 July 2026, a deadline that has already been revised more than once. Verify every platform constraint against the live documentation for your own project rather than relying on the position recorded here.