WORKFLOWS

Switching warmup tools without losing your history

Illustration: a person carries a box of letters and a notebook across a paper bridge between two small stoves, leaving a key back on a hook
Illustration generated by AI.
The short answer

Almost nothing moves with you. The warming schedule, the peer network and the tool's own charts stay behind; what you keep is your domain, your mailboxes, your authentication records and whatever you exported before cancelling. So the switch is an access and evidence exercise, not a data migration. Export first, overlap briefly, revoke deliberately, and do not read the weeks either side as a before and after.

What actually moves, and what stays behind

Vendors talk about warmup as if it built something inside their product. Some of it does live there, and that part is not portable. Sort the two columns before you plan anything, because the plan depends on which column your reasons are in.

Yours, and unaffected by the switch

  • The domain and its sending subdomains
  • SPF, DKIM and DMARC records, which live in your DNS
  • The mailboxes themselves, at Google or Microsoft
  • Whatever history your sending platform holds: sends, bounces, complaints, unsubscribes
  • Any export you took before the old account closed

Left behind with the old tool

  • The warming schedule and its ramp, which the new tool restarts on its own terms
  • The peer network your mailboxes were exchanging with
  • The tool's dashboards, scores and charts, including any figure you quoted to a client
  • Test credits you already paid for and did not use
  • Any placement report you can no longer open once the login is gone
There is no warmup reputation file to hand over. Mailbox providers form their own view of your domain from what they observe, and no vendor can transfer it. A tool that offers to carry your warmup progress across is describing its own database, not anything at Google or Microsoft.

The practical consequence: expect the new tool to start its own ramp from the beginning, and budget for that period rather than being surprised by it.

Before you cancel anything, write the inventory

Do this while you still have the old login. It takes twenty minutes and it is the difference between a switch and an incident. One row per mailbox.

  1. Mailbox address and provider. Google Workspace, Microsoft 365 or other, and which sending domain or subdomain it belongs to.
  2. How the old tool connects. OAuth grant, app password, or SMTP and IMAP credentials. This is what you will have to revoke, and it is different in each case.
  3. Who owns the account. You, or the client. If it is the client's, the revocation is theirs to perform or to authorise in writing.
  4. What the subscription costs and when it renews. Per mailbox lines renew silently, and a mailbox you stopped using still bills.
  5. Unused credits. Spam or placement test credits that expire with the account.
  6. Exports you still need. See the export section below, and do it before the cancellation date, not after.

The billing line is the one people get wrong. A tool priced per mailbox, such as MailReach or Warmup Inbox, stops charging for a mailbox you remove, so the inventory and the invoice should agree at every step of the switch. A tool where warmup is bundled into a sending plan, such as Instantly, charges the same whether you warm one mailbox or twenty, so removing mailboxes saves nothing and the only saving is cancelling the plan. Know which of the two you are leaving before you write the client a number.

Keep this inventory after the switch. It becomes the access ledger in your client report, which is the section clients actually ask about. The format is in the client reporting template.

The order of operations

The sequence below has one purpose: never leave a mailbox connected to two warming systems for longer than necessary, and never leave a period where you cannot say what was running. Days are relative, and the plan below is fictional and written for this guide.

Switch plan, six mailboxes

Sample plan · fictional data
One period, one change per line. Any reading taken during days 1 to 14 cannot be attributed to either tool.
DayActionWhy this order
0Inventory written, exports taken from the old toolExports are unavailable once the account lapses
0Authentication checked per sending domain: SPF, DKIM, DMARCA configuration fault will otherwise be blamed on the switch
1New tool connected on two mailboxes onlyProves the connection method is allowed before you commit the rest
1Old tool left running on the same two mailboxesNo warming gap while the new connection is validated
4Old tool switched off on those two mailboxes, access revokedEnds the double warming window deliberately, on a date you can name
7Remaining four mailboxes moved the same wayStaggered, so a failure affects two mailboxes and not six
14Old subscription cancelled, renewal date confirmed in writingCancellation after revocation, never before
14Change log line written for the client fileThe period is now explainable three months later

Two rules hold the whole sequence together. Revoke before you cancel, because a cancelled account can leave a live OAuth grant or app password behind, and you no longer have a console to remove it from. And change one thing at a time: if you also move sending platform, rewrite the copy or raise daily volume in the same fortnight, you have given up on interpreting anything that follows.

Revoking the old tool's access, properly

Cancelling a subscription is a billing act. Revoking access is a security act. They are not the same, and only the second one removes the tool's ability to reach the mailbox.

Google Workspace and Gmail

If the tool connected with an app password, remove it from the account's app passwords list. Google states that to create one you need 2-Step Verification on your Google Account, that app passwords are not available for work, school or other organization accounts, for accounts using security keys only, or for accounts on Advanced Protection, and that once revoked the app can't access your Google Account again (Google Account Help, sign in with app passwords, checked ). If the tool connected with OAuth, remove it from the account's third party access list instead (Google Account Help, third party access).

Microsoft 365 and Exchange Online

Access for SMTP client submission is controlled per mailbox and organization wide. Microsoft recommends disabling SMTP AUTH across the organization and enabling it only on the mailboxes that require it, and the per mailbox setting overrides the tenant setting. The mailbox toggle is Authenticated SMTP under Users, Active users, Mail, Manage email apps, or Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true in Exchange Online PowerShell. Microsoft also notes that if security defaults is enabled in the organization, SMTP AUTH is already disabled (Microsoft Learn, Enable or disable SMTP AUTH in Exchange Online, checked ).

Then verify, do not assume. Re-open the app passwords list, the third party access list or the mailbox setting after the change and read it back. A revocation you did not verify is a revocation you are guessing about, and it is the line a client is most entitled to ask you to prove.

Record each revocation with its date and the person who performed it. If the mailbox belongs to a client, that record is the evidence that their credentials are no longer reachable by a vendor they stopped paying.

What to export before the account closes

Export while the subscription is live. Most of this is unavailable a day after it lapses, and none of it is worth paying another month to retrieve later.

  • Placement or spam test reports you have quoted to anyone, as files rather than links. A link into a dead account proves nothing.
  • The list of connected mailboxes with connection dates, which is the backbone of your revocation checklist.
  • Invoices for the period, so the spend section of the client report matches reality.
  • Any authentication findings the tool surfaced, so you can re-check them yourself rather than take them on trust.
  • Settings you deliberately chose, such as daily volume caps, so the new tool can be set up to match rather than to guess.

What you should not bother exporting: scores, grades and health percentages. They are internal to the product you are leaving, they have no shared definition, and they cannot be compared with anything the new tool will show you. Carrying them into a client report invites exactly the comparison that is not valid.

If the tool offers no export at all, that is a finding worth writing down for the next purchase decision. Ask the new vendor what you can take with you before you subscribe, and keep the reply.

Reading the weeks after the switch without fooling yourself

This is where switches produce bad reports. You changed tools, something moved in the numbers, and the story writes itself. Resist it, because the switch fortnight contains several changes at once and a warming ramp that restarted.

Defensible after a switch

  • Dates: what was connected, when, and when the old access was revoked
  • Authentication status per sending domain, observed before and after
  • Bounce, complaint and unsubscribe figures from your own sending platform
  • Placement observations, with the instrument, the seed count and the folder split written out
  • Spend, including the overlap period when you paid twice

Not defensible after a switch

  • The new tool improved our deliverability
  • A comparison of the old tool's score with the new tool's score
  • Any percentage that crosses the overlap window
  • A forecast of what next month will look like
  • A guarantee of inbox placement, from any tool, ever

If you genuinely want to know whether the new tool does anything for you, a switch is the wrong experiment. Keep a hold-out group instead: some mailboxes on the new tool, comparable mailboxes on nothing, everything else held still, read with one instrument. That design is set out in the warmup pilot protocol, and reading the instrument correctly is covered in how to read an inbox placement test.

Questions people also ask

Will I lose my warmup progress if I switch tools?

You lose the tool's record of it, which is not the same thing. Mailbox providers form their own view of your sending from what they observe, and that is unaffected by which vendor you pay. What restarts is the new tool's ramp, which typically begins at a low daily volume and builds. Plan for that period rather than treating it as damage.

Can I run two warmup tools on the same mailbox at once?

Briefly, to avoid a gap while you validate the new connection, and with the dates written down. Do not leave it running: two systems sending and filing warming mail on one mailbox raises the volume in ways neither tool accounts for, and it makes any reading from that period uninterpretable. A few days is a transition; a few weeks is a mess you will have to explain.

Do I have to cancel before I revoke access?

The other way round. Revoke the mailbox access first, verify it by re-reading the app passwords list, the third party access list or the Authenticated SMTP setting, then cancel the subscription. A cancelled account can leave a live credential behind, and at that point you no longer have a vendor console to remove it from.

What do I tell a client about the switch?

The dates, the reason for the change, what was exported, when the old tool's access was revoked and by whom, and the fact that readings either side of the switch are not comparable. That last sentence protects you more than any chart. Put it in the change log section of the client report rather than in a covering email that nobody keeps.