ESP Migration Guide: Announce a Price Increase

Do not index

A marketing lead has a platform cutover on the calendar and a price increase that must be announced in the same quarter. The two deadlines may look like separate projects, but they rely on the same audience data, sending identity, and reputation. Treating the announcement as just another campaign can put an already delicate ESP migration at risk.

Table of Contents

Why an ESP Migration and a Price Increase Collide What to Audit Before You Touch Anything Map streams, systems, and baselines Prove suppression parity DNS and Authentication Changes for the New ESP Validate the received message, not just the dashboard Choosing Between a Shared and Dedicated IP Phasing Volume and Running Both ESPs in Parallel Announcing the Price Increase Without Losing Subscribers What to Monitor in the First 30 Days Build a receiver-level scorecard Common mistakes FAQ When should the price announcement go out?Can both ESPs send during the transition?What should trigger a pause in the ramp?Is a successful import enough to call the migration complete?

Why an ESP Migration and a Price Increase Collide

A price change can prompt customers to unsubscribe or complain. Those responses are a normal part of a sensitive announcement, but mailbox providers also use complaint signals when deciding how to handle future mail. If the announcement goes out from a new platform before its authentication and sending reputation are established, a difficult message is landing on an unproven route.

Both projects depend on the same fragile assets: suppression data, engagement history, authentication, and sender reputation. The migration decides which people can be mailed and from which systems. The announcement tests whether those decisions work, because it reaches customers who may react differently from a routine campaign.

The risk often comes from a detail that seems administrative. Unsubscribes, hard bounces, or complaints can exist only in the old ESP and fail to make it into the new one. Or the new DKIM key may be published while DMARC alignment goes untested, or the old ESP's SPF authorization may be removed while it still sends transactional messages. In each case, the new setup can look ready while the actual sending path is not.

A migration deserves a schedule of its own. A 2018 Litmus survey found that more than 28% of brands had switched or dropped an ESP during 2017, and over 16% named switching ESPs a top email-marketing priority for 2018. Its guidance estimated that a straightforward move could take approximately three months, with more complex programs taking longer (Litmus guidance on switching ESPs). That's a useful reminder for anyone planning a move next quarter: leave room for inventory, testing, a phased cutover, and the price announcement. Don't stack the announcement on top of the cutover just because both deadlines fall in the same period.

What to Audit Before You Touch Anything

Start with the live sending operation, not the contact export. Record what sends today, how each stream is authenticated, which systems feed it, and what “normal” looks like before traffic moves. Without a baseline, a post-cutover change in complaints or deferrals can be hard to diagnose.

Map streams, systems, and baselines

Inventory every sending stream, domain and subdomain, IP, bounce domain, tracking domain, automation, webhook, and integration. Separate marketing from transactional mail, and document which system owns each stream. Also record provider-level baselines for hard bounces, complaints, deferrals, and inbox placement, so the team can distinguish a migration issue from normal variation.

Export campaign and domain-level engagement history, including event timestamps, consent records, and bounce and complaint status. Group engagement into useful bands, such as recent clickers, recent openers, recent buyers, and older or inactive contacts. Keep the source and date logic clear. If one system records a date in a different time zone or a field changes meaning during import, lifecycle segments may behave differently after launch.

Prove suppression parity

The most consequential migration gap is often not a missing contact. It's a missing reason not to mail that contact. Export unsubscribes, hard bounces, complaints, and other suppressions before importing active contacts. Reconcile global unsubscribes against campaign-level opt-outs, and define which system is authoritative if the ESP and CRM disagree.

Before the first send, compare the old and new suppression sets and verify that the new platform excludes the same people. Preserve consent status and event timing, not just a simple subscribed flag. A migration that looks complete but loses this logic can generate complaints, damage trust, and create compliance problems. A smaller, behaviorally qualified first audience is often safer than importing every record and treating them all as send-ready. For a focused cleanup, use this guide to reduce email bounce rate.

DNS and Authentication Changes for the New ESP

A familiar From address doesn't mean mail follows the same authentication path after a move. The sending provider, DKIM signing domain, return path, and IP can all change, so validate the new route before production traffic moves.

Validate the received message, not just the dashboard

Authorize the new sender in SPF, publish the new DKIM keys, and confirm that DMARC aligns with the visible From domain. Set up the custom return-path and tracking domains, and verify forward and reverse DNS for the sending domain or IP where applicable. Don't create a second SPF record; combine authorized senders carefully and stay within SPF's DNS-lookup limit.

A green status in the ESP is not proof that a receiving system sees the message as intended. Send authenticated tests to representative inboxes and inspect the received message's Authentication-Results header, including SPF and DKIM results and whether DMARC passes through alignment. Check the links, reply handling, unsubscribe behavior, and event processing too. For a closer review of the authentication workstream, see email authentication guidance.

Gmail's bulk-sender requirements apply to senders delivering approximately 5,000 or more messages to personal Gmail accounts within a 24-hour period. Those senders need SPF and DKIM, a published DMARC policy, valid forward and reverse DNS, TLS, and a spam rate below 0.30% in Postmaster Tools (Gmail sender requirements). Check the new sending path against the mailbox provider's requirements that apply to the program, rather than assuming the old setup's passing status carries over.

Lower DNS TTL before a planned change if it helps shorten propagation, but don't treat that as a substitute for a rollback plan. Keep the old ESP's SPF authorization and authentication active while it still sends mail, including transactional messages. For a useful companion on practical deliverability decisions, see deliverability guidance for growth teams. When the actual records need checking, our sister tool mailX offers a DMARC checker.

Choosing Between a Shared and Dedicated IP

The IP decision should follow the sending pattern, not a default preference for control. A dedicated IP gives the sender more direct responsibility for its own reputation, but that control comes with a requirement for consistent, well-managed traffic. A shared pool may suit a program with modest or uneven volume, but the sender has less control over the reputation environment.

Sending setup	Better fit when	Main trade-off
Shared IP	Volume is modest or changes with campaign demand	Less direct control over the pool's sending environment
Dedicated IP	Volume is steady and the team can manage reputation closely	The sender owns the responsibility of establishing and maintaining its reputation

A dedicated IP is not an automatic deliverability upgrade. If volume is inconsistent, or the first important send is a price increase likely to produce complaints, a new dedicated IP may be a poor place to start. The sender has less established history, and an abrupt high-volume campaign can make it harder to tell whether the problem is audience reaction, authentication, or the new route.

A shared pool can reduce the burden of establishing an IP reputation independently, but it doesn't remove the need for healthy lists and careful targeting. Decide before writing the ramp plan, because IP choice affects how traffic should be introduced. IP warmup is a related workstream, but it shouldn't replace a migration plan; the domain warmup guide covers that topic separately.

Phasing Volume and Running Both ESPs in Parallel

A phased move gives the team time to see how receiving systems respond before more mail is exposed to the new route. Run both ESPs in parallel during the transition, with a clear map of which streams and automations remain on each platform. That overlap reduces the risk of breaking active journeys or losing delayed messages in a hard cutover.

A practical sequence is:

Start with the strongest engagement. Send first to recent clickers and buyers, then recent openers. These groups are more likely to recognize the sender and engage.

Review before expanding. Check hard bounces, complaints, and temporary deferrals from Gmail, Microsoft, and Yahoo. A rise in deferrals or complaints is a reason to hold or step back, not to press ahead.

Add older engagement bands gradually. Expand only when the signals remain stable across several consecutive sends. Don't add multiple new segments at once if that makes a change hard to trace.

Move each stream deliberately. Record whether marketing, transactional, and automated mail are still sending through the old ESP or have moved. Keep authentication active for both paths for as long as both send.

Retire the old system only after reconciliation. Confirm delayed mail has completed, automations are working on the new platform, and suppression updates are synchronized before decommissioning the old configuration.

Industry migration guidance recommends overlapping providers, routing engaged recipients first, and moving volume progressively rather than flipping all traffic at once; its suggested ramp spans roughly two to six weeks, with the old configuration retained until delayed mail, automations, and suppression synchronization are confirmed (migration cutover guidance). The right pace depends on the program's signals, not a calendar promise. Teams that move everything in one send can see a temporary inbox-placement drop and more deferrals, while a phased move gives them room to identify and correct problems.

Keep the price announcement out of the initial test sends. First establish that the new route handles ordinary, well-qualified traffic and that its measurement is trustworthy. For ecommerce teams reviewing adjacent changes to the customer messaging mix, compare Shopify SMS platforms without confusing that evaluation with the email cutover. A migration-focused warmup plan should support the traffic schedule, not dictate it.

Announcing the Price Increase Without Losing Subscribers

The price announcement should reach the right audience from a proven sending path. Don't make it the first campaign on the new ESP: a message that may prompt complaints is a poor test of authentication, audience mapping, or unsubscribe processing.

Start with segments based on consent and behavior. Exclude suppressed recipients, people with unresolved consent status, and inactive contacts who aren't appropriate for the announcement. Then decide who needs the earliest and clearest notice. Loyal, recently active customers can receive a direct explanation and a clear effective date. Mid-engagement subscribers may need more context about what is changing and where to find account details. At-risk accounts deserve a careful, service-oriented message, not repeated promotional pressure.

Audience band	Notice period	Message angle	Deliverability risk
Loyal, highly engaged customers	Give clear advance notice	Explain the change, effective date, and available account options	Lower relative risk, but complaints remain possible
Mid-engagement subscribers	Provide clear notice before the change takes effect	State what changes and where to review details	Moderate risk if the message feels unexpected
At-risk accounts	Send only where consent and account context support it	Keep the message useful, direct, and easy to act on	Higher risk if the audience is stale or poorly qualified

Use a subject line that identifies the topic plainly, such as “An update to your subscription price” or “Your plan price is changing.” Avoid urgency or vague promotional wording that obscures the message's purpose. B2B customers often need the effective date and billing impact stated precisely; ecommerce subscribers may respond better to a concise explanation tied to their existing subscription or order history. In either case, the sender name should be recognizable and the message should make the next step clear.

Keep the unsubscribe mechanism functional and easy to find. For high-volume sending, Gmail and Yahoo's bulk-sender rules include one-click unsubscribe requirements and a spam-complaint rate kept under 0.3%, ideally under 0.1% (Gmail sender requirements). The mechanism matters especially on a price announcement because hiding it can turn an opt-out into a complaint. Teams planning how to listen to customers through a subscription change can also review customer feedback on subscription changes. Align the announcement's timing and audience logic with the broader email strategy.

What to Monitor in the First 30 Days

A healthy-looking ESP dashboard doesn't prove that receiving systems are accepting and placing mail as intended. Evaluate the move by provider, stream, and audience segment. That lets the team distinguish a Gmail-specific deferral from a campaign-wide issue, or a transactional problem from a marketing one.

Build a receiver-level scorecard

Track the following daily during the first month, and compare like with like against the pre-migration baseline:

Delivery response: Record hard bounces and temporary deferrals, including the full SMTP response. A deferral is not the same as a permanent failure; repeated temporary responses can point to rate, reputation, or policy problems that need investigation.

Complaint signals: Watch complaints by provider and stream. Gmail's bulk-sender rules specify a spam-rate ceiling below 0.30% and recommend keeping the rate below 0.10% (Gmail sender requirements). Treat an approaching ceiling as a reason to pause expansion and investigate audience and message fit.

Authentication and alignment: Inspect received-message headers for SPF, DKIM, and DMARC results. A passing authentication check without alignment may still leave the visible From identity unverified for DMARC.

Placement and provider reputation: Review provider-level inbox and spam placement where measurement is available. Check Google Postmaster Tools for Gmail signals and SNDS for Microsoft sending activity; neither should be replaced by the ESP's aggregate delivery status.

Unsubscribe processing: Confirm that requests register promptly and suppress future sends across the systems that can mail the same person. A working footer link isn't enough if a connected automation can still send from another platform.

When one provider diverges, don't pause every stream by reflex or continue ramping because the overall dashboard looks fine. Compare the affected provider's deferrals, authentication results, complaint signals, and message headers with the other destinations. Then hold the affected stream or segment while the owner tests the sending path and audience logic. A provider-specific failure needs a provider-specific diagnosis.

Common mistakes

Removing the old SPF authorization too early. Transactional messages still using the old ESP may fail authentication. Keep the old sender authorized until it has stopped sending.

Importing contacts without suppressions. Previously unsubscribed or complaining recipients may be mailed again. Verify suppression parity before activating any campaign.

Trusting a dashboard instead of a received message. Misaligned DKIM or a changed return path can escape a basic setup check. Inspect headers and confirm alignment through the actual receiving route.

Sending the price increase first. A complaint-prone campaign makes a poor first test of an unfamiliar platform. Establish stable performance with qualified segments before scheduling the announcement.

Declaring success because opens look unchanged. Open activity alone doesn't reveal provider-specific deferrals, spam placement, or broken unsubscribe processing. Judge the move on the full receiver-level scorecard.

A migration is successful only when provider-specific delivery outcomes and compliance signals remain stable after traffic moves. If the team has no clear owner, faces repeated incidents, sees provider blocks or persistent deferrals, or must coordinate the migration with a price change without reliable monitoring, an outside expert can help diagnose the route and agree on safe next steps. For a deeper look at the provider-level view, see this guide to ESP migration deliverability.

FAQ

When should the price announcement go out?

Send it after the new route has demonstrated stable performance with qualified recipients, not as its first campaign. Confirm that suppression handling, authentication alignment, and unsubscribe processing work before announcing the change. If those checks aren't complete, delay the announcement rather than asking a sensitive message to double as a migration test.

Can both ESPs send during the transition?

Yes, if the team has a clear map of which streams remain on each system and keeps authentication and suppression data current for both. Parallel operation can protect live automations and help isolate problems, but it also creates risk of duplicate sends or conflicting audience states. Reconcile ownership and suppressions before either system sends to shared segments.

What should trigger a pause in the ramp?

A rise in hard bounces, complaints, or temporary deferrals is a reason to stop increasing volume and investigate. Compare the affected stream and mailbox provider with the baseline, inspect received-message headers, and check whether the audience or sending path changed. If the signals persist, step back to the last stable segment while the cause is addressed.

Is a successful import enough to call the migration complete?

No. A file import doesn't prove that engagement history, consent, event timing, or suppression logic survived the move. Test representative contact records and live behaviors, including unsubscribe processing and automation entry rules. The migration is complete when the sending systems behave correctly and provider-level outcomes remain stable after traffic moves.

MailAdept assigns a dedicated deliverability expert to audit a setup, fix issues, and monitor domains with 12+ daily checks per domain and a weekly expert review. Calls with experts are included in every plan, and the process starts with a free audit.

Want a second pair of eyes on the authentication, suppression, and ramp plan before the announcement goes out? MailAdept can review the migration and help identify deliverability issues that need attention before traffic moves.