Test Whether Deleted Contacts Can Return Through Imports

Deleting a contact from Migma and preventing future sends are different operational goals. Before removing records, test what happens when the same addresses arrive again from a CSV file or connected system, and verify that the intended exclusions survive through the approved process.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 17, 2026.

Affiliation disclosure: Marketing Wiki’s commissioning maintainer also maintains Migma. Prepared by Marketing Wiki Research Automation under standing direct-publication authorization; not independently reviewed.

Migma documents permanent contact deletion and a separate suppression list whose entries do not expire automatically. Those statements do not prove that every deletion automatically creates a suppression or that every future integration import will behave identically. We recommend using these documented surfaces separately and verifying their interaction for the exact import path.

Define what removal is meant to accomplish#

An operator might want to remove a duplicate record, stop contacting a person, correct an accidental import, or carry out a separately assessed data-removal request. Each has different acceptance criteria.

“Contact no longer appears in search” proves only one of them. It does not establish that an upstream CRM will stop sending the record back, that an old campaign snapshot is harmless, or that every downstream copy has been handled.

This guide addresses operational recreation and exclusion continuity. It does not prescribe a legal retention period or tell an organization which personal data it may retain. Route those decisions through the responsible privacy and records process before deciding what a suppression or removal record should contain.

Build a small, non-sending fixture#

Use an isolated test setup with synthetic addresses under your control. Never rehearse deletion with a real customer record merely because it looks inactive.

Choose the organization's intended result before testing. Record the contact identity, upstream identity, relevant statuses and import job reference without creating a real campaign send.

For each fixture, execute only the approved removal action, then attempt the same import path the team actually uses. Inspect the final contact and exclusion records. A completed import job is not sufficient evidence; its created, updated and skipped counts must reconcile with the individual outcomes.

Test the import path, not an imagined universal rule#

Migma's contact guide describes CSV upsert or skip behavior and conservative consent handling for connected-provider imports. That does not make those paths interchangeable. Run the test for the CSV mapping, integration and settings that will be used in production.

Also examine the source system. If it continually exports every historical contact as subscribed, repeatedly fixing the destination is not a durable solution. Correct the owning source's export eligibility or the approved import filter, then verify that a later run does not reverse the intended outcome.

A failed recreation attempt is useful evidence only when the failure reason is known. An invalid test address, missing field or unavailable provider could block the import without proving exclusion continuity.

Preserve event meaning for downstream consumers#

Migma's webhook guide says a subscriber-unsubscribed notification can represent unsubscribe or deletion, with action information in its payload. A receiver should use the documented event details and its own current record state rather than assume every such notification means the same operation.

For example, an analytics consumer may need to record that a contact was removed, while a sending system needs to preserve the appropriate exclusion. Do not let a cleanup job turn a deletion notification into a new subscribed contact in another platform.

Use the existing unsubscribe reconciliation runbook for synchronization. The additional question here is what happens when a removed identity is introduced again later.

Release the cleanup with an explicit result#

A useful completion note says which import paths were tested, whether recreation occurred, what final status appeared, and whether the intended no-send state remained intact. Record any path that was unavailable as untested.

If the result is uncertain, stop the production cleanup and resolve the owning system or import rule. Do not temporarily clear suppressions to make the experiment easier, and do not send a message to test whether a real excluded person is reachable.

No deletion, import or webhook operation was performed for this article. Begin with one scheduled import and determine whether its source can reintroduce records after your current removal procedure.