Migrating from Mailchimp Step by Step

Migrating from Mailchimp is a technical project. Not a matter of clicking export and import. We see it every time a client moves a list onto our fleet of sending servers. The CSV file? The smallest problem. The whole difficulty sits in consent, list hygiene, DNS configuration and warming up the new sender. Move everything in a single day and fire at the entire list, and deliverability drops, while rebuilding reputation takes weeks. Below is the order we follow when moving accounts.

Before you start: what you really need to take out of Mailchimp

Start with an inventory of the account. Write down lists and segments, tags, custom fields, signup forms, automations and templates. Without that map you will not rebuild the logic on the other side. The gaps only show up during the first campaign, and by then things are tense.

Export contacts together with the date and source of consent. An email address alone, with no metadata, is data you cannot defend during an inspection. The signup date, the wording of the clause, the IP address and the source form – that is your proof of a legal basis for sending. Those columns are missing from the export? Fill them in from other systems before you import anything.

Save the campaign history separately, with open, click and unsubscribe statistics. That is your baseline. Without it, after the migration you will not tell a drop caused by the change of tool from ordinary seasonality.

Check address statuses as well. Contacts marked as cleaned, unsubscribed and bounced do not travel further. Importing an unsubscribed address into a new system is not a technical oversight. It is sending without a legal basis.

Tip: run the export on the same day you plan the import. Working with a file from two weeks ago means you will carry over people who have already unsubscribed.

Cleaning and list hygiene before the import

Do not move the list one to one. Move the part that reads and clicks. The rest stays behind, at least at the start. A new sender has no history with the filters yet, so every signal weighs far more for it than for an account that has been running for years.

The scope of the cleanup is simple and mechanical:

• Hard bounces – addresses that do not exist, removed without exception.
• Role addresses such as info@, office@, contact@ – they reach many people, they generate complaints and they rarely click.
• Duplicates – including those created by different letter case and trailing spaces.
• Typos in domains – gmail.con, wp.pi, onet.p. Some can be corrected, some have to be cut out.

Doubtful addresses do not have to be guessed at. You can check whether an address exists without sending anything to it, which lets you drop the dead ones before they cost you a bounce on the new infrastructure.

Then segment by engagement. Separate people active in the last ninety days, people active within the year and dormant ones. That split decides the order of sends in the next stage. Segmentation, tags and custom fields are core features of the platform, so you can rebuild that split before the import.

Leave the dormant ones for later or for a separate reactivation campaign. Never for the first send from the new infrastructure. A bad list ruins sender reputation faster than any mistake in the content, and rebuilding it takes longer than moving the account itself.

Consent, GDPR and PKE article 398 when changing provider

Changing the tool does not invalidate consent. Consent covers the data controller and the purpose, not the platform. But you have to hold the proof: the wording of the clause as it stood at the moment of signup, the date, the IP address and the source. If you do not have that, then formally you do not know what the person agreed to.

The Electronic Communications Law in article 398 requires consent for sending commercial information in B2B relations as well. A company address is not an exception. The practice where a company builds a list from business cards and email signatures and then explains “but this is business” does not hold up at all during an inspection.

On the formal side, prepare two things: an update to the record of processing activities and a data processing agreement with the new provider. Check also where the servers physically stand and whether the data leaves the EEA. With American platforms the transfer is the rule, not the exception. Our fleet stands in Poland, so the transfer question simply does not arise – that is a real selection criterion, not a line from a leaflet.

Contacts without documented consent stay in the old system or get deleted. Do not import them blind, counting on nobody asking.

Technical sender configuration: SPF, DKIM, DMARC, Return-Path and PTR

You set up authentication before the first send, not after the first problems. And the order matters here.

1. SPF – add the new provider to the existing record, do not create a second one. Watch the limit of ten DNS lookups. Exceeding it gives a permerror result, and then SPF does not work at all.
2. DKIM – use a separate selector for the new platform. Leave the old Mailchimp key active until the end of the transition period, because both sending paths have to sign correctly.
3. Return-Path – set it on your own subdomain. That way a bounce comes back where it should, and SPF alignment matches the sender domain.
4. DMARC – start with p=none and reports. Tighten the policy only after confirming that all traffic passes authentication. Switching on p=reject during a migration can cut off your own transactional messages.
5. PTR and IP reputation – with your own fleet of sending servers you check this in house and you know who else sends from that address. On shared pools you are left trusting the provider.

Tip: make the DNS changes a few days before the first send. Then send a test message to your own mailbox and read the headers. Three lines interest you: the SPF result, the DKIM signature and DMARC alignment. Green icons in the provider panel are not the same thing as the header at the recipient.

Warming up the new sender: a schedule instead of one big shot

Warmup works because the filters learn your traffic gradually. You direct the first sends only to the most engaged segment. Opens and clicks from people who are waiting for your messages build the history. Only then do you widen the reach.

Break the schedule down by mailbox provider. Gmail, Outlook, WP and Onet react differently and have their own thresholds. It happens that in the same send one operator accepts everything while another starts delaying the queue. Without that split you will see an averaged number and you will not learn where the problem lies.

Watch bounces, complaints and queue delays, not opens alone. Opens are noisy because of privacy protection in mail clients. The server response code does not lie.

A block at a large filter always looks the same: messages stop leaving the queue, and the logs show a 4xx or 5xx response with a specific description and often a link to the operator page. You read the code, you limit the rate, you fix the cause and you file a request. Getting unblocked takes from a few hours to a few days. We do this regularly, so let me say it plainly: you can get out of it, but not in five minutes.

Keep part of your sending in Mailchimp through the transition period. That is a safeguard, not indecision.

Rebuilding automations, forms and integrations

Move the logic, not the layout. The welcome sequence, the cart reminder and recurring campaigns have to reproduce entry conditions, delays and exit conditions. Copying the look of a template is the least important part of this work.

Swap the signup forms on the website and in the shop as soon as the new account goes live. Otherwise fresh addresses keep dropping into the old system and after a month you have two lists that have drifted apart. On WordPress the quickest route is a plugin that sends form signups straight to your mailing list, without rewriting the forms by hand.

The unsubscribe link has to work from the first send. Because if it does not work, the recipient will not write to you asking to be removed. They will click “this is spam”, and the complaint hits the reputation of the whole domain.

Plan integrations over API and webhooks together with the mapping of custom fields and tags. Field names rarely match one to one, and personalisation with an empty field looks worse than none at all. Before you start writing your own code, check the list of ready integrations – some connections to a shop or a CRM you will set up without a developer.

Not everything transfers directly. Parts of the more elaborate visual automations are not with us yet – they are on the roadmap. Until they ship, you work around it with conditions on the shop or CRM side that trigger the send over the API. It works, but it needs configuration on the client side. We prefer to say that plainly rather than promise a feature you will not see in the panel. We described the technical details on the site: email marketing platform with its own sending servers.

Checks after the migration and shutting down the old account

The first two weeks run against a checklist:

• Authentication: SPF, DKIM and DMARC passing in the headers of every send, not just the test one.
• Bounce rate split into hard and soft rejections.
• Complaints at individual operators.
• Landing in the promotions folder and other tabs, checked on real mailboxes.

Compare the results with the data from before the migration, the data you saved at the start. Without that reference you will confuse the effect of changing tools with a holiday drop in activity.

Read DMARC reports regularly. That is the only source that shows who actually sends on your behalf. You will find forgotten systems there: the shop, the CRM, the contact form, sometimes somebody’s attempt at spoofing.

Remove the old provider’s DNS entries last. Mailchimp’s DKIM and SPF stay active as long as anything is going out from there, including system notifications. Delete them too early and part of your messages stop passing authentication.

Before closing the account, export the campaign archive and the reports. After deactivation you will not get the history back, and it comes in handy when analysing which content worked best.

Summary: a migration is a technical project, not a click-through import

The outcome is decided by the order: consent, list hygiene, DNS, warmup, and only then the full send. Reversing those steps costs reputation, not time.

The most common mistake always looks the same. A company imports the whole list and on day one sends to everyone from the new infrastructure. The filters see an unknown sender with a large volume, part of the messages land in spam, complaints go up, and the next campaigns already start from a worse position.

A migration run properly takes a few weeks. And it usually ends with better deliverability than before the change, because along the way you clean the list, put consent in order and fix authentication that was half-done on the old account.

If your account has an unusual structure, many sender domains or a large list, write to us before the export. We will go through the plan together and set a warmup schedule for your volume. Better to set it up at the start than to climb out of a block at an operator later.