Migrate from Mailchimp to listmonk: what the move involves
A team that has decided to leave Mailchimp for newsletters and announcements can run those sends on listmonk in its own infrastructure, but the project is not a database import. listmonk handles subscriber management and campaign sending, and the effort sits in three places: exporting audiences with their consent records intact, rebuilding templates in listmonk's Go templating, and standing up SMTP sending and deliverability work that Mailchimp currently does for you. listmonk does not replace Mailchimp's automation journeys. If you rely on welcome series, behavioral triggers or multi-step flows, plan for Mautic or Dittofeed as a separate decision.
Usually an internal marketing operations or platform owner leads the move, since they hold the Mailchimp account, the list definitions and the brand templates. An implementation partner typically handles the parts that need infrastructure skills: deploying listmonk as a single binary on PostgreSQL, configuring the database and backups, connecting one or more SMTP servers, and setting up bounce handling and sender authentication. listmonk ships as a standalone binary with PostgreSQL as its only dependency, which keeps the footprint small, but the surrounding mail configuration is where most of the work lands.
Effort depends on three factors you can measure before you start: how many lists and tags you maintain, how complete your consent records are for each subscriber, and how many emails you send per campaign and per month. Ask Mailchimp for a full audience export and check whether each row carries an opt-in date and source, because listmonk's single and double opt-in lists depend on that history. Confirm with your SMTP provider which sending limits, warm-up expectations and bounce feedback they support before you choose a sending volume target. Those answers, not the listmonk installation itself, set the schedule.
Which Mailchimp capabilities map cleanly to listmonk and which need rework
This table maps the capabilities a newsletter team typically uses in Mailchimp to their listmonk equivalents, marked clean, needs rework or gap. Read the notes column first for any row that affects your sending or consent records. The main takeaway is that listmonk covers list-based newsletters well, while journey automation and Mailchimp-native integrations need to be scoped and confirmed against your own account.
| Capability | listmonk equivalent | Status and notes |
|---|---|---|
| Audiences and lists | Lists with subscribers managed across many lists | Clean. Lists map directly, but confirm how your audiences are split before importing. |
| Subscriber fields and attributes | Subscriber attributes stored as JSON and queried with SQL | Needs rework. Map each Mailchimp merge field to an attribute key and check data types during import. |
| Opt-in handling | Single and double opt-in lists | Needs rework. Set each list's opt-in type and carry over consent evidence from your Mailchimp export before sending. |
| Templates | Go templating with more than 100 functions and HTML, Markdown or plain text editing | Needs rework. Mailchimp layouts and merge tags must be rebuilt in Go template syntax and tested per client. |
| Segmentation | Subscriber segmentation with SQL expressions | Clean for rule-based segments. Rebuild each saved segment as a query and confirm the counts match. |
| Campaign sending | Campaigns sent through multi-threaded queues across several SMTP servers with rate limiting | Clean. Sending depends on your SMTP provider, domain authentication and warm-up plan, not on listmonk alone. |
| Reporting | Built-in campaign, bounce and link analytics | Needs rework. Confirm which Mailchimp reports your team relies on, since fields and dashboards will differ. |
| Transactional email | Transactional mail API for pre-defined templates | Needs rework. Move transactional sends to listmonk templates and reconfigure any Mailchimp API calls in your applications. |
| Access control | OIDC single sign-on with granular roles, permissions and API tokens | Clean for most teams. Confirm role design against your current Mailchimp users and approval steps. |
| Journey automation | Not a listmonk feature | Gap. Scope any Mailchimp automations separately, for example with Mautic or Dittofeed, and confirm each one in your account. |
| E-commerce and native integrations | Not covered by listmonk's supplied features | Gap. Inventory Mailchimp store, ad and app connectors and confirm each replacement before cutover. |
Which audience, consent and template data must move, and by what path
A Mailchimp move is more than copying email addresses. The subscriber status, list membership, consent evidence and template assets each need their own export path and check before anything is imported into listmonk. The cards below set out what to move, what to confirm in each vendor's documentation, and what to verify after import.
Subscriber records and status
Each subscriber row carries an email address and a status such as subscribed, unsubscribed, cleaned or pending. Confirm which statuses Mailchimp's audience export includes and how it labels bounced or cleaned addresses. Import only addresses that are still valid for sending, and keep unsubscribed or cleaned contacts out of any active listmonk list so they are never mailed again. Check the exported file for duplicate emails and for case or whitespace differences that could create two records for one person.
List membership and segments
Mailchimp audiences, groups and tags determine which newsletters a person receives, so these memberships must map to listmonk lists before import. Decide whether each Mailchimp audience becomes one listmonk list or whether tags and groups become segments queried with SQL expressions. Confirm in Mailchimp's export documentation whether tags and group membership appear as separate columns or must be requested separately. Map each list to its sending purpose so a subscriber who joined for one newsletter is not added to another.
Custom attributes and merge fields
Merge fields such as first name, location or preferences are the custom attributes your templates depend on. listmonk stores subscriber attributes as structured data that templates can reference, so each Mailchimp merge tag needs a matching attribute name and type. Confirm the exact column names and date formats in the Mailchimp export before writing the import mapping. Test a few records end to end after import to confirm that personalization renders correctly in a test send.
Consent and opt-in evidence
This is the component most likely to be lost in a move. A Mailchimp export generally shows that a contact is subscribed, but the timestamp, signup form, IP address and opt-in confirmation details that prove consent may not be included in the same file. Consent evidence must be carried into a record your team can defend before any contact is imported. Record the source, date and method of consent for each list, and mark whether the list is single or double opt-in in listmonk. Confirm with counsel which evidence your jurisdiction and contracts require, and confirm with Mailchimp which consent fields its export contains.
Campaign templates and images
Mailchimp templates use its own block structure and merge tags, which do not transfer directly. listmonk templates use Go templating, so each reusable layout is rebuilt in its template editor and each merge tag is rewritten to the listmonk equivalent. Download hosted images and confirm their licensing and URLs before the Mailchimp account closes, because image links in old campaigns may stop working. Test every rebuilt template with a sample subscriber and check links, unsubscribe footers and plain-text versions.
Sign-up forms and connected feeds
Sign-up forms, e-commerce connectors, CRM syncs and webhooks all feed the Mailchimp audience. Each one must be inventoried, because after cutover a form that still posts to Mailchimp will silently stop adding people to listmonk. Decide which feeds will call listmonk's API or a webhook, and which will be retired. Confirm the list of active integrations in your Mailchimp account settings before the migration plan is approved. Update the consent wording on each form to match the new record.
How consent and double opt-in status carry over into listmonk
Consent is the highest-stakes part of this migration. A subscriber list is only as valuable as the permission behind each address. listmonk stores each subscriber against the lists they belong to, and it distinguishes single opt-in lists, where a subscription is active on import, from double opt-in lists, where the subscriber must confirm before receiving campaigns. If a contact is imported with a status their original signup did not support, you are emailing someone who never agreed to that list, and the mistake is hard to reverse once messages have gone out. Your export from Mailchimp should carry the consent evidence you need (the signup date, the form or source where available, and the list's opt-in type at the time), but confirm each field with your own export before you rely on it, because the fields Mailchimp includes vary by account and audience.
Build the import rule before you run any import. For each Mailchimp audience, sort subscribers into three groups: those who completed a confirmed signup on a form that matches the listmonk list's opt-in type and can be imported as confirmed; those whose consent is unclear, such as older imports, partner lists, or signups where you cannot show the form or date, who should be re-invited through a double opt-in confirmation; and those with no provable consent or who have unsubscribed or bounced, who should be dropped and never reloaded from another file. Use the status and list subscription fields in your import file to reflect these decisions explicitly, and keep the file that records each decision. Illustrative example: a subscriber who joined a double opt-in newsletter form three years ago with a timestamped confirmation goes in as confirmed, while a subscriber added by a bulk upload with no source goes to reconfirmation.
Have your legal or privacy owners approve this rule, including the treatment of unsubscribes, suppression records and jurisdiction-specific requirements, before anything is imported. DeployOpen can prepare the segmentation process, the import files, the mapping and the evidence log that shows how each group was decided, but it does not issue legal opinions, and an independent auditor or certification body is the party that assesses any compliance claim. Ask your counsel to confirm which lawful basis applies to each audience and whether a re-permission campaign is required in your markets.
The migration sequence from inventory to decommission
This sequence moves Mailchimp audiences, templates and sending to listmonk in controlled stages, so each stage has a documented result before the next begins. It ends with Mailchimp switched off only after the retention period your organization requires has been met.
Inventory lists, templates, automations and integrations
Build a single inventory register that lists every Mailchimp audience, segment, tag, template, automation, form, integration and sending domain. Name an owner for each item, record which ones are still in use, and note which consent source backs each audience. Your marketing operations lead and the privacy or legal contact should both sign the register. The step is done when every item has an owner, a status and a consent note, and nothing active is left unrecorded.
Run a pilot with one list and one template
Choose one small, well-understood audience with clear opt-in evidence and one simple newsletter template. Import the subscribers into a listmonk list configured as single or double opt-in to match the original consent, rebuild the template with Go templating, and configure your SMTP server and sending domain. Send test campaigns to internal addresses and to a small external group. The step closes with a signed-off pilot report covering import counts, rejected rows, rendering checks across major mail clients, and delivery and bounce results.
Parallel run to a controlled segment
Keep Mailchimp live and send selected campaigns from listmonk to a controlled segment of engaged subscribers, while the same content continues to go out through Mailchimp to its usual audience. Compare inbox placement signals, bounce rates, complaint reports and unsubscribe activity between the two stacks over several sends. Confirm that the listmonk campaign analytics and bounce handling are recording what you expect. The step is complete when you hold a delivery and bounce comparison report that the team has reviewed, and any gaps in SMTP configuration or authentication records are fixed.
Cut over sending domains, forms and integrations
Move the remaining audiences and templates to listmonk and repoint sign-up forms, website embeds and integrations, such as e-commerce or CRM connectors, to the new endpoints. Update the DNS records that authenticate your sending domain, following your SMTP provider's instructions, and check that the new authentication settings pass before the old ones are retired. Keep a change record that shows each DNS entry, form URL and integration changed, the person who changed it, and the time of change. The step is done when test sign-ups flow into listmonk and the change record is complete.
Decommission Mailchimp after the retention period
Before closing the Mailchimp account, export the final audience data, consent records, campaign reports and template files, and store them in an archive your legal and records teams approve. Confirm the retention period your organization requires with those teams, then cancel the subscription and remove the Mailchimp sending authorizations from your DNS. Ask your Mailchimp account representative or the support documentation which data remains available after closure. The step is complete when the archive is verified, the retention period has passed, and the decommission record is signed by the data owner.
What drives the cost and duration of the move
This table lists the factors that change how much work and money a Mailchimp to listmonk move takes, why each one matters, and how to keep it manageable. Read it before asking for a quote, because the same list becomes the scope you should put in writing. The main takeaway is that software licensing is not the main cost: effort goes to consent data, templates, sending infrastructure and running the system afterward.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Subscriber and list count | More subscribers and lists mean longer imports, more deduplication and more segments to rebuild as single or double opt-in lists. | Remove unsubscribed, bounced and inactive contacts before export, and merge lists that serve the same purpose. |
| Share needing consent reconfirmation | Contacts without a verifiable opt-in record may need a double opt-in campaign before they can be mailed, which adds sending, follow-up and suppression work. | Export consent and opt-in fields first, then decide which contacts can move as confirmed and which must reconfirm. |
| Number and complexity of templates | Mailchimp templates must be rebuilt using listmonk's Go templating, and heavily customized layouts take longer to test across mail clients. | Consolidate to a few base templates and keep merge tags simple; retire unused designs. |
| Custom integrations and forms | Sign-up forms, website embeds, e-commerce connectors and API calls each need to be pointed at listmonk and tested again. | Inventory every form and integration before the move and list which ones must work on day one. |
| SMTP provider and domain warm-up | Choosing an SMTP service, configuring authentication for your sending domain and warming up IP reputation affects deliverability from the first campaign. | Confirm the SMTP provider's sending limits and warm-up guidance in writing, and start with smaller segments of engaged contacts. |
| Internal skills available | Running PostgreSQL, a Go binary behind a reverse proxy, backups and upgrades needs staff who can operate them, or a partner who does. | Assess skills before picking a scope, and decide which tasks stay in-house and which go to a retainer or implementation partner. |
| Parallel running | Keeping Mailchimp and listmonk active during cutover means paying for both platforms and maintaining two sets of audiences until switchover is complete. | Set a fixed cutover date, freeze new Mailchimp list growth in advance, and agree the parallel period in the written scope. |
| One-time work: migration and testing | Exporting, mapping fields, importing, rebuilding templates, testing forms and cutover are project effort that does not repeat. | Ask for a fixed-scope plan listing each deliverable, test and acceptance step. |
| Recurring work: hosting and operations | Server or cloud hosting, PostgreSQL operations, backups, monitoring, upgrades and the SMTP provider's fees continue after go-live. | Ask for a monthly run estimate covering each component, and confirm which items your team owns. |
How the migration differs by list size and starting point
A small newsletter usually has one sender, a handful of lists and a single template family. The migration is mostly a sequence of checks: confirm what consent evidence the Mailchimp export actually contains, decide whether each list stays single or double opt-in, and rebuild the one or two templates the newsletter uses. The main effort falls on the people deciding, not on the tooling, because a small team often has no one who owns deliverability.
- Consent first: Confirm which opt-in records you can export and which subscribers have no provable opt-in before importing anything.
- List decisions: Decide which lists become double opt-in in listmonk, since existing subscribers imported from Mailchimp need a clear basis for being mailed.
- Template rebuild: Recreate the main newsletter layout in listmonk's Go templating, keeping the unsubscribe and preference links intact.
- Sending path: Choose the SMTP provider and confirm the sending domain's authentication records before the first real send.
- Warm-up plan: Start with the most engaged subscribers so the new sending path builds a reputation gradually.
Before the first campaign, check that a test send reaches the inbox, that unsubscribes work, and that bounces are being recorded.
A larger organization often has many audiences, separate lists per region or product line, and different sending identities for each. The migration becomes a mapping exercise: every Mailchimp audience, tag and segment must be assigned to a listmonk list, with its consent status carried across. Regional sending can add rules about content, unsubscribe language and data location that must be settled before import, not after.
- Audience map: Document each Mailchimp audience, its tags and its owner, then decide the matching listmonk list and whether it is single or double opt-in.
- Regional rules: Confirm which jurisdictions require specific consent wording or retention rules, and get legal sign-off on the migrated opt-in evidence.
- Sending identities: Plan separate sending domains or SMTP configurations per region, since listmonk can send through multiple SMTP servers with rate limiting.
- Segmentation rebuild: Translate Mailchimp segments into listmonk SQL queries and test each against a sample before relying on it.
- Deliverability ownership: Name who watches bounces, complaints and sender reputation for each domain before volume grows.
Risks here are heavier because a mistake in one list can affect several regions at once, so run a staged cutover one audience at a time.
A team that already operates its own mail infrastructure, including outbound SMTP relays, DNS authentication records and bounce handling, starts with most of the sending risk already managed. The work shifts to integrating listmonk with that existing path, deciding how its bounce and complaint feedback reaches listmonk, and checking that the current reputation is not put at risk by a new sending pattern.
- Relay reuse: Confirm whether listmonk should use the existing SMTP relay directly or a separate pool, and set per-server rate limits to match the relay's limits.
- Feedback loops: Make sure bounce and complaint data reaches listmonk, so suppression lists stay accurate across both systems.
- Shared reputation: Check whether existing transactional mail shares the same IP pool or domain, since a bulk newsletter can affect password resets and receipts.
- Configuration review: Compare the current SPF, DKIM and DMARC setup with what the newsletter domain will use, and confirm the records match.
- Change control: Route the SMTP and DNS changes through the same review process used for other production mail.
Confirm with your own operations team which bounce and complaint signals you already collect, because listmonk's analytics will only be as complete as what it receives.
A team without its own mail infrastructure must choose an outbound email delivery service before listmonk can send anything. Mailchimp currently handles delivery for its customers, so this is the step where cost, reputation and compliance questions move onto the migrating team. The provider choice, domain setup and warm-up plan should be decided before the subscriber import, because they determine how quickly the first campaigns can go out.
- Provider selection: Compare providers on sending regions, data processing terms, bounce and complaint webhooks, and the pricing model you will pay for ongoing volume.
- Domain authentication: Set up dedicated sending domains with SPF, DKIM and DMARC records, and plan for the time DNS changes take to propagate.
- Warm-up schedule: Start with small sends to the most engaged subscribers and increase volume gradually, since a new sender has no history.
- Data processing agreement: Confirm the provider's contract terms cover the subscriber data you will send through it.
- Ongoing ownership: Assign someone to watch bounce rates, complaint rates and provider notices after launch.
Ask the provider to confirm its current limits, webhook support and any warm-up requirements in writing, because these change and should not be assumed from older documentation.
What usually goes wrong when moving newsletters to listmonk
Most failed newsletter migrations fail on consent, deliverability and forgotten connections rather than on the software itself. The cards below cover the six risks that tend to surface after cutover, each with a check to run before the first live send. They are ordered roughly by when a team meets them: data export, import, template build, sending setup, and operations.
Importing unconfirmed subscribers
A Mailchimp export does not always make the opt-in state obvious, so teams often load every contact into a single list. If that list is meant to be double opt-in, contacts who never confirmed will receive campaigns they did not request. Run a consent audit before import: decide which source lists were confirmed, map each one to a listmonk list with the right opt-in type, and import unconfirmed contacts only into lists that match their original consent. Do not import unconfirmed contacts into a double opt-in list as if they were confirmed.
Losing the consent trail
The consent record is the evidence that a subscriber agreed to receive mail, and it lives in the fields and timestamps you export. If those columns are dropped, renamed or left out of the import mapping, the new system has addresses without any proof of how they arrived. Before exporting, confirm which consent-related fields the export includes, store the original export file unchanged in an archive you control, and document how each consent field maps to listmonk's subscriber attributes and list status.
Sending from a new IP or domain cold
When listmonk starts sending through your own SMTP servers, mailbox providers see a sending source with no history. Sending the full list on day one, from an unfamiliar IP or domain, is a common cause of throttling and spam placement. Plan a staged warm-up that starts with the most engaged subscribers and increases volume over several sends, while watching bounce and complaint rates at each step. Confirm the warm-up practice, authentication setup and sending limits with your SMTP provider and with the major receiving mailbox providers.
Template breakage from Go syntax
listmonk templates use Go templating, so a Mailchimp merge tag such as a field placeholder will not render as expected after pasting. Errors often appear only for some subscribers, such as those with an empty name field or a missing attribute, which makes them easy to miss in a single test send. Build a test suite of sample subscribers covering empty, long and unusual values, send each template to test addresses across major mail clients, and review the rendered plain-text version alongside the HTML.
Bounce and complaint handling not wired up
Mailchimp handled bounces and unsubscribes for you, and listmonk expects you to configure how those events are received and acted on. Without this, hard bounces keep receiving mail, complaints go unrecorded, and sender reputation erodes. Confirm how your SMTP provider reports bounces and complaints, configure listmonk's bounce handling and suppression behavior accordingly, and check the campaign analytics for bounce counts after each test send, not only after the first full campaign.
Forgotten forms and integrations
Sign-up forms embedded on websites, landing pages, checkout flows and CRM or e-commerce connectors often still post to Mailchimp after the newsletter moves. New subscribers then land in the old account while listmonk sends to a stale list. Build an inventory of every form, embed, API call, automation and connector that touches Mailchimp, assign each one a new listmonk endpoint or retirement date, and confirm the old account is not still receiving sign-ups before you close it.
Questions teams ask before moving from Mailchimp to listmonk
How much effort does moving from Mailchimp to listmonk take?
The effort depends mainly on how many audiences, lists and templates you run, how clean your consent records are, and how many automations you rely on. A team with one newsletter list, a handful of templates and clear opt-in evidence has a small job. A team with many segments, tagged audiences, SMS contacts and years of mixed consent history has a larger one. The main work items are the audience export, consent mapping, rebuilding templates in listmonk's Go templating, configuring SMTP sending and warming up the sending domain. Ask for a written inventory of lists, templates and automations before anyone estimates the work.
How long does the migration take, and what sets the pace?
The pace is set by the slowest dependency, not by the import itself. Consent and opt-in questions, DNS access for SPF, DKIM and DMARC, the choice of SMTP provider and the deliverability warm-up period usually decide the schedule. Importing subscribers into listmonk is typically the quick step. Parallel sending during warm-up and the review of templates before cutover take longer. Confirm with your team which calendar dates matter, such as a major announcement or contract end, and agree the cutover window in writing before work starts.
What must our team provide before the move starts?
Several inputs decide whether the move goes smoothly:
- A full inventory of audiences, tags, templates, and any automations or customer journeys in Mailchimp.
- Consent evidence for each audience, including signup source, timestamps and the wording shown at signup, so you can decide which contacts become single opt-in and which need re-confirmation.
- DNS access to the sending domain to publish and verify SPF, DKIM and DMARC records.
- Decisions on the SMTP provider, sending volumes per day and bounce handling rules.
- A named business owner who signs off on templates, the suppression list and the cutover.
Confirm who in your organization holds each item, because delays usually come from missing consent records or DNS changes.
Can an in-house team move from Mailchimp to listmonk without a partner?
Yes, a capable in-house team can do it, provided it has someone comfortable with PostgreSQL, Docker or a Linux server, SMTP and DNS configuration, and Go templates. The harder parts are usually not technical: reconciling consent evidence, planning the warm-up without damaging sender reputation and documenting the decisions for auditors or legal review. Ask yourself whether those skills and the time to carry them out sit within the team. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, so you can decide which parts to keep in house.
Does listmonk replace Mailchimp automations?
No. listmonk is a one-way newsletter and mailing list manager. It sends campaigns, manages single and double opt-in lists, supports SQL segmentation and offers a transactional mail API for predefined templates. It does not provide the multi-step, event-driven automations that many Mailchimp accounts use, such as welcome series triggered by behavior or branching customer journeys. If you rely on those, plan for Mautic for campaign automation with forms and scoring, or Dittofeed for event-driven journeys across email and other channels. Map each Mailchimp automation to one of these options, or to a manual process, before you set the cutover date.
What does the ongoing run cost include after cutover?
Your run cost has several recurring parts, and listmonk's free license covers only the software. You pay for the server or cloud account that hosts the binary and PostgreSQL, backups and storage, the transactional email provider or SMTP service you send through and its volume charges, domain and DNS management, monitoring, and the time to apply upgrades. listmonk is licensed under AGPL v3, so there are no per-contact license fees, but you should confirm your obligations under that license if you modify the software. Ask any provider for a quote that separates one-time setup from monthly infrastructure, sending and support costs.
How do we keep deliverability and consent records safe during the move?
Warm up the new sending setup gradually, starting with your most engaged subscribers, and keep Mailchimp running in parallel until the new setup shows healthy bounce and complaint rates. Import suppression lists, unsubscribes and bounces before the first send so previously opted-out contacts are never mailed. Keep a copy of the original export with its consent fields and the import log, and store them under your retention policy. Confirm with your legal or compliance team which records they need and how long they must keep them.
How DeployOpen scopes, runs and supports a Mailchimp to listmonk migration
DeployOpen plans and implements the move from Mailchimp to a listmonk instance in your own infrastructure, starting from a written scope. The work covers consent-aware audience export, subscriber import, template rebuilding, SMTP sending and deliverability setup, with handover documentation at the end.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Mailchimp audiences, consent fields and tags move, and which are retired or left behind.
- We confirm the hosting target, PostgreSQL setup, SMTP provider and sending domains with your team before any data moves.
How we build
- We install listmonk from the official Docker image or binary, with PostgreSQL as its only dependency, in your environment.
- We map exported consent and opt-in fields to single or double opt-in lists and test imports on a sample before the full load.
- We rebuild each newsletter template in listmonk's Go templating, then test rendering, links and plain text versions.
How we hand over
- You receive documentation of the deployment, configuration, list structure, sending setup and the import steps performed.
- We walk your team through campaign creation, segmentation, bounce handling and the analytics listmonk provides.
- Handover includes a record of the consent evidence carried over, so your compliance lead can review it with your auditors.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover listmonk version upgrades, backups of the PostgreSQL database and SMTP configuration changes.
- Ask for a written quote based on your scope, which sets out what is one-time work and what recurs.

