Email Platform Migration

Email marketing software migration checklist.

A safe email-platform migration is not “export contacts, import contacts, cancel the old account.” It is a controlled transfer of subscriber data, permission evidence, segmentation, templates, forms, automations, integrations, reporting context, sending infrastructure, and operational responsibility.

Start the Checklist Understand Audience Structure

Guide type Implementation checklist

Migration style Staged & reversible

Vendor scope Platform-neutral

Commercial links None on this guide

Before the checklist

Treat migration as a temporary two-system project.

A safer migration usually creates a period where the old platform remains available while the destination account is configured, tested, validated, and gradually assumed to be the new operating system.

Preserve rollback. Do not remove the old system while a critical workflow may still need to be recovered.

Move meaning, not just rows. A CSV may preserve values while losing the business logic behind fields, tags, segments, and automation.

Revalidate permission. A successful import does not by itself prove that every record should receive future marketing.

Rebuild deliberately. Do not recreate years of old complexity unless the workflow still serves a useful purpose.

Test actual behavior. Screens that look correct can still contain broken triggers, links, forms, or routing.

Cancel only after evidence. Savings from early cancellation are small compared with the cost of discovering later that something important was lost.

Migration is partly a cleanup opportunity. The goal is not to reproduce every historical object. It is to preserve what matters and rebuild the system the business actually needs now.

Migration at a glance

Six broad stages from old system to new system.

Inventory Document data, assets, workflows, integrations, and dependencies.

Preserve Export records, evidence, reports, and configuration references.

Rebuild Create the required structure and workflows in the destination.

Validate Test imports, forms, messages, automation, and integrations.

Cut over Move production activity in a controlled order.

Retire Archive what matters and cancel only after rollback is unnecessary.

Full migration checklist

Work through the migration in a controlled order.

Exact interfaces differ by vendor, but the migration questions are broadly reusable across email platforms.

Discovery

Inventory the existing platform.

Before changing anything, identify what currently exists and which external systems depend on it.

Record the current plan, account owner, billing cycle, and renewal date

Record current subscriber/contact totals

List lists, audiences, groups, tags, fields, and segments

List active campaigns and recurring newsletters

List automation workflows and sequences

List forms, landing pages, popups, and embedded signup points

List sending domains, sender identities, and reply addresses

List integrations, APIs, webhooks, plugins, and middleware

List ecommerce, payment, CRM, analytics, and tracking connections

Identify reports or historical data that may be needed later

Do this before exporting. An export can tell you what records exist, but not necessarily which workflows, pages, forms, integrations, or business processes depend on the account.

Preservation

Export and archive before cleaning.

Keep an untouched migration archive before making cleanup decisions. That gives the business a reference copy if something is misunderstood later.

Export the available contact database

Preserve useful fields, tags, and other subscriber attributes

Preserve subscription and consent-related evidence available to you

Preserve suppression, unsubscribe, and bounce-related information where available and necessary

Export or archive important reports

Save copies of important email content

Document forms and landing pages

Document active automation logic

Record integration settings and connection points

Save account screenshots or configuration notes where exports are insufficient

Preserve the original archive separately. Do not overwrite your only source export with the cleaned migration file.

Cleanup

Decide what should actually move.

Migration is a poor time to carry forward records and structures nobody understands or needs.

Identify clearly invalid or obsolete records

Review duplicate records and duplicate identities

Separate active business records from obsolete historical clutter

Identify contacts whose permission status is uncertain

Review old tags that no longer drive a useful action

Review fields with unclear or inconsistent values

Identify segments that can be recreated from cleaner data

Identify workflows that should be retired rather than rebuilt

Identify forms and pages that no longer receive meaningful traffic

Keep an audit trail of important cleanup decisions

Do not use migration as an excuse to erase compliance evidence. Cleaning marketing clutter and preserving records relevant to permission, suppression, or business history are different tasks.

Data model

Map the old audience structure to the new one.

Do not assume lists, groups, tags, fields, and segments mean the same thing in both systems.

Map required standard contact fields

Map custom fields and valid values

Decide how old tags should be represented

Decide whether old lists should remain separate

Reinterpret platform-specific groups where necessary

Recreate dynamic segment logic rather than merely copying names

Identify the destination system's authoritative customer-state field

Preserve acquisition source where it remains useful

Preserve meaningful interest or preference data

Document which system owns each important business state after migration

Preserve meaning, not terminology. The correct destination object may have a different name from the source object.

Destination setup

Build the new account foundation before the full import.

Configure the destination with the minimum required structure so imported data has somewhere correct to go.

Confirm the destination plan supports the required workflow

Configure account and business information accurately

Configure approved sender identities

Configure required fields and audience structure

Establish consistent tag or label naming

Create required base segments

Review unsubscribe and preference handling

Review default footers and required account information

Verify intended business activity fits current provider policy

Document the destination configuration before production use

Controlled import

Import a small test sample first.

A small representative sample can expose field mapping, encoding, classification, and duplicate-handling problems before the entire database is affected.

Create a representative sample of testable records

Include records with different field values

Include representative tags or classifications

Map each source column deliberately

Confirm dates, numbers, and text fields import correctly

Inspect duplicate handling

Confirm destination subscription status is appropriate

Verify important segments return the expected sample contacts

Correct mapping problems before expanding the import

Record the final import mapping for the production import

A successful file upload is not a successful migration. Inspect the resulting contact records and segmentation behavior.

Content & capture

Rebuild emails, forms, and landing-page connections.

Subscriber records can move without recreating the places where new subscribers enter or the messages they receive.

Rebuild required email templates

Verify sender and reply-to settings for each important message

Rebuild required signup forms

Rebuild or reconnect landing-page forms

Reconnect website embeds

Review consent language and field collection

Configure success, confirmation, or thank-you states

Test every important link

Check desktop and mobile rendering

Confirm each signup route creates the expected subscriber data

Automation

Rebuild workflows from business logic, not screenshots alone.

Automation builders rarely migrate as portable objects between unrelated platforms. Reconstruct the logic deliberately.

Document the trigger for each required workflow

Document entry requirements and exclusions

Rebuild email steps

Rebuild waits and scheduling rules

Rebuild conditions and branch logic

Rebuild field, tag, or status updates

Rebuild exit conditions

Remove historical complexity that no longer serves a purpose

Test every meaningful branch with controlled contacts

Keep production automations inactive until validation is complete

Use migration to simplify. Rebuilding a workflow is an opportunity to remove obsolete branches rather than reproducing them automatically.

Integrations

Reconnect the systems around the ESP.

Email software often sits in the middle of forms, websites, analytics, payment systems, CRMs, ecommerce tools, and other applications.

Reconnect website forms and plugins

Reconnect ecommerce or payment events where required

Reconnect CRM or customer-state synchronization

Reconnect analytics and conversion tracking

Reconnect APIs or webhooks

Reconnect middleware or workflow-automation tools

Replace old API keys or account identifiers

Test data moving in both required directions

Test failure behavior where practical

Update internal documentation with the new connection path

Sending infrastructure

Configure and verify the production sending setup.

A migration may require changes to sender verification and domain-related configuration. Treat those as production infrastructure rather than cosmetic settings.

Verify approved sender addresses

Verify reply handling

Configure required domain authentication according to current provider guidance

Review existing DNS records before changing anything

Avoid deleting working records simply because the new vendor provides different instructions

Verify the resulting authentication state after DNS changes

Confirm branded links or tracking domains where applicable

Test messages to controlled inboxes

Inspect message content, links, and sender identity

Document the final production DNS and sender configuration

DNS changes deserve their own rollback plan. Record the working state before modifying domain records.

Production import

Move the validated contact set.

Once the sample import, account structure, and critical workflow tests are satisfactory, move the intended production audience.

Use the cleaned migration dataset rather than the untouched archive

Use the verified field mapping

Preserve required classification data

Confirm import totals against expectations

Spot-check representative contact records

Validate high-value segments

Confirm exclusions and suppression handling

Investigate unexpected duplicates

Record the final production import date

Keep the source archive unchanged

Cutover

Move production traffic in a controlled order.

Avoid flipping every dependency simultaneously when the system allows a more controlled transition.

Identify the planned cutover window

Confirm destination forms and signup routes are ready

Confirm destination automations are ready

Confirm destination integrations are ready

Redirect new subscriber acquisition to the destination

Activate required production workflows

Send controlled production traffic first where practical

Monitor new contacts entering the correct audiences

Monitor unexpected errors or duplicate activity

Keep the source platform available for rollback

The objective is confidence, not speed. A short parallel period can be cheaper than reconstructing a missing workflow after the source account is gone.

Post-cutover

Validate the new system under normal operation.

Do not declare the migration complete merely because the first production message sends successfully.

Confirm new subscribers enter correctly

Confirm fields, tags, or classifications populate correctly

Confirm welcome or fulfillment workflows start correctly

Confirm expected branches and exits work

Confirm unsubscribe handling works

Confirm key forms and pages continue functioning

Confirm integrations continue exchanging expected data

Confirm reporting captures expected activity

Review operational errors or support issues

Correct issues before retiring the source platform

Archive & retirement

Preserve what matters, then retire the old platform.

The old account should be canceled only after the business is confident it no longer provides necessary data, rollback capability, or operational function.

Complete a final contact export if useful

Preserve required historical reports

Preserve consent or subscriber-history evidence still needed

Save final automation documentation

Save any remaining content that has not been recreated elsewhere

Confirm no active website forms still point to the old system

Confirm no API or integration still depends on the old account

Confirm no scheduled campaigns remain active

Review cancellation timing and billing consequences

Cancel only when rollback is no longer reasonably required

Cancellation is the last migration step, not the first cost-saving step.

High-risk migration areas

These are the places most likely to be missed by a contact-only migration.

Consent context A contact file may not preserve every detail of when, where, or under what expectation a subscriber joined.

Suppression information Unsubscribed, bounced, complained, or otherwise restricted records should not accidentally return to normal marketing.

Dynamic segments The members can export while the rule that generated the membership does not.

Automation exits Rebuilding entry logic but forgetting stop conditions can create inappropriate follow-up.

Embedded forms Old forms can continue sending new leads into a system you believe has already been replaced.

Integrations A checkout or CRM may continue updating the old account unless connection details are changed deliberately.

Historical reporting Past campaign and automation data may not transfer into the destination reporting interface.

DNS and sender configuration Production sending settings can affect more than one service and should not be changed casually.

Migration validation

Do not judge success from one number.

A migration can preserve the correct contact total and still break subscriber states, segmentation, forms, automation, or integrations.

Record count Does the intended migrated population approximately reconcile with the source after deliberate cleanup and exclusions?

Field accuracy Do representative contacts contain the expected values in the correct destination fields?

Segment accuracy Do important dynamic audiences contain the people you expect and exclude the people you do not?

Form accuracy Does each important signup route create the correct contact and required metadata?

Automation accuracy Do entry, waits, branches, actions, and exits behave correctly?

Integration accuracy Do connected business systems send and receive the required data?

Message accuracy Are sender identity, personalization, links, content, and rendering correct?

Subscription handling Do unsubscribe and other relevant eligibility states behave as intended?

Reporting accuracy Can the business observe enough activity to operate and troubleshoot the new system?

What to archive

Some data is valuable even when it does not belong in the new ESP.

The destination platform does not have to become the permanent warehouse for every historical artifact.

Original exports Keep untouched source exports separate from cleaned import files.

Consent evidence Preserve relevant acquisition and permission records not fully represented in the new contact schema.

Historical reporting Save reports needed for business analysis, reconciliation, or future reference.

Workflow documentation Preserve diagrams, screenshots, notes, or exports that explain how old automations worked.

Content archive Save important past email content that should remain available after account cancellation.

Migration decision log Record what was migrated, rebuilt, retired, excluded, and why.

Migration cost

Include temporary duplication in the migration budget.

A controlled migration can briefly require two subscriptions and additional administrative work. That temporary overlap may be part of the cost of reducing operational risk.

Parallel subscriptions Source and destination may both remain active during setup and validation.

Rebuild time Templates, forms, automations, and integrations can require manual reconstruction.

Testing time Controlled tests reduce risk but still require deliberate execution and review.

DNS and technical work Production sender setup may require domain configuration and verification.

Learning time The new platform has its own interface, terminology, and operating model.

Opportunity cost Migration temporarily consumes attention that could otherwise go to normal marketing or operations.

Understand Email Software Cost Audit the Full Software Stack

Product-specific example

Generic migration principles should lead into vendor-specific implementation.

This checklist intentionally avoids pretending that every provider imports contacts, handles custom fields, structures segmentation, or configures domains in the same way.

Generic guide Defines what must be preserved, rebuilt, tested, and validated regardless of vendor.

Product migration guide Documents the destination vendor's current import formats, field mapping, interface, and limitations.

Product setup guide Continues after migration into sender setup, segmentation, automation, forms, reporting, and operational configuration.

See the GetResponse Migration Guide GetResponse Setup Guide

The cancellation gate

Do not cancel the source account until these statements are true.

Required contacts are present. The intended audience and important attributes have been validated.

Permission handling is understood. Important consent and suppression context has been preserved appropriately.

Signup routes work. New subscribers are entering the destination correctly.

Required automations work. Important entry, branch, action, and exit behavior has been tested.

Integrations work. Critical systems no longer depend on the source ESP.

Sending works. Sender identity, domain setup, links, content, and controlled delivery tests are satisfactory.

Important history is archived. Reports, exports, and other source-only information have been preserved.

Billing impact is understood. The cancellation date, renewal timing, and expected account state are known.

Rollback is no longer needed. The destination has operated successfully long enough for the business to accept retirement of the old system.

If one of these remains uncertain, the migration may not be finished.

Evidence standard

Migration guidance should separate durable process from changing vendor details.

StackEvidence uses this page for the durable migration framework. Exact file formats, import limits, field behavior, plan requirements, DNS instructions, and product interfaces belong on vendor-specific pages and should be refreshed before an actual migration.

Durable Inventory, preserve, clean, map, rebuild, test, cut over, archive, and cancel last.

Vendor-specific Import formats, file-size limits, plan gates, interface steps, and current feature behavior.

Permission-sensitive Consent, suppression, unsubscribe, and subscriber eligibility should not be reduced to a simple contact-count exercise.

Testable Important migration assumptions should be verified with controlled records before full production use.

Reversible Preserve source access until the destination system has been validated sufficiently to remove rollback dependence.

Commercial transparency

A migration guide should reduce switching risk, not manufacture reasons to switch.

This page contains no affiliate links. Changing email platforms can create meaningful cost and operational risk, so migration should follow a documented business reason rather than a promotion or a temporary feature difference.

If you have not chosen a destination yet, use the requirement-first buying framework before beginning migration work.

Email Marketing Research Hub How We Evaluate