Move an Outbound Campaign Without Replaying Its Follow-Ups

Imagine moving a campaign on a Thursday afternoon. The contacts import successfully, the sending mailboxes connect, and the new tool is ready to run. One contact has already received the second message, but the imported record starts them at the first step. Another has a follow-up waiting in the old tool.

Those are the records I would inspect before approving the move. A migration needs to account for work already done and work still capable of happening. A successful contact import answers neither question by itself.

The process below is a proposed acceptance check for an outbound campaign migration. It is not a description of built-in Mailrun controls or a promise that every sequencer exposes the same information. If your tools cannot show a required state, keep the affected work on hold while the owner resolves it.

Find Everything That Can Still Send

Start with the person responsible for the current campaign. Ask them to identify every place a message can be waiting: a scheduled sequence step, an application retry, or a submission already handed to the sending provider. Ask what the campaign's pause control actually stops and what continues after it is used.

There is a protocol reason to distinguish those stages. An SMTP server's positive completion reply after the message data means it has accepted responsibility for delivery or relay. That is not confirmation that the message reached the inbox. RFC 5321 also describes duplicate-mail risk when a timeout leaves the sender without the acknowledgment it expected. RFC 5321, Section 6.1

For a sending API, verify the provider's documented acceptance and retry behavior separately. Do not translate an application label such as “sent” into a stronger delivery claim, or treat a timeout as proof that no submission occurred.

Choose a cutover time with an explicit timezone. Record who will stop new submissions from the old campaign, inspect outstanding work, and authorize the new campaign. I would require one person to own that release decision even when several people perform the checks.

Carry the Send Decision With the Contact

For each contact, retain the campaign and step, assigned sending mailbox, last confirmed submission, next eligible action, and any reason to stop. Include the relevant timestamps and the records supporting that decision. Store exports where the migration team is authorized to access them; use synthetic contacts in shared test reports.

Group unfinished work by what the evidence establishes:

These categories are migration decisions, not standardized status names. Document how each tool's fields map into them. If two exports disagree, retain the disagreement for review instead of choosing whichever value makes the import easier.

Keep source identifiers where available, but do not assume the destination interprets them the same way. RFC 5322 defines Message-ID as an identifier for a particular version of a message. In-Reply-To and References describe message relationships. Those fields do not establish a sequencer's rules for recognizing work it has already performed. RFC 5322, Section 3.6.4

Ask the implementer to show how one source campaign step maps to one destination action. Changing the campaign name should not be enough to turn an already submitted follow-up into a new task.

Account for Replies That Arrive During the Move

A cutover timestamp does not stop incoming mail. Decide who watches the original mailboxes while records are transferred, and how a new reply or opt-out changes the destination record before it sends.

For a controlled test contact, arrange a reply after the export but before the new campaign is released. Confirm that the reply reaches the responsible person and stops the follow-up under your campaign's rules. Repeat with an opt-out. Record the scope of the stop decision so that an import does not silently narrow it.

The protocol and end-to-end opt-out checks are covered in Test Your Unsubscribe Path Before the Next Outbound Campaign. During migration, the extra question is whether a decision recorded after the initial export reaches the system that will make the next send decision.

Set a final reconciliation checkpoint before release. If replies or suppression updates are still being processed, leave the affected contacts paused. A count of imported rows cannot demonstrate that those later events were applied.

Keep that handling in place after the new campaign starts. A recipient can still reply to an earlier message or use the unsubscribe link it contained. Before retiring the old tool, verify that those reply threads and opt-out routes still reach the person or system responsible for the next send. Test an old message's link and a reply to its thread after the move, using controlled records. If an old route depends on the former tool, assign an owner to keep it working or arrange a verified replacement; disabling the old campaign's sending must not silently disable its incoming stop requests.

Rehearse the Move With Work You Can Trace

Use invented correspondence and accounts your team controls or has explicit permission to test. Include a contact waiting for a first message, one waiting for a later step, one that has replied, one that has opted out, and one with an uncertain submission result represented in the test data. Do not manufacture uncertainty by interrupting a live customer's send.

Walk those records through the same export, mapping, import, and release process planned for the campaign. Check both tools afterward. For eligible work, inspect the intended step, mailbox, and send window. For held or stopped work, verify that it cannot submit from either tool during the defined observation window.

Before any controlled send, set a bounded send allowance and a way to stop the test. Keep the resulting submission records so that another operator can follow what happened. One received message does not prove there are no more queued copies; include outstanding work in the check.

Rehearse a rollback too. If the new tool submits a message before the team decides to return to the old one, the old record needs that history before it resumes. Re-enabling the original campaign without reconciling activity since cutover could repeat the same step. Apply the same holds to unresolved outcomes in either direction.

Before the old campaign resumes, verify that queued work and retries in the new tool can no longer submit the steps being returned. Include already accepted provider work in that reconciliation, just as you did on the first move.

Release the Campaign With an Exception List

Before restarting production, name the tool that now owns each active step and record what remains held. Assign an owner and a next review action to every exception. If the tools cannot prevent both sides from submitting the same work, the migration is not ready for release under this process.

Keep the old records available for authorized reconciliation without leaving the old campaign free to send. Agree on their retention and access with the responsible team rather than leaving an unattended copy behind.

For the first portion of resumed work, review submission records and new replies against the migration plan. The useful evidence is a contact whose next action can be explained: this step already happened, this one is eligible, or this one is still held for a specific reason. That is what I would want the team to demonstrate before widening the release.