Will my engagement rates drop during migration?

Slightly, yes. New IPs without reputation history get worse placement than mature SaaS pool IPs. Plan for 10-20% engagement dip during weeks 2-4, recovering by week 6-8.

Can I migrate without losing subscribers?

Yes. Subscriber list exports preserve engagement metadata (last open, click, signup source). Suppression list merges from current SaaS plus our hard-bounce hygiene. We verify counts match across the boundary.

PROJECT-SCOPED · 48 HOURS

From shared SMTP to dedicated infrastructure.
Subscribers preserved, no data loss, gradual cutover.

Migrating off SendGrid, Mailgun, Postmark, Amazon SES, or Mailchimp looks simple until you try it. Subscriber lists need to transfer with engagement metadata. Suppression lists need to merge correctly. Authentication keys need to live alongside the old ones during cutover. New IPs need warming because shared-pool reputation doesn't transfer with you.

We do the operation cleanly. 48 hours from kickoff to working stack, then a 1-2 week gradual cutover where production traffic moves incrementally and your old SaaS keeps running until the new infrastructure proves stable. No big-bang day, no surprise downgrades, no list loss.

Order on Telegram → Calculate your savings

price €199

cutover 48h + 2wk ramp

data loss zero

SaaS source any major

why senders migrate

SaaS works fine until it doesn't.

The case for staying on SaaS is real. Subscribers under 30K, low send frequency, no industry sensitivity, no compliance requirements that hosting on US infrastructure would violate. Mailchimp is fine. Stay there. Don't migrate just because someone on a forum said self-hosted is better.

The case for migrating shows up in five fairly distinct situations. Volume past about 50,000 monthly where SaaS per-subscriber pricing starts to dwarf what self-hosted costs. Termination risk in your industry, cold outreach, gambling, certain crypto, certain political mail, lead generation, MLM, adult, pharma, where SaaS providers reserve broad rights to terminate accounts and your business depends on email working tomorrow. Data sovereignty requirements that US-based SaaS can't satisfy: healthcare, legal, finance, government, EU-only regulations. Operational features that SaaS UIs can't express: sophisticated multi-step automations, custom application logic running alongside the email path, multi-brand isolation that a single SaaS account doesn't allow. Reseller economics: running an ESP for your own customers can't sit on top of someone else's SaaS at a viable margin.

The migration itself is a 48-hour technical operation. The decision to do it is usually months of accumulating reasons. By the time customers reach us, they've usually already decided. Our job is to do the operation without losing data, without destroying their reputation during transition, and without surprises afterward.

cost comparison, calibrated to you

SaaS bill vs self-hosted, your numbers.

Set your volume and current provider. The calculator runs the economics: monthly SaaS fee vs total self-hosted cost (server + PowerMTA license + MailWizz license + addons + our migration). Output updates as you adjust.

Monthly send volume 200,000

Total monthly email sends. The calculator interpolates between subscriber-based pricing (Mailchimp) and volume-based pricing (SendGrid, Mailgun, SES).

Current provider

2026 pricing tiers from publicly listed plans. SES baseline is just the per-message cost; we add a realistic ops overhead.

Self-hosted architecture

Server, license, and addons sized to your volume. Includes ASH-managed monitoring and DKIM rotation.

your current SaaS

SendGrid

monthly €420

annual €5,040

Volume-based pricing. Most senders hit overage on at least 2 months per year, adding ~15%.

self-hosted with ASH

Standard production

migration (one-time) €199

monthly recurring €296

annual €3,751

Server + PowerMTA rental + MailWizz Managed + Monitoring. Adjust addons to your needs.

your savings

Year 1 economics

save in year 1 €1,290

payback period 2.6 months

5-year savings €6,650

Includes the €199 migration. Ignores the option value of escaping termination risk and data sovereignty issues, which is harder to put a number on but often the bigger driver.

Numbers are calibrated to publicly listed pricing as of early 2026. Below 50K monthly volume, savings often turn negative, you stay ahead on SaaS at that scale. Past 1M monthly, the savings curve becomes steeper because per-message pricing on SaaS ramps faster than self-hosted infrastructure does. Honest answer: the calculator recommends "stay on SaaS" for about 22% of customers who hit it. That's the calculator working as intended.

how the cutover actually works

No big-bang day. Production traffic moves gradually.

The most common migration mistake is the big-bang switch. Cancel old SaaS Friday afternoon, point production traffic at new infrastructure Friday evening, watch deliverability collapse Monday morning when new IPs without reputation history hit Gmail's volume thresholds. The mistake is structural: shared-pool SaaS reputation doesn't transfer to your new dedicated IPs, and new IPs need warming time before they handle production volume.

Done right, migration is a two-phase operation. Phase one is the 48-hour technical setup: new infrastructure provisioned, authentication published in parallel with the existing SaaS DNS, subscriber data imported, suppression lists merged. Old SaaS keeps sending normally throughout phase one. Phase two is the 1-2 week gradual cutover: a slowly-increasing fraction of production traffic moves to the new infrastructure each day while the new IPs warm up. Engagement metrics watched daily. SaaS gets retired when the new stack proves stable, not on a calendar date.

About 70% of customers cancel SaaS within 14 days of phase one completion. The rest take longer because they're cautious about something specific (transactional volume, regulated content, holiday season approaching). Both timelines are fine. We're not in a hurry to retire your old setup, and we don't bill more for taking longer with the cutover.

honest expectation-setting

What your inbox rate looks like during migration.

New IPs lack reputation history. Engagement dips during weeks 2-4, recovers as receivers see consistent sending behaviour. The chart shows the typical curve we measure across migrations. Hover any point for details.

Inbox rate during migration (median, n=140)

Lowest point, week 3-4 dip

SaaS baseline (pre-migration)

Sample: 140 customer migrations from SendGrid, Mailgun, Mailchimp, and SES, completed 2024-2025, where customers had at least 6 weeks of pre-migration baseline data and ran our standard 8-week ramp. Individual outcomes vary; cold-outreach migrations dip lower (week-3 floor around 60-65%) and recover slightly slower than transactional or opt-in marketing.

honest fit assessment

Who migrates, who shouldn't.

good fit

Volume past the SaaS sweet spot (50K+ monthly) and per-subscriber pricing is starting to hurt. The cost calculator above probably already showed you positive ROI.
Termination risk in your industry. Cold outreach, gambling, certain crypto, certain political mail, lead generation, MLM, adult, pharma. SaaS providers reserve broad rights to terminate; your business needs infrastructure that can't be turned off on someone else's whim.
Data residency requirements your current SaaS doesn't satisfy. EU-only operations, healthcare with HIPAA-adjacent constraints, government work, certain financial services where US-based SaaS is contractually problematic.
Operational features SaaS UIs can't express. Sophisticated multi-step automations with external API calls, custom application logic that needs to run alongside the email path, multi-brand isolation that a single SaaS account can't provide.
Reseller business. Running an ESP for your own customers; this can't sit on top of someone else's SaaS at viable margin.
Multiple SaaS accounts you want to consolidate. One for transactional, one for marketing, one per brand. Self-hosted often consolidates cleaner than juggling three SaaS bills.

poor fit

Volume below 30K monthly. The economics rarely justify migration at this scale. The calculator above shows you the numbers; if it suggests staying, stay.
You don't have engineering capacity to operate the new stack. Migration without ops is worse than staying on SaaS. Either hire, contract, or sign up for our managed addons (MailWizz Managed €49/mo, Deliverability Monitoring €49/mo) to fill the gap.
Your current SaaS works fine and the only motivation is "I read self-hosted is better." Stay on SaaS unless you have a real reason. Migration is operational expense and engineering risk; doing it without justification is bad decision-making.
You expect identical deliverability on day one. The chart above is the reality. Reputation transition takes 30-60 days. If you can't tolerate the dip during weeks 2-4, plan migration for a quieter season.
You're actively in a deliverability crisis right now. Migration during a crisis usually makes the crisis worse. Fix the immediate issue first (Recovery Pack, Blacklist Removal), stabilise, then migrate. Mid-fire is not the time.

before you order

Pre-migration readiness check.

Tick what you have ready. The intake call goes faster when these items are in hand. Don't have all of them? That's fine, we can work around most gaps; the checklist just tells you what to expect.

DNS provider login (read+write) Cloudflare, Route53, Google Cloud DNS, your registrar's DNS, or wherever your domain's DNS lives. We need to publish new records during migration.

SaaS account login or API key For exporting subscribers, suppression lists, and historical campaign data. Read access is fine.

Decision on jurisdiction Bulgaria, Romania, Moldova, Panama, Hong Kong, Singapore, Ukraine, or your own infrastructure. We can recommend if you're unsure.

Decision on PowerMTA license Lifetime (€1499), monthly rental (€99/mo), or you have one already. Postal/Acelle/MailWizz-only paths are also options.

Application access to update SMTP credentials If your application sends transactional mail via SMTP API, you need access to update the credentials when we cut over. SaaS-to-SaaS migrations sometimes get stuck here.

List of all sending domains Including any subdomains used for sending (transactional vs marketing on different subdomains is common). Helps us scope the DKIM and rDNS work.

Recent campaign volume + frequency Approximate average daily sends, peak-day send, normal cadence (daily, weekly, on-demand). Calibrates the warmup schedule for new IPs.

Stakeholder buy-in on the dip Engagement drops 10-20% during weeks 2-4. Your CEO, marketing lead, or board needs to expect this before migration starts, not be surprised by it.

Readiness

Tick items as you confirm them. Any score above 70% and we can scope the migration on the intake call. Below that, we'll spend part of the call gathering missing pieces.

scope of work

Every step of the migration. All of it.

Pre-migration audit

Review of your current SaaS setup. Subscriber count, engagement metrics, suppression list size, sending volume per receiver, current authentication, peak send patterns, content categories. The audit produces a migration plan tailored to your specific situation, not a generic checklist.

Findings that affect migration planning surface here. Single-sender business needs different infrastructure than multi-brand reseller. Cold-outreach senders need different warmup logic than opt-in marketing. Transactional volume needs different priority routing than promotional batch sending.

Subscriber and suppression export

Subscribers exported with full engagement metadata. Last open timestamp, last click timestamp, signup source, custom fields, segment memberships, tag history. Imported into MailWizz preserving every column. We verify counts match across the boundary, not just totals, sometimes SaaS exports drop dormant or unsubscribed subscribers silently and the count looks right but real subscribers are missing.

Suppression list merged from current SaaS exports plus our standard hard-bounce hygiene. Hard-bounces from old SaaS are bounces in new infrastructure too; this prevents you from hitting the same dead addresses again on day one of new sending.

Provider-specific export tooling: SendGrid's contact export API, Mailgun's mailing-list dump, Mailchimp's audience export, Klaviyo's list manager. Each provider has its own quirks; we know them.

Authentication parallel-publishing

Your current SaaS keeps sending normally during the entire transition. We publish new DKIM keys for the new infrastructure under fresh selectors that don't conflict with your existing SaaS-managed selectors. SPF gets new IPs added without removing old SaaS includes. DMARC stays valid throughout.

No window where authentication breaks. Both old and new are authoritative simultaneously, then old gets removed only after new is proven and SaaS is retired.

New infrastructure provisioning

PowerMTA + MailWizz (or Acelle, on request) provisioned in your chosen jurisdiction. Custom rDNS configured per IP, FCrDNS verified. FBL inboxes connected and parsing. Same baseline as our standalone Setup service, integrated into the migration timeline rather than sold separately.

Test campaigns sent through the new stack to verify pipeline before production traffic is routed. Each major receiver checked for authentication pass and acceptance.

Warmup planning and execution

New dedicated IPs need warming. Your existing reputation lives on shared-pool IPs that you can't take with you. We document and execute the warming schedule: logarithmic ramp from 50 to ~5,000 daily per IP over 30 days, with engagement-network seeding during early phases.

For migrations with multiple sending streams (transactional + marketing, or multiple brands), each stream warms on its own schedule. Skipping warmup is the most common migration mistake; we don't allow it as a shortcut even if you ask.

Cutover orchestration

Production traffic moves gradually, not all at once. We split sends across old SaaS and new infrastructure during the 1-2 week ramp. 20% on new infrastructure in week 1, 50% in week 2, 80% in week 3, 100% in week 4 if engagement metrics support it.

Engagement metrics watched daily through Postmaster Tools, SNDS, and our 84-RBL monitoring. If specific receivers degrade beyond expected warmup curves, we slow the ramp and investigate. Old SaaS gets retired only after new infrastructure shows stable placement at all major receivers, not on a calendar date.

Post-cutover stabilisation

14 days after full cutover, we run a stabilisation review. Postmaster Tools and SNDS trends checked against pre-migration baseline. Any specific receivers still showing degradation get targeted remediation. Final report documents what changed, what's stable, and what to monitor going forward.

Optional follow-on with our Deliverability Monitoring addon (€49/mo) for ongoing reputation tracking. Most migration customers add at least one ongoing addon within 30 days of cutover; the most common is monitoring.

Documentation handover

Operations runbook covering the migrated infrastructure: every credential, every config file, every cron schedule, every backup job. Migration-specific documentation: which old DNS records were replaced, which were merged, which old SaaS configurations are still receiving fallback traffic if any. Recovery procedures.

30-minute Telegram or Jitsi handover with your team. Walkthrough of the new stack and the migration changes specifically. Recording available on request.

migration timeline

From order to fully retired SaaS.

Day 0

Audit + plan

Telegram intake. Read access to current SaaS. Migration plan drafted, scope confirmed, timeline locked. NDA signed.

Day 1

Infrastructure

New stack installed. Authentication published in parallel with current setup. New IPs ready but not yet sending production volume.

Day 2

Data migration

Subscribers and suppression list moved with engagement metadata preserved. Verification of completeness. Test campaign through new stack.

Days 3-14

Gradual cutover

Traffic split between old and new with daily increases. New-IP warmup running in parallel. Engagement monitored daily. SaaS retired when stable.

Days 15-30

Stabilisation

100% on new infrastructure. Reputation building toward and past SaaS baseline. Final review at day 30 with metrics handed over.

questions before you order

Frequently asked.

Will my engagement rates drop during the migration?

Slightly, yes. The chart above shows the typical curve. New IPs without reputation history get worse placement at receivers than mature SaaS pool IPs. The drop typically lasts 30-45 days and bottoms around week 3-4 at roughly 70-75% inbox rate vs 90-94% baseline. By week 6-8 you're back at or above baseline because dedicated IPs usually outperform shared SaaS pools by a few percent once warmed.

Plan for the dip. Set expectations with your CEO, marketing lead, or board before starting, not when they ask why open rates are down in week 3. Most migration regret comes from unmet expectations, not from technical failure.

Can I do this myself?

Yes, if you have an experienced deliverability engineer and 60-80 hours to dedicate. The work is well-documented across PowerMTA's manual, MailWizz's docs, and various deliverability blogs. Most teams that try it end up either taking 4-6 weeks instead of 2 days or making mistakes that cause months of reputation damage. The most common failure mode: skipping or shortening warmup. The second most common: importing suppression lists incompletely.

The €199 fee is a bet that one of those mistakes costs more than the fee. For most volumes above 50K monthly, that bet is correct.

What about the API? My application calls SendGrid's send endpoint.

You change the SMTP credentials in your application config to point at the new MTA. MailWizz has its own API for transactional sends if you need parity with SendGrid's REST API. Most migrations are straightforward at this layer; some custom integrations need code changes. We surface API-level work in the audit so you can plan engineering time.

My SaaS bill is €2K/month. What's the new economics look like?

Self-hosted infrastructure for that volume is typically €300-600/month all-in (server + license + monitoring). Payback on migration cost is 2-4 weeks at that volume. Above €5K/month SaaS bills, the payback is in days. Below €500/month SaaS bills, the math gets tighter and staying on SaaS is often correct. The calculator above runs your specific numbers.

Can I migrate from one SaaS to another (Mailchimp to ConvertKit)?

Yes, but that's a different operation. SaaS-to-SaaS is much simpler because both providers handle their own infrastructure; you just move subscriber data. We do this for €99 (subscriber export + clean import + suppression merge, no infrastructure work). Mention "SaaS-to-SaaS" at intake so we route correctly.

I have multiple SaaS accounts (transactional + marketing). Can you consolidate?

Yes. Consolidation often makes the economics even better since one self-hosted stack replaces two SaaS bills. The migration is slightly more complex (two source datasets to merge correctly) but the operation is the same. Tell us at intake which providers and roughly what volume each handles.

What happens if migration goes wrong mid-cutover?

Mid-cutover is the easiest place to recover from issues because old SaaS is still active. If new infrastructure shows degraded placement beyond expected curves, we pause the ramp and investigate. Worst case, traffic stays on old SaaS while we fix the issue, then we resume. We've never had a migration where customers couldn't keep sending; we've had migrations where the cutover took 4 weeks instead of 2.

Do I need to cancel SaaS before migration?

No. Don't cancel until full cutover is stable. Most customers downgrade their SaaS to the lowest tier during weeks 1-2 (still handling some traffic) and cancel at week 4 or 5 once new infrastructure is fully proven. SaaS providers don't refund mid- month, so timing the cancellation against your SaaS billing cycle saves a few hundred euros for most customers.

What about data residency and GDPR?

Self-hosted gives you complete control over where subscriber data lives. EU jurisdiction (Bulgaria, Romania, Moldova, optionally Ukraine) for GDPR-friendly hosting. Non-EU jurisdictions if you specifically want to escape EU data-protection regimes. We document data residency in your handover so your DPA filings are clean.

How does payment work?

Standard process: half upfront (€99) on intake, half (€100) on full cutover completion. Payable in any of our 11 supported cryptocurrencies. Self-hosted BTCPay, no third-party processor, no KYC. If scope expands during the project (you decide to also migrate a second brand, or you have 50 sending domains instead of 5), we quote the expansion before doing the work.

also relevant

Related services and references.

Common migration scenarios and how each runs

Migration engagements vary substantially based on source and target combinations. The scenarios below capture the patterns we have completed most frequently across customer migrations.

Hosted ESP to self-hosted infrastructure: typical scope covers data extraction from the hosted platform (subscriber lists, segment definitions, historical campaign data), translation to self-hosted format, validation testing, parallel operation during cutover, decommissioning. Timeline runs 6-10 weeks for typical scope.

Self-hosted to managed infrastructure: typical scope covers infrastructure assessment, migration of existing configuration to managed equivalent, parallel operation during reputation warmup, customer team training on new operational patterns. Timeline runs 4-8 weeks depending on configuration complexity.

Cross-platform self-hosted (e.g., MailWizz to Acelle, custom to standard): typical scope involves substantial data translation because platforms structure subscriber data, segment logic, and reporting differently. Timeline runs 8-14 weeks reflecting the translation complexity.

Cross-jurisdiction migrations: typical scope adds infrastructure provisioning in target jurisdiction, DNS coordination across registrars where applicable, regulatory considerations specific to the target jurisdiction. Timeline runs 8-16 weeks depending on whether the jurisdiction change accompanies platform changes or operates independently.

Ready to leave shared SMTP?

Telegram intake takes 30 minutes. 48-hour technical setup follows. The 2-week gradual cutover starts when you're comfortable; we don't push. Median customer outcome: full cutover completed within 21 days, fully recovered to baseline within 45.

Order on Telegram → Submit ticket

# Median Telegram response: 12 minutes during operating hours