Moving email providers is not simply a transfer of addresses. Preferences, unsubscribes, evidence, templates and active workflows need to remain coherent so a technical migration does not become an unexpected new sending practice.
Inventory the existing process before exporting
List the data and functions actually used. These may include contact fields, topic interests, consent associations, suppression lists, templates, forms and automations. Note connected systems that create or update contacts too.
Distinguish active recipients from unsubscribed, unconfirmed and undeliverable records. One file without status information is not a complete representation of the existing process. Check what the old service can actually export and in which format.
Record counts and field definitions. The number of records may differ from the number of unique addresses. Discovering that only after import makes it harder to decide whether information is missing or simply organized differently.
Design the new mapping first
Map each necessary old field to an appropriate meaning in the new system. Identical field names do not always imply identical functions. A status might describe an import state in one service while another treats it as permission to send.
Examine overlapping memberships. A person may have chosen several topics while also being excluded from a particular message type. Preserve that combination. Avoid a simplified rule treating every available address as an active subscriber.
Document fields that cannot be transferred. Decide deliberately whether they remain necessary in a protected supplementary record or can be removed. Do not replace missing data with invented defaults.
Control sending during the transition
Set a changeover point and assign responsibility. If both systems receive new contacts simultaneously, a later reconciliation may be necessary. If changes are not processed during a pause, establish how they will be caught up afterward.
Pay particular attention to unsubscribes during the transition. A list exported shortly before switching can already be outdated. Transfer relevant changes up to the actual launch and ensure that a new registration does not accidentally override an earlier suppression without an appropriate basis.
Pause old automations deliberately and identify contacts partway through a sequence. Restarting everyone can repeat messages. Resuming at the wrong step can omit necessary information. For some workflows, a documented completion in the old system may be more suitable than immediate full transfer.
Check technical settings separately
The sender name, reply address and domain configuration must fit the new route. Implement required authentication using current documentation from the selected provider. A successful import does not establish correct sending configuration.
Check new website forms and links. Old embedded forms may continue submitting data to the former provider. Confirmation or unsubscribe links in older messages may still matter too. Clarify how the respective services handle those transition cases.
Templates need their own rendering test. Images, buttons and personalization fields may not transfer unchanged. Inspect actual messages in test inboxes, especially fallback text for missing values.
Rehearse a small migration
Use controlled test records representing different states: active, unconfirmed, unsubscribed, multiple interests and missing optional information. Do not use a random group of real recipients for experiments without an appropriate basis.
After import, compare values and statuses, not only counts. A matching total can conceal incorrect associations. Then inspect who would actually be selected for a specific campaign.
Test unsubscribing in the new system, followed by reimporting an older test dataset. The contact should remain excluded appropriately. Check duplicates and spelling variations too, without carelessly combining different people.
Define completion and a fallback
Decide when the migration is complete and which errors require stopping. Keep an appropriate protected backup for a justified transition need. A fallback plan must not lose unsubscribes that occurred in the meantime.
Cancel the old service only after necessary data, evidence and working transition routes are resolved. Remove unnecessary access and data afterward according to the agreed plan. Record what was transferred, what was tested and what was deliberately omitted.
Investigate anomalies after the first campaigns without immediately blaming content or audience. Technical and organizational differences can operate together during a provider change. A clear change log helps separate their effects and gives the team a way to explain the migration later without relying on recollection.
Explain discrepancies in a reconciliation record
Suppose the old export contains 520 records while the new system shows 498 contacts. Duplicates may explain the difference, but so may rejected rows or misunderstood status values. The smaller number is neither automatically an error nor proof of successful cleanup.
Assign every discrepancy a documented cause. Protect error logs and use test data first to examine how the new service handles problematic rows. Avoid changing all values at once when that would make it impossible to identify the necessary correction.
Also compare small, deliberately selected groups, such as confirmed contacts with two interests and unsubscribed contacts. Matching their attributes provides stronger evidence than comparing only totals. Unexplained differences remain unresolved and prevent use of the affected sending route until their cause is understood.
