Migrate from Sendy: keep your SES, lose the server

Why it's easy

The delivery layer doesn't move — because it's already yours

Every other migration guide on this site has a section about re-verifying domains or warming up a new sending path. This one doesn't need it. You chose Sendy because you wanted SES's delivery prices on your own infrastructure — SendOps keeps exactly that arrangement. It's provisioned into the same AWS account via CloudFormation (STS-only, no stored keys), imports your existing SES configuration non-destructively, and sends through the domains and reputation you've already built. Both tools can send side by side during the switch.

What you're actually migrating is the application layer: lists, autoresponders, templates — and the PHP server they live on. That server is the real cost of Sendy: hosting, patching, MySQL backups, cron jobs, and being your own on-call. For the feature-level side-by-side, see the Sendy comparison and how SendOps turns SES into a marketing platform.

The migration path

Six honest steps — no magic importer

There's no one-click Sendy importer, from us or anyone. But because delivery doesn't move, this migration is short: export CSVs, rebuild a handful of autoresponders and templates, and turn off a server. Most Sendy setups finish in an afternoon.

1. 1

   Connect SendOps to the same AWS account Sendy uses

   Run the CloudFormation template in the AWS account Sendy has been sending from — about two minutes. SendOps imports your existing SES setup non-destructively: verified domains, configuration, reputation, all untouched and still available to Sendy while you migrate. SendOps never holds your AWS keys; access works through STS and a scoped IAM role you control. If you're reading this without SES set up yet, start with the SES setup guide. Amazon SES setup guide .

2. 2

   Export your lists from Sendy, import your contacts

   Export each Sendy list as CSV — including unsubscribes, so consent history carries over — and import into SendOps, or push contacts through the API. Custom fields map to typed attributes; list membership becomes an attribute you can query. How contacts and segments work .

3. 3

   Rebuild segments in SendQL

   Sendy segments are rewritten as SendQL queries. Sendy's segmentation is simple by design, so most segments are one or two conditions and translate in seconds — and SendQL can then go further than Sendy ever could, querying events and send activity as well as fields.

4. 4

   Rebuild autoresponders in SendFlow

   Autoresponders are rebuilt, not imported. Sendy autoresponders are time-based drips — 'email 1 on signup, email 2 after 3 days' — which map to the simplest possible SendFlow workflows. The text DSL makes each one a few lines a coding agent can draft, and the visual canvas lets you verify the sequence before activating it. SendFlow workflows .

5. 5

   Port your templates

   Rebuild templates as React Email components — which SendOps compiles to SES-native Handlebars — or directly in Handlebars if you prefer to paste and adapt your existing HTML. Sendy personalization tags become attribute references, and Sendy's unsubscribe link is replaced by SendOps topics and branded unsubscribe pages.

6. 6

   Run in parallel, then decommission the PHP server

   Because both tools send through the same SES account, you can run them side by side with zero delivery risk — no warm-up, no DNS changes, no reputation reset. Send a broadcast or two from SendOps, confirm the autoresponder rebuilds behave, then switch off Sendy's cron jobs, snapshot the database, and terminate the server. That's the last PHP update you'll ever apply to your email stack.

The win

Everything you liked about Sendy, minus the parts you didn't

Sendy's appeal was always the economics: SES delivery prices instead of SaaS markups. SendOps keeps the economics and removes the operational tax: