Sendy to Mailblast Migration: Full Walkthrough

Migrating from Sendy to Mailblast is mostly a CSV export, a CSV import, and one SNS webhook repoint - usually 30-60 minutes for a single list under 20,000 contacts. Because both tools sit on top of your own Amazon SES account, none of the heavy infrastructure moves: your verified domain, DKIM keys, dedicated IPs (if you have any), and your sender reputation all stay attached to the same AWS account that SES uses to calculate the rolling bounce and complaint rates that drive deliverability (AWS, 2026).

Plan closer to half a day if you have live drip campaigns, multi-brand setups, or custom subscriber fields that need remapping. The CSV step is fast; rebuilding templates and rewiring SNS are where time goes.

For background on how the two tools compare before you commit, see the Sendy vs Mailblast breakdown and the broader Sendy alternatives on Amazon SES roundup.

Pre-flight checklist

Amazon SES judges every account on bounce and complaint rates calculated over a rolling window, with the warning band starting at a 0.1 percent complaint rate and 5 percent hard bounce rate (AWS, 2026). A migration that ignores existing Sendy suppressions can push a previously clean account past the complaint threshold in a single send, so the protective work happens before anything moves.

You'll need: AWS Console access, the IAM user credentials Sendy currently uses (so you can audit permissions), the ARN of your existing SNS bounce/complaint topic, a fresh export of your unsubscribers and hard-bounced segments, and a copy of your most-recent campaign HTML. Note your current SES sending quota too - Mailblast respects the same quota and does not request an increase on your behalf.

Phase	What happens	Time estimate
Pre-flight	Audit IAM, SNS topic, unsubscribers, current templates	15 min
Export	Download active and unsubscribed subscriber CSVs from Sendy	5-10 min
Import	Upload suppression list, then active list into Mailblast	10 min
Templates	Rebuild 1-3 templates in the BeeFree drag-and-drop editor	20-45 min
SNS webhook	Repoint bounce and complaint subscriptions to Mailblast	5 min
Verify	Send a small test campaign, confirm events flow	15-30 min
Decommission	Archive Sendy DB, revoke old IAM keys, shut down PHP host	10-20 min

Step 1 - Export subscribers from Sendy

Sendy's marketing page lists CSV import and export of subscribers as a first-class feature, with mass import, mass delete, and per-segment export available to admins (Sendy, 2026). In the admin UI this surfaces as a per-list export to CSV, one export per list per status: active, unsubscribed, bounced, and unconfirmed.

Log in to your Sendy admin, open each list, and run three exports per list:

1. Active subscribers - the main file you'll import to Mailblast.
2. Unsubscribed - your suppression list. Critical: never skip this.
3. Bounced (hard) - import these as suppressions too so SES doesn't see them re-attempted.

Sendy's CSV uses email, name, and any custom fields you defined, one row per subscriber, UTF-8 encoded. Open one file in a text editor (not Excel - it'll mangle UTF-8) and confirm the header row looks sane and there are no stray BOM bytes. If you have multiple lists, keep them in separate files; you'll recreate the list structure in Mailblast in step 2.

Step 2 - Import to Mailblast and verify lists

Import order matters because Mailblast checks every incoming address against your account-wide suppression list before adding it to any list, which mirrors the AWS rule that complaint rates are calculated across all sending from your SES account and not per campaign (AWS, 2026). Get suppressions in first so a previously-unsubscribed address doesn't sneak back into an active list.

1. In Mailblast, create one list per Sendy list, keeping names consistent so any reports you've shared internally still match.
2. Upload your unsubscribed and hard-bounced CSVs as suppressions first (the import dialog has a "treat as suppression" toggle).
3. Upload each active CSV into its matching list. Map email and name automatically; map custom fields manually if you used them in Liquid templates.
4. Spot-check the count after each import - if Mailblast shows fewer contacts than Sendy did, the delta is almost always rows blocked by your fresh suppression file. That's correct behaviour.

Step 3 - Recreate templates in Mailblast

Sendy stores campaigns as raw HTML with its own merge-tag syntax ([firstname,fallback=there]), while Mailblast uses the BeeFree drag-and-drop editor with Liquid personalisation ({{ subscriber.first_name | default: "there" }}). There's no automatic converter for this because the underlying models differ - Sendy gives you a textarea, Mailblast gives you content blocks.

For each campaign template you actually reuse (most Sendy users have one or two):

• Paste the rendered HTML into a "blank HTML" block in Mailblast to preview the layout.
• Rebuild the same structure with BeeFree blocks (header, hero, text, button, footer). It's faster than it sounds - 15-30 minutes per template.
• Replace every [tag] merge field with the Liquid equivalent.
• Add the Mailblast unsubscribe footer block. Sendy's [unsubscribe] link doesn't carry over.

If you only send plain newsletters, skip BeeFree entirely and paste your HTML into the raw-HTML block - that maps closest to Sendy's workflow.

Step 4 - Reconfigure SNS bounce/complaint webhook for Mailblast

AWS recommends wiring bounce and complaint feedback through SNS topics with HTTPS subscribers so the management layer can suppress affected addresses before the next send batch goes out (AWS, 2026). Sendy ships with a /sendy/_autoresponders style endpoint registered with your existing SNS topic; Mailblast provides its own HTTPS endpoint and signs incoming requests with an account secret you generate in the SES settings screen.

In the AWS Console:

1. Open SNS → your existing bounce/complaint topic.
2. Add a new HTTPS subscription with the Mailblast webhook URL shown in your Mailblast SES settings page.
3. Confirm the subscription (Mailblast auto-confirms within a few seconds).
4. Send a single test bounce using the SES mailbox simulator (bounce@simulator.amazonses.com) - check that the event appears in Mailblast's event log within 30 seconds.
5. Once confirmed, delete the old Sendy HTTPS subscription from the same topic. Leaving both subscribed means Sendy re-marks the bounce locally, which is harmless but confusing.

Don't delete or recreate the SNS topic itself - the topic ARN and the SES configuration set that points at it stay the same.

Step 5 - Send a verification campaign

AWS recommends a small segmented send before any reputation-sensitive cutover, because bounce and complaint data from the first 1,000 to 5,000 recipients is what feeds the SES reputation dashboard signal that drives throttling decisions (AWS, 2026). Treat the first Mailblast campaign as a deliberate canary, not a real send.

Build a one-paragraph "we've moved our newsletter system, no action needed" message, target a 500-1,000 subscriber segment of your most-engaged contacts (recent openers), and schedule it. Then watch four signals over the next hour:

• Mailblast's per-campaign dashboard for opens, clicks, and bounces.
• The SES sending statistics page in the AWS Console for matching numbers.
• The bounce and complaint rate dashboard in SES - both should stay flat.
• Your inbox for any reply-to bounces or autoresponders that look unusual.

If all four look clean after an hour, schedule the rest of the list.

Decommissioning the Sendy install

Sendy is a self-hosted PHP application backed by MySQL, so decommissioning is more involved than just deleting an account. Do this in a controlled order to keep an audit trail in case you need to reference historical campaign data.

1. Export the MySQL database (mysqldump sendy > sendy-backup-YYYY-MM-DD.sql) and store the dump alongside any campaign assets in cold storage (S3 Glacier is fine).
2. Revoke the IAM access keys Sendy used for SES. Don't just delete the IAM user yet - revoking keeps the user in CloudTrail history.
3. Delete the old SNS HTTPS subscription pointing at Sendy's domain.
4. Shut down the EC2 instance, droplet, or shared host running Sendy.
5. Decommission the database if it was on a separate instance.
6. Update your DNS if Sendy was on a subdomain like mail.example.com - either repoint it at Mailblast or remove the record entirely.

Keep the backup for at least 12 months. Some jurisdictions require demonstrating when a subscriber consented, and Sendy's subscribers table is your only record of that.

What can go wrong (CSV encoding, missing fields)

The two issues that bite most Sendy migrations are CSV character-encoding mismatches and merge-field gaps - both are recoverable, but only if you catch them before the first 500-recipient verification send. Sendy exports as UTF-8, but the moment a CSV passes through Excel on Windows it can be silently re-saved as Windows-1252, which mangles every accented character in name fields and gives downstream subject-line personalisation literal ? characters.

Watch for:

• ? characters in imported names. That's the UTF-8 to Windows-1252 conversion. Re-export from Sendy, open in a plain text editor (VS Code, BBEdit), and re-import.
• A BOM at the start of the file. Some Mailblast importers will treat the first column header as email instead of email. Strip with sed -i '1s/^\xEF\xBB\xBF//' file.csv.
• Custom fields landing in the wrong column. Sendy doesn't enforce column order across exports - map every column manually rather than relying on auto-mapping.
• Empty merge tags in the first campaign. Usually because a Sendy [firstname,fallback=] had an empty fallback. Set a Liquid default in Mailblast: {{ subscriber.first_name | default: "there" }}.
• Double-opt-in confirmations re-triggering. Disable double opt-in on the destination list before importing - your contacts already confirmed once in Sendy.

If any of these cause a noticeable bounce spike in the verification campaign, pause the rest of the rollout and clean the source CSV. SES gives you very little grace once you cross the warning thresholds.

What changes (and what doesn't) when you move to Mailblast

Mailblast is a hosted management layer for your own Amazon SES account (BYO-SES), not a hosted ESP that pools senders through shared SES infrastructure - the IAM credentials Sendy used can be reissued to Mailblast on the same AWS account, and SES treats the traffic as continuous. The drag-and-drop editor (powered by BeeFree), automation flows on every paid plan, CSV import and export, double opt-in handling, unsubscribe management, and recipient-level event tracking replace the pieces of Sendy you'd otherwise have to patch together. Landing pages and A/B testing are not included, so if those drove your evaluation, factor them in before cutting over.

The Mailblast free plan covers 1,000 contacts and 10,000 emails per month, which is enough to run the verification campaign without committing to a paid tier. Paid plans start at $10 per month for that same 1,000 contacts and add automation plus unbranded sending. The SES per-1,000 cost stays the same because the sends still leave from your AWS account.

FAQ

Will my AWS SES sender reputation reset when I switch from Sendy to Mailblast?

No. Sender reputation is bound to your AWS account, verified domain, and the IPs the SES regional pool assigns you - none of which change when you swap the management layer in front of SES. Both Sendy and Mailblast send through your same SES account, so warm-up history carries over without interruption.

How long does a typical Sendy to Mailblast migration take?

Around 30-60 minutes for a single list under 20,000 contacts with one or two templates. Plan half a day if you have active drip campaigns, multiple brands, or custom fields that need remapping. The CSV import itself is usually the fastest part - reconfiguring SNS webhooks and rebuilding automations takes the most time.

Do I need to re-verify my domain in Amazon SES?

No. Your SPF, DKIM, and DMARC records stay in DNS, and SES still recognises your verified identity. You only need to give Mailblast IAM credentials with SES send permissions and point your SNS bounce or complaint topic at the new Mailblast webhook URL.

What happens to subscribers who unsubscribed in Sendy?

Export them as a separate suppression CSV from Sendy's unsubscribers segment, then import that list into Mailblast as a suppression file before importing your active subscribers. This prevents anyone who opted out from receiving the first Mailblast campaign - critical for staying under the AWS 0.1 percent complaint threshold.

Can I run Sendy and Mailblast in parallel during the cutover?

Yes, but only briefly. Both can send through the same SES account simultaneously, however SNS bounce or complaint notifications can only point to one webhook at a time. Run the parallel period for a single test campaign, confirm Mailblast is recording events correctly, then decommission Sendy.

---

Disclosure: Mailblast publishes this blog and is one of the destinations described above. The mechanical steps - CSV export, SNS repoint, decommission - work the same way for any BYO-SES tool you choose to migrate to.