Mailwizz to Mailblast: A Step-by-Step Migration Walkthrough

Migrating from Mailwizz to Mailblast usually takes 1-2 hours for a single-customer setup, and the key reason is structural: both products send through your existing Amazon SES account, so verified identities, DKIM, dedicated IPs, and warmed reputation stay attached to AWS rather than to the application you are leaving (AWS, 2026). You are swapping the management layer, not rebuilding the pipes.

This walkthrough covers the exact sequence I use when helping people leave a self-hosted Mailwizz install. It assumes you are already on Amazon SES and want to stay there. If you are still evaluating, the head-to-head in Mailwizz vs Mailblast is the better starting point.

Pre-flight checklist

Before you touch the Mailwizz admin, capture the state you will need to reproduce. Migrations fail more often from missing context than from missing data. Spend 15-20 minutes on the checklist below, document your SES identities and SNS topics, and confirm you have an AWS IAM user with ses:SendEmail, ses:SendRawEmail, and sns:Publish permissions ready for Mailblast to use (AWS, 2026).

Concretely, before exporting anything:

• List every verified SES sending identity (domain and email) in the AWS console for the region Mailwizz currently uses.
• Note the SES dedicated IP pool name if you have one, plus the warm-up status of each IP.
• Screenshot or export your Mailwizz delivery server configuration (region, throttling limits, hourly and daily quotas) so you can mirror it in Mailblast.
• Capture custom subscriber fields from Lists > List > Custom fields for each list - column name, tag, type, and default value.
• Document existing SNS topics for bounces and complaints; you will repoint these later, not recreate them.

If you run Mailwizz in multi-customer mode, list each customer account and decide upfront whether each one becomes its own Mailblast workspace or whether you are consolidating into a single workspace (Mailwizz, 2026). Mailblast can hold either pattern as separate workspaces, but multi-brand agency reselling isn't its focus - if managing many client brands is central to your business, BigMailer is the better fit.

Export lists, subscribers, and segments from Mailwizz

Mailwizz exposes subscriber CSV export under Lists > [list] > Tools > Export and supports list-level and segment-level exports separately. Export each list as its own CSV with all custom fields included; for segments, export each segment as a separate CSV so you can re-import as a tag or list in Mailblast. Keep filenames descriptive (list-newsletter-2026-07.csv) so the import phase is unambiguous.

Practical notes from doing this on production installs:

• Choose UTF-8 as the export encoding. Anything else corrupts non-ASCII names and breaks unicode emoji in custom fields.
• Include EMAIL, FNAME, LNAME, plus every custom field tag you noted in the pre-flight. Mailwizz uses uppercase tag names by convention; Mailblast import normalises these.
• Export only confirmed subscribers. Skip unconfirmed, unsubscribed, blacklisted, and bounced statuses unless you have a specific reason - re-importing them re-engages people who should not be reached.
• For lists over ~250,000 subscribers, run the export from the server CLI rather than the browser to avoid PHP timeouts (php /path/to/mailwizz/apps/console/console.php list-subscribers --export ...).

Drop everything into a single working directory. Treat the CSVs as the source of truth for the next step - if anything looks wrong in Mailblast later, re-import from these files rather than going back to Mailwizz.

Import into Mailblast and verify

In Mailblast, create one list per Mailwizz list (keep the same names), define matching custom fields before importing so the column mapper has somewhere to land each column, then upload each CSV. Mailblast import handles around 50,000 rows per file comfortably; split larger lists into chunks. After import, spot-check totals against Mailwizz row counts before moving on - quiet drift here costs hours later.

Two verification steps that catch 80% of import bugs:

1. Compare confirmed subscriber counts per list against the Mailwizz list dashboard. A discrepancy of more than ~0.5% usually means a column got skipped or a row was rejected for a missing email.
2. Pick five random subscribers per list and confirm their custom field values look identical to Mailwizz. Misaligned columns are silent: import succeeds, but birthday ends up in the city field.

Once counts match, freeze new signups into Mailwizz - either pause the public subscribe forms or repoint them at the Mailblast equivalent. From this point forward, Mailblast is the single source of truth for new subscribers.

Recreate templates and customer groups

Mailwizz templates live in MySQL using its own block schema, which does not translate to Mailblast's BeeFree drag-and-drop editor. Plan on rebuilding each active template - in practice this is faster than it sounds because most senders only use 2-4 templates regularly, and the BeeFree library covers most layouts in a few minutes per template.

Workflow that has worked for several senders:

• Open each Mailwizz template, view source, copy the rendered HTML and inline CSS.
• In Mailblast, start a new BeeFree template, drop in matching content blocks (header, hero, body, CTA, footer), and paste copy into each block rather than importing raw HTML. The reflow is intentional - BeeFree's structure gives you mobile-responsive layouts without hand-editing media queries.
• Recreate any Liquid-style merge tags using Mailblast's personalisation syntax. Most Mailwizz merge tags ([EMAIL], [FNAME]) have a direct equivalent.
• Save a "transactional shell" template and a "newsletter shell" template; build all future campaigns from those.

If you used Mailwizz customer groups for internal team separation, Mailblast workspace roles cover the common cases (admin, editor, viewer). Multi-tenant resale via Mailwizz Extended License does not have a direct Mailblast equivalent.

Reconfigure SNS feedback to point at Mailblast

Bounce and complaint handling is the highest-stakes piece of the migration, and the cleanest path is to reuse your existing SNS topics rather than create new ones. AWS publishes bounce and complaint events to whatever SNS topic is configured on your SES configuration set; you simply add Mailblast's HTTPS endpoint as a new subscriber to that topic, confirm the subscription, and remove the old Mailwizz subscriber after a parallel verification window (AWS, 2026).

The order matters:

1. In the AWS SNS console, open each topic Mailwizz currently uses for bounces and complaints.
2. Add a new HTTPS subscription for Mailblast's webhook URL (Mailblast displays this on the SES integration screen). Confirm the subscription within five minutes; AWS expires unconfirmed subscriptions.
3. Verify in Mailblast that the topics show Connected status.
4. Leave the Mailwizz endpoint subscribed for one week as a parallel sanity check. Both apps will receive the same events.
5. After verification, unsubscribe the Mailwizz endpoint and shut down its bounce handler cron job.

If you used SES event publishing (opens, clicks, deliveries) with Mailwizz, repoint the SES configuration set event destination to Mailblast's events endpoint the same way - by adding a new subscription before removing the old one (AWS, 2026).

Test campaign and validate metrics

Send a small production-style campaign to a seed list of 20-50 internal addresses across Gmail, Outlook, Yahoo, and an Apple Mail address. Confirm that opens, clicks, bounces, complaints, and unsubscribes all land in Mailblast within a few minutes, then check the SES console for the same event counts. If both sides agree to within a percent or two, your wiring is correct and you can run a real send.

What to verify on the seed campaign:

• Open and click counts appear in Mailblast reporting and match SES sending statistics within normal tracking latency.
• A test bounce (use a non-existent address at a domain you control) shows up as a bounce in Mailblast within five minutes and the subscriber is automatically suppressed.
• A test complaint (use Mailblast's manual complaint testing tool, or AWS SES mailbox simulator's complaint@simulator.amazonses.com) marks the recipient as complained and removes them from sendable lists.
• Unsubscribe link clicks remove the recipient from the list and the suppression appears in both Mailblast and SES suppression list if you have account-level suppression enabled.

Only after this seed pass should you point a real campaign at a real audience.

Decommission the Mailwizz install

After one week of parallel operation with no discrepancies, you can decommission Mailwizz. Snapshot the database and S3 attachments first - you may want to refer back to old send history for compliance or analytics reasons - then shut down the application cron jobs, remove the SNS subscriptions pointing at the Mailwizz endpoints, and revoke the AWS IAM access keys that Mailwizz was using. Leaving stale IAM credentials in production is a slow-burning security problem.

Checklist for a clean teardown:

• Disable all Mailwizz cron jobs (crontab -e, comment out the Mailwizz lines).
• Take a final MySQL dump and store it in cold storage with the SES region noted.
• Archive a CSV export of every list as a paper trail beyond the database dump.
• Revoke the IAM user's access keys in AWS IAM, then delete the user if it was Mailwizz-specific.
• Spin down the VPS or move the server to a stopped state for 30 days before destroying, in case you missed something.

Edge cases (Mailwizz multi-customer setups, custom field mapping)

Two edge cases trip up otherwise smooth migrations: multi-customer Mailwizz installs and custom fields with non-standard types. For multi-customer setups under the Extended License - which costs $275 one-time and explicitly permits SaaS resale - decide before migrating whether each customer becomes a separate Mailblast workspace or whether you are consolidating (Mailwizz, 2026). Mailblast can hold either pattern, but it isn't built for multi-brand agency reselling the way BigMailer is - keep that in mind if reselling to many customers is core to your business.

Common custom field traps and how to handle them:

• Date fields: Mailwizz exports dates in the format set per field; normalise to ISO 8601 (YYYY-MM-DD) in a spreadsheet before import to avoid parser drift.
• Dropdown / multiselect fields: export as the underlying value, not the human-readable label. Mailblast custom fields are free-text by default; recreate the option list during the field definition step.
• Country fields: Mailwizz stores ISO country codes; keep those rather than substituting full country names.
• Geolocation fields: Mailwizz tracks subscriber IP and geo data per subscriber. Mailblast captures this on its own going forward, so do not bother migrating the historical values.

If you are coming from a similar BYO-SES tool that is not Mailwizz, the same pattern applies - see migrate from Sendy to Mailblast for the Sendy version of this runbook.

Migration phases at a glance

The table below maps the phases above to a realistic time budget for a single-customer Mailwizz install with under 50,000 subscribers and a handful of templates.

Phase	What you do	Typical time	Risk if skipped
1. Pre-flight	Inventory SES identities, IPs, custom fields, SNS topics	15-20 min	Missing context surfaces hours later as broken events
2. Export from Mailwizz	CSV export per list and per segment, UTF-8, confirmed only	10-15 min	Encoding bugs corrupt unicode names and tags
3. Import into Mailblast	Create lists, define custom fields, upload CSVs, reconcile counts	15-25 min	Silent column misalignment, ghost subscribers
4. Rebuild templates	Recreate 2-4 active templates in BeeFree	20-30 min	Inconsistent branding on first production send
5. Repoint SNS	Add Mailblast as new SNS subscriber; confirm	10-15 min	Bounces and complaints stop processing on cutover
6. Test campaign	Send to 20-50 seed addresses; reconcile metrics	15-20 min	Untrusted reporting on first real send
7. Decommission	One week parallel, then teardown and IAM key revocation	10 min (after wait)	Stale IAM credentials, orphaned SNS subscribers

FAQ

How long does a Mailwizz to Mailblast migration actually take?

For a single-customer Mailwizz install with under 50,000 subscribers and a handful of templates, plan on 1-2 hours of focused work. The CSV export and import is fast; most of the time goes into rebuilding templates in the BeeFree editor and reconfiguring SNS topics. Multi-customer Mailwizz setups with many segments and custom fields can stretch to half a day.

Will I lose my Amazon SES sender reputation when I switch?

No. Sender reputation lives on your AWS SES account, not in the Mailwizz database. Verified domains, DKIM records, dedicated IP addresses, and bounce and complaint history all stay attached to the same SES identities. Mailblast simply becomes the new application sending through those identities, so deliverability does not reset on cutover.

Can I import Mailwizz segments directly into Mailblast?

Not as live segments. Mailwizz stores segment definitions in its own MySQL schema, which does not translate to other tools. The workable approach is to export each segment as its own CSV from Mailwizz, then import each one as a separate list or tag in Mailblast and recreate the rule in the Mailblast segment builder if you need it to stay dynamic.

Do I need to keep Mailwizz running during the migration?

Keep Mailwizz running until you have sent at least one production campaign from Mailblast and verified bounces, complaints, and unsubscribes are flowing correctly. A one-week parallel window is enough for most senders. After that, snapshot the database, pull the install offline, and revoke the AWS access keys it was using.

What happens to in-flight Mailwizz automations during cutover?

Mailwizz automations cannot be exported in a format Mailblast can ingest, so any drip sequences need to be rebuilt in the Mailblast automation builder before you cut over. Let any in-flight Mailwizz sequences finish their last step, freeze new enrollments, then enroll new subscribers into the Mailblast equivalents going forward.

---

Disclosure: I work on Mailblast. The pattern above mirrors how we walk customers through Mailwizz migrations; the time estimates come from real cutovers, but your install will have its own quirks. If something in your setup does not fit cleanly into the steps above, ask before you cut over - the SNS rewiring and template rebuild are the two phases worth getting right the first time.