How to Migrate Email Platforms Without Emailing Unsubscribed Contacts

Inventory every contact state before exporting

List the states that can prevent marketing email in the source system. Depending on the provider, these may appear as unsubscribed, non-subscribed, cleaned, bounced, complained, blocklisted, unconfirmed, opted out of all email, or opted out of a specific subscription type.

Export both the campaign-ready audience and every blocked state. Keep the full account archive separately when the provider offers one. A sendable-only export is not a complete migration because it cannot protect against an address reappearing in a later CRM, billing, form, or integration sync.

• Subscribed or active contacts with permission evidence
• Unsubscribed and globally opted-out contacts
• Non-subscribed or unconfirmed contacts
• Hard-bounced, cleaned, complained, rejected, or blocklisted contacts
• Subscription type, source, timestamp, and list context when available

Normalize identity before comparing status

Trim whitespace and compare email addresses case-insensitively before looking at profile differences. One person can appear across several files with different names, companies, tags, or lifecycle fields. Those profile conflicts are secondary to the marketing state attached to the normalized address.

Keep a trace of every source row used in the decision. The import review should show which files were recognized, which addresses duplicated, which statuses conflicted, and which final state was selected. That record lets an operator explain why a contact is blocked without reopening the old platform.

Make the strongest blocked state win

Do not use last-upload-wins logic. If an address is subscribed in one file and unsubscribed or complained in another, the blocked state should win until a reviewer verifies a legitimate later permission event. A current profile value or recent purchase is not automatically consent for promotional email.

Document the precedence used by the migration. A conservative default places complaint and unsubscribe ahead of permanent bounce or cleaned, then non-subscribed or unconfirmed, and finally subscribed. The exact labels vary by source platform; the governing principle is that ordinary profile updates cannot weaken suppression.

ava@example.com | subscribed.csv | subscribed
ava@example.com | unsubscribed.csv | unsubscribed
ava@example.com | crm-export.csv | active customer

Final marketing state: unsubscribed
Reason: blocked state overrides list membership and profile activity

Retain a minimal suppression record

Deleting the address can delete the fact that it must not be mailed. Retain the normalized identifier, blocked state, source, observed timestamp, and any evidence required by your policy. Keep unrelated profile data out of the suppression record when it is no longer needed.

Delivery-provider suppression and workspace-level marketing suppression solve related but different problems. Provider suppression may stop a hard bounce or complaint at delivery time. Campaign eligibility should also exclude unsubscribe and permission states before a message is prepared or scheduled.

Require evidence for any later resubscription

A new CSV row, CRM update, or integration event should not automatically resubscribe a blocked address. Define the events your policy accepts as new permission, such as a completed signup form tied to the relevant subscription type with a timestamp and source.

Route ambiguous changes to review. Preserve the old blocked observation beside the newer permission evidence so the decision remains auditable. If the message purpose changed materially, confirm that the new permission actually covers it rather than assuming a prior customer relationship is enough.

Run a dry-run audience reconciliation

Before saving or sending, compare source totals with the proposed result: unique contacts, sendable, unsubscribed, non-subscribed, bounced or cleaned, complained, invalid, and conflicting. Sample addresses from every path, including contacts present in both active and blocked files.

Generate a downloadable review that records accepted and excluded rows without exposing unnecessary contact data. The campaign owner should approve the final eligible count and the reason each exclusion category exists before content is connected to the audience.

1. Upload all related provider exports together.
2. Review file recognition, duplicates, conflicts, and final statuses.
3. Inspect representative sendable and blocked contacts.
4. Confirm the campaign uses only the reconciled eligible audience.
5. Save the migration review with the cutover record.

Use resumable jobs and a rollback boundary

Large migrations should continue after the browser closes and should never depend on one oversized request. AttuneMail stores bounded import chunks, processes one chunk at a time, reports progress and per-object results, and lets an operator retry failed work from Import history.

Rollback should also be conservative. An import can remove the list, associations, and otherwise-unused records it created and restore records that have not changed since completion. It should retain records edited or used after the migration, and it should never erase suppression history. Download the result report before cutover so accepted, invalid, duplicate, created, updated, sendable, and blocked counts remain auditable.

Preserve relationships and future consent collection

When the old platform also owns CRM data, migrate companies, contacts, and deals as related objects rather than flattening every relationship into contact columns. Match company references by normalized domain or name and deal contacts by email, then inspect the recreated associations. Contacts without documented campaign permission can still move into the CRM, but they should remain pending and excluded from campaign sends.

Cutover is not complete when the historical list is safe. Rebuild subscription capture too. A replacement form can hold new contacts pending until they click a time-limited confirmation email, add them to the intended list only after confirmation, and preserve a campaign-email preference that recipients can later disable or re-enable. Complaint and bounce blocks must remain stronger than preference changes.

1. Import companies before their related contacts and deals.
2. Review association totals and sample both linked and unlinked records.
3. Leave CRM-only contacts pending unless permission evidence is documented.
4. Enable double opt-in where your policy or risk level requires address confirmation.
5. Test the confirmation, preference, unsubscribe, complaint, and bounce paths before launch.

Prove the first send and the paths that stop sending

Use an internal seed, then a small engaged segment. Verify the sending domain, From address, links, reply routing, visible unsubscribe, one-click unsubscribe where required, bounce and complaint processing, and the immediate eligibility change after an opt-out.

Keep the old sender active only for the short proof window, and prevent overlapping campaigns from both platforms. After the new path is proven, stop old sends, retain the export archive, and monitor unexpected eligibility changes, complaints, and bounce patterns during the first production campaigns.