ComparisonsBuying Guides

Migrating Off Mailchimp: A 2026 Plan

Intuit split Mailchimp into its own reportable segment. Here is the migration plan for remote teams: four triggers, a two-axis pick, a segmented move, and a two-week dual run.

Disclosure: This post contains affiliate links. If you make a purchase or sign up for a paid plan through these links, I may earn a small commission at no extra cost to you.

The Vendor Just Sent You the Signal

I have built newsletters, welcome flows, and launch sequences for more than a dozen remote teams since 2018, and the most common thing I find when I get called in is that the team has been quietly growing out of its platform for two years without noticing.

Mailchimp’s free plan is capped at 250 contacts and 6,000 emails per month, according to its own pricing page. Its Essentials tier starts around $13 a month at 500 contacts, and Standard starts at $20 a month. I have pulled up more than four or five accounts where the contact count sat well above 250 and the owner still believed they were on the free tier. Billing labels change, contact counts do not.

This year there is a second reason to look. On Intuit’s fiscal 2026 fourth-quarter earnings call, the company announced that Mailchimp will become a separate reportable segment starting in fiscal 2027. Intuit reported full-year revenue growth of 14% and said its Big Bets grew 34% and now account for 30% of revenue, with 8.9 million online paying customers up 3%. The implication is straightforward: a parent that is growing fast at the top line and carves one business into its own segment is preparing that business to be evaluated, sold, or underfunded.

Segmentation is the clearest supplier-risk signal you can receive, because it is coming from the vendor. Reported separately, decided on separately, and therefore funded on separately.

The Four Triggers Worth Acting On

Do not wait for a price increase to justify a move. Check these four conditions each quarter and act when one of them fires.

  1. Pricing page changed. Tiers renamed, contact limits lowered, or features moved between tiers. The most insidious version is a tier rename that leaves you on a plan that costs more than the last quote you saw.
  2. Feature downgraded. Automations, segmentation, or reporting removed from the tier you are on. Note that several independent review sites report automation was removed from Mailchimp’s free plan in January 2026 and that legacy accounts received notice of an 11 to 13% increase. Those figures come from independent review outlets rather than from Intuit, so treat them as reported rather than confirmed, but do treat them as a reason to re-check your own account settings.
  3. Corporate strategy shifted. A segment spin-off, a divestiture, or sustained underinvestment. This is the Intuit signal and it is the one most likely to compound over the next year.
  4. Renewal jumped. A renewal quote that lands materially above your last invoice, with no change in your contact volume.

I see trigger one and trigger two fire first, almost every time. Trigger three is the reason you should not wait for trigger four.

Picking the Replacement on Two Axes

Do not compare features. Compare two things: automation depth and cost per contact. Automation depth is how far a triggered flow can branch, how many behavioral events you can key off, and whether the automation survives a tier change. Cost per contact is what a thousand contacts actually costs you, not the entry price on the pricing page.

PlatformPositionAutomation depthStrengthWeaknessBest remote fit
MailchimpEstablished, growingMedium, tier-dependentTemplates and drag-and-drop are the fastest to learnFree plan capped at 250 contacts, automation value shifts between tiers, segment spin-off riskTeams under 1,000 contacts who prioritize setup speed
BrevoBudget, growingMedium to highLarge free tier and an unusually flat entry curveAnalytics and deliverability tools lag the larger suitesBootstrapped teams scaling from hundreds to tens of thousands
MailerLiteBudget newsletterMediumVery clean automation builder at low volumeLess suited to CRM-adjacent workflowsSolo founders and sub-5,000-contact newsletters
KlaviyoPremium ecommerceHighDeepest behavioral triggers and predictive segmentsPriced for ecommerce conversion, not newsletter economicsEcommerce brands where email drives revenue directly
Customer.ioUsage-priced, premiumHighestFully programmatic, event-based flows for product teamsPer-event pricing is hard to budget for a pure newsletterProduct-led teams sending triggered in-app plus email
EngageBayBudget suiteMediumBundles CRM, landing pages, and helpdesk in one contractSmaller ecosystem of native integrationsRemote teams that want one vendor for CRM and email

The reason I put this table here is that most migration mistakes happen before a contract is signed. A team picks the platform with the lowest entry price, moves 12,000 contacts, and discovers at month three that its welcome sequence needs a branching rule that tier does not include. Depth is not a nice-to-have in a migration. It is the reason you got here.

Freezing and Cleaning Before You Move Anything

The list you export on day one will not be the list you want on day 30. Freezing first is what makes the cleanup honest.

Stop new sign-ups for the duration of the migration, or route new sign-ups to the new platform from day one. Both are defensible; pick one and stick to it. If you leave the door open on the old platform, you will finish the migration with a delta that never reconciles, and nobody will ever know which contacts lived where.

Then clean. Remove hard bounces first, then contacts inactive for 12 months, then anyone who unsubscribed under a previous list owner. In my experience, a neglected list loses between 25% and 40% of its rows to bounce and long-term inactivity. A migration is the single best moment to shrink a list, because you will not get another chance to do it painlessly.

Split the remainder by recency into three segments: active in the last 90 days, active between 90 and 365 days, and everything older. Move the first segment first. If the migration works, you have already proven the pipeline on your most valuable contacts. If it breaks, your blast radius is a third of the list instead of the whole thing.

Rebuilding the Three Automations That Actually Pay

Most teams run dozens of workflows and cannot tell you which three they could not survive without. Here are the three that consistently show up, and what breaks when you rebuild them.

Welcome sequence. Breaks on the first trigger. The old platform counted a signup; the new one counts a form submission, or a tagged contact, or a webhook event. Rebuild the trigger explicitly and send a test to yourself from a fresh mailbox, not from an address already in the list.

Behavioral trigger. Breaks on event naming. A purchase, a download, or a page view will not be the same event name on the new platform. Map every old event to a new one in a table before you rebuild a single flow, then check that the events are actually firing. I have seen teams launch a flow and wait three weeks for it to fire, because the event was never wired to the page.

Birthday email. Breaks on timezone. A birthday automation that reads local timezone on one platform fires at the right moment; the same field on another platform fires at midnight server time, and everyone gets it at 3 a.m. local. Decide the firing rule once and test it across three timezones.

I have found that rebuilding these three before anything else is the right order. They are cheap to test, they fire often enough to expose wiring errors within days, and they are the automations most likely to be running silently and broken without anyone noticing.

Protecting Send Reputation Is the Whole Game

Deliverability is the only migration risk that is not recoverable in a day. Reputation compounds slowly and collapses fast, and the new platform inherits almost nothing from the old one.

Set up your DNS before the first send. The records you need are SPF, DKIM, and DMARC, and I include the DMARC record on day one even when it is set to monitor, because a platform that sends unauthenticated email on a monitored domain will get downgraded faster than one that does not.

Isolate the sending domain. I use a subdomain, something like mail.example.com, rather than the apex domain, so a collapse on the new platform cannot take down transactional email on the domain you still depend on. This is the single most important defensive move in the whole migration.

Then ramp. Send to the most engaged third of your list at reduced volume for the first week, add the middle third in week two, and only then the long-tail contacts. Every major provider throttles new sending from unwarmed domains, and a full-throttle first send after silence is the fastest way to land in a spam folder.

Run both platforms in parallel for two weeks. Send the same campaign from the new platform and the old one to the same list, and compare three numbers: open rate, click rate, and unsubscribe rate. If the new platform is within a few percentage points on all three, cut over. If open rate drops sharply, the problem is authentication or throttling, not content, and you fix the records and rerun before touching a template.

The Two-Week Dual Run, End to End

Here is the checklist I hand to the team I run the migration with. Every row needs a date and a name on it.

  1. DNS records set and verified on the new domain or subdomain.
  2. Welcome sequence rebuilt, tested from a fresh mailbox, confirmed firing.
  3. Behavioral events mapped old to new and confirmed firing in production.
  4. Birthday automation fired correctly across three timezones.
  5. First send ramped to the engaged third of the list.
  6. Middle third added at week two, no deliverability incidents.
  7. Open rate within range on the new platform.
  8. Click rate within range on the new platform.
  9. Unsubscribe rate within range on the new platform.
  10. Old account frozen, exports archived, payment method removed.

Rows one through four are the setup. Rows five through nine are the validation. Row ten is the only step that feels satisfying, and it is the one most teams reach first.

What the Mailchimp Free Tier Taught Us

The 250-contact cap has been the same number for a very long time. That stability is itself a signal, because it means the free tier is not where a growing product tries to win customers. Growing products push you onto a paid tier with automation, then charge per contact, then segment the business when the unit economics stop working.

For a remote team of two or three, a 250-contact list is often still the right tool. Do not migrate out of a platform that is doing the job, merely because it is cheap. Migrate when one of the four triggers fires, and specifically when trigger three fires, because segment announcements are not announcements, they are deadlines.

The teams that migrate well are not the ones with the biggest list. They are the ones that freeze first, segment by recency, rebuild the three automations before the rest, isolate the sending domain, and run two weeks in parallel before cutting over. Everything else is detail. Those six moves are the migration.

Frequently Asked Questions

1Is Intuit really reducing investment in Mailchimp?

Yes. On its fiscal 2026 fourth-quarter earnings call, Intuit announced Mailchimp will become a separate reportable segment starting in fiscal 2027. Segmenting a business out is how a parent company makes it visible for divestiture, and it is the clearest supplier-risk signal you can receive from the vendor itself.

2How many contacts does the Mailchimp free plan actually allow?

Mailchimp's official pricing page caps the free plan at 250 contacts and 6,000 emails per month. Many teams that believe they are on a free tier are already well past that limit and being billed under a different tier name.

3Do I have to migrate my whole list at once?

No, and you should not. Freeze the list, clean it, then move it in segments starting with your most active contacts. Segment-by-segment migration keeps your sending reputation recoverable if something breaks, instead of losing every segment at once.

4How do I avoid a deliverability collapse during the move?

Set up DNS records on the new platform before the first send, isolate the new domain or subdomain from the one you are leaving, and ramp volume gradually. Then run both platforms in parallel for two weeks and compare open rate, click rate, and unsubscribe rate before you cut over.