Deliverability · Migration service

Email infrastructure migration as a flat-rate engagement, with the boring reputation-preservation work that consultants usually skip

A managed email migration moves your sending from one provider or self-hosted stack to another while preserving sender reputation, authentication and suppression data. OS Domains runs migrations off SendGrid, Mailgun, Amazon SES, Postmark and Mandrill as a flat-fee engagement: six overlapping phases across roughly four to eight weeks, with gradual parallel-sending cutover and a 30-day warranty, so deliverability does not crater mid-move.

Most email migration consultants charge by the hour, hand you a runbook, walk away after cutover, and leave you to figure out warming and reputation work yourself. We charge a flat rate, execute the migration end to end, include IP warming on the new infrastructure as part of the engagement, and protect your sending reputation through the cutover with a gradual transition rather than a cliff. From €499 for the architecture plan, €2,499 for a standard single-platform migration, €5,999 for multi-platform with stream separation. Same engineering team that has been operating email infrastructure since 2008.

In short

Six phases over about four to eight weeks: discovery, runbook, new-infrastructure setup, gradual cutover, IP warming, and a closing review with a 30-day warranty.
Gradual parallel-sending cutover (5-10% then 25-30%, 50-70%, then 100%) is what protects reputation; the old infrastructure runs down while the new one warms.
Flat-fee engagements: €499 (Discovery + Plan), €2,499 (Standard) and €5,999 (Multi-Platform), plus custom for complex moves — no hourly billing.
Documented playbooks for the common sources: SendGrid, Mailgun, Amazon SES, Postmark and Mandrill / Mailchimp Transactional.
DMARC alignment, DKIM key rotation and suppression-list integrity are carried through cutover, not left to chance.

See engagement sizes Talk to a deliverability engineer

The cutover

How does the parallel-sending cutover work?

Traffic moves to the new infrastructure in stages rather than as a single switch. The new platform earns reputation through controlled, rising volume while the old one keeps its reputation as it winds down, so any issue surfaces before it reaches all of your mail. The diagram shows the ramp.

Mid-cutover, authentication is validated on both paths — the new DKIM selector resolves, SPF includes both providers during overlap, and a probe send returns a queued ID on the new infrastructure:

$ dig +short TXT osd._domainkey.yourdomain.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
$ dig +short TXT yourdomain.com | grep spf
"v=spf1 include:_spf.oldprovider.com include:spf.osdomains.com -all"
$ swaks --server smtp.osdomains.com:587 --tls --auth LOGIN --to [email protected]
<- 250 2.0.0 Ok: queued as 7a2bE19xK0

What this service actually is

A managed migration with reputation preservation, executed for a flat fee

Most senders running serious email volume eventually face a migration. The reasons vary. SendGrid pricing crossed the threshold where self-hosted becomes cheaper, around 1M emails per month. The acquisition of Mailchimp Transactional (Mandrill) by Intuit pushed users to look elsewhere. The Cloud Act exposure of US-based ESPs became a procurement question for European customers. The product team needs separation between transactional and marketing streams that the existing platform cannot deliver. The reasons are operational, the work is technical, and the pain is concentrated in a few weeks of cutover during which reputation can be lost faster than it took years to build.

The migration consulting market in 2026 has two main shapes. First: hourly consulting from independent specialists or boutique agencies, typically €120 to €250 per hour, usually scoped at 30 to 80 hours for a typical mid-market migration. Total cost lands somewhere between €4,000 and €15,000 depending on complexity, and the customer takes on the cost uncertainty because consultants cannot predict edge cases up front. Second: managed migration services from ESPs themselves (Mailgun publishes a free SendGrid migration guide and offers paid implementation help, similar pattern from most major ESPs), which is fine if you are migrating to their platform but does not help if you are leaving them or going self-hosted.

We sit between those two with flat-rate pricing and platform-agnostic execution. The migration runs end-to-end whether you are moving SendGrid to Mailgun, Mailgun to AWS SES, anything to PowerMTA self-hosted, KumoMTA self-hosted, or to our own infrastructure (a small fraction of customers; we do not push our own platform during migration scoping). The flat-rate covers the architecture work, the cutover execution, the reputation preservation playbook during transition, and the IP warming on the new infrastructure once cutover is complete. No hourly billing, no scope-creep surprises, no separate warming fees after the migration "completes" but reputation has not stabilized.

Honest framing about the value proposition. Migration work is mostly boring infrastructure plumbing: DNS record updates, API endpoint changes, template re-formatting, suppression list transfer, webhook reconfiguration, and the operational details that make sending continue to work after the cutover. None of it is conceptually difficult; all of it is detail-heavy and requires someone who has done it before. The value we add is not technical wizardry; it is the absence of mistakes during a high-stakes cutover. A botched migration can lose 2 to 4 weeks of reputation, miss customer-facing emails during the gap, and require expensive recovery work afterward. A well-executed migration is invisible to your customers and looks anticlimactic from outside. The boring outcome is the product.

And honest about scope. We do not migrate marketing automation logic (that is your marketing team's work). We do not rewrite your application code (that is your engineering team's work). We do not set up new ESPs from scratch as their first customer (we work with established platforms). We focus tightly on the email infrastructure layer: domains, DNS, authentication, IPs, MTAs, ESPs, sending reputation. The customer team handles the application-side changes; we handle the infrastructure-side changes; the cutover plan coordinates the two. Most migrations work this way naturally because the application changes and the infrastructure changes have different review cadences and ownership.

One last clarification. This is the entry point for many customers. About 60 percent of migration customers continue with us afterward through some combination of /deliverability-monitoring, /managed-dmarc, or one of the sending products (/smtp-relay, /email-sending-servers, /cold-email-infrastructure). The cross-sell is natural rather than aggressive: customers who experienced our migration work tend to want our ongoing operations work, and the post-migration state is well-suited for monitoring subscriptions because the baseline is fresh and well-documented. Customers who do not want any ongoing relationship after the migration are equally fine; the migration engagement is self-contained and we do not retain any operational dependency on you using our other products.

And worth saying about the timing pressure most migrations carry. By the time a sender contracts a migration, the decision is usually 2 to 6 months overdue. The pricing change at the old ESP that triggered the move happened a quarter ago. The Cloud Act compliance question came up in a sales conversation the previous month. The transactional/marketing separation has been on the engineering roadmap for half a year. Migration work tends to slip because nothing is broken yet; the existing infrastructure works fine and the team has higher-priority work to do. We are familiar with the pattern and we structure engagements assuming customers arrive somewhat behind schedule. The Standard Migration timeline (4 to 6 weeks for the full engagement, including warming) is calibrated to be the right balance between thorough execution and the timeline pressure most customers arrive with. Faster is sometimes possible but rarely advisable; slower is sometimes necessary for unusual scope.

Migration scenarios we have actually executed

Six common patterns, each with documented playbooks and known pitfalls

Below are the migration patterns we encounter most often. The flat-rate pricing assumes the migration matches one of these patterns or a near variant; significantly unusual migrations get scoped as Custom engagements with custom pricing.

Scenario 01

ESP-to-ESP migration (SendGrid to Mailgun, Mailgun to SES, etc.)

The most common scenario. You are leaving one ESP for another, usually for cost or feature reasons. The work covers API endpoint changes, suppression list transfer, template re-formatting where needed, webhook reconfiguration, DNS record updates with DKIM rotation, and the gradual traffic cutover that protects reputation on both old and new infrastructure during transition. Standard Migration pack covers single-domain ESP-to-ESP within typical complexity. Multi-domain or multi-stream falls into Multi-Platform Migration.

Scenario 02

ESP-to-self-hosted migration (SendGrid to PowerMTA, Mailgun to KumoMTA)

For senders crossing the volume threshold (typically 1M+ emails per month) where self-hosted becomes cheaper than ESP. Adds infrastructure setup work: MTA installation, configuration tuning, IP procurement and rDNS configuration, monitoring stack integration, suppression list import. Standard Migration covers ESP-to-self-hosted within typical scope; multi-IP or complex routing falls into Multi-Platform Migration. We have detailed playbooks for PowerMTA, KumoMTA, MailerQ, Postal, and Postfix targets.

Scenario 03

Stream separation migration (combined to transactional + marketing split)

Senders who started on one platform for everything and need to separate transactional from marketing because reputation cross-contamination is hurting both. Often combined with ESP changes (transactional to Postmark, marketing staying on existing platform; or transactional staying on existing platform, marketing moving to dedicated). Multi-Platform Migration scope; the work involves splitting domains, splitting IPs, splitting authentication, splitting suppression handling. Stream separation typically improves placement on both streams within 30 days.

Scenario 04

Cloud-to-on-prem (or on-prem-to-cloud)

Architectural shifts driven by cost, compliance, or operational reasons. Cloud-to-on-prem usually targets KumoMTA or PowerMTA on Hetzner-class infrastructure for cost optimization at high volume. On-prem-to-cloud usually targets SES, Mailgun, or our own infrastructure for operational reasons (reducing maintenance burden, getting professional support). The infrastructure changes are larger than ESP-to-ESP but the email-layer work is similar; both fit in Multi-Platform Migration unless complexity warrants Enterprise scoping.

Scenario 05

Mandrill / Mailchimp Transactional refugees

A specific pattern that comes up regularly since the Intuit acquisition disrupted Mailchimp Transactional pricing and capabilities. Customers leaving Mandrill typically have years of webhook integrations, template logic, and operational tooling assuming the Mandrill API. The migration is more delicate than standard ESP migration because the Mandrill-specific behaviors (template merge syntax, webhook event types, smart routing rules) need translation rather than direct mapping. Standard Migration covers smaller Mandrill departures; larger ones fit Multi-Platform.

Scenario 06

Reputation-driven migration after an incident

Sometimes the reason to migrate is reputation damage on the existing infrastructure that cannot be recovered (or that recovery would take longer than building a new clean setup). This overlaps with our /reputation-recovery product but is structurally different: the goal is not to fix the broken infrastructure but to leave it cleanly while building a clean new one. The migration includes coordinated wind-down on the old infrastructure (so customers do not experience hard cutover failures) and full warming on the new. Multi-Platform Migration scope; coordinates with /reputation-recovery if both apply.

How the migration actually runs

How long does an email migration take?

A managed migration runs about four to eight weeks across six overlapping phases. Migration work is not strictly linear; phases overlap because some preparation can happen while other work is in progress. The phases below describe what gets done; the actual timeline depends on engagement size and your team's availability for the customer-side work.

Discovery and architecture review (week 1)

A 90-minute call with your engineering and operations leads. We capture the current architecture (which ESPs, which domains, which IPs, which authentication setup, what application code patterns), the target architecture (where you want to end up), the constraints (timeline pressure, regulatory requirements, dependencies on other systems), and the success criteria. Output is a written architecture document covering current state, target state, and the gap analysis. The Discovery + Plan product (€499) covers Phases 1 and 2 only and stops here.

Migration plan and runbook (week 1-2)

The detailed runbook your team uses for cutover. Covers DNS changes with timing, application code changes by component, suppression list transfer mechanics, webhook reconfiguration, IP warming schedule for the new infrastructure, rollback procedures if something fails, communication plan for customer-facing changes. The runbook is opinionated about ordering and timing because migration failures usually come from the wrong sequence rather than missing steps. Discovery + Plan product ends here; customers using that product execute the rest themselves.

New infrastructure setup (week 2-3)

Provisioning the destination platform. For ESP destinations: account setup, domain verification, sender authentication configuration, suppression list import, webhook configuration. For self-hosted destinations: MTA installation and tuning, IP allocation and rDNS configuration, monitoring stack integration, security hardening. The work happens in parallel with continued sending on the old infrastructure; nothing user-visible changes during this phase. Standard Migration and above include this work.

Gradual cutover with parallel sending (week 3-4)

The actual transition, executed gradually rather than as a cliff. Day 1 of cutover: 5 to 10 percent of traffic moves to the new infrastructure. Day 3 to 5: 25 to 30 percent. Week 2: 50 to 70 percent. Week 3 to 4: 100 percent on new, old infrastructure decommissioned. The gradual cutover is what protects reputation: the new infrastructure builds reputation through controlled volume, the old infrastructure keeps reputation while it runs down, and any issues caught during cutover get addressed before they affect 100 percent of traffic. This is the phase where most "fast" migrations fail because they skip the gradual cutover.

IP warming on new infrastructure (week 3-6)

For migrations involving new IPs (most ESP-to-self-hosted migrations, many ESP-to-ESP migrations with dedicated IPs), the new IPs need warming during cutover. We coordinate the warming with the gradual cutover: warming volume is part of the 5/30/70/100 percent ramp. By the time cutover reaches 100 percent, IP warming is sufficiently complete that full volume is safe. For migrations without new IPs (some ESP-to-ESP with shared IPs), this phase is skipped and the migration completes faster.

Closing review and 30-day warranty (week 4-8)

Closing review covers what was migrated, what was decommissioned, what reputation state was achieved on the new infrastructure, and any remaining cleanup. The 30-day warranty kicks in: if reputation degrades on the new infrastructure within 30 days of cutover completion due to migration-related issues, we re-engage at no additional charge. Reputation degradation due to your sending behavior changes (new campaigns, list quality issues, content changes) falls outside the warranty since it is not migration-related; the closing review documents the baseline so future issues can be classified.

What we preserve through the cutover

The reputation-preservation work that distinguishes migration from infrastructure switching

Most migrations technically work in the sense that emails get sent through the new infrastructure. The harder problem is sending them with the same placement quality you had on the old infrastructure. Below is what the preservation work covers.

DMARC alignment through cutover

DMARC requires SPF or DKIM alignment on the From domain. Most migrations briefly break alignment (during DNS propagation, or during the period when both old and new infrastructure are sending) which causes silent placement degradation that takes weeks to recover. We coordinate the DNS changes with the cutover sequence so alignment never breaks: the new authentication is published before traffic shifts, the old authentication remains valid through the transition, and the cleanup of old records happens after cutover completes.

Suppression list integrity

Suppression lists are how senders avoid emailing addresses that have unsubscribed, hard-bounced, or complained. Migrations frequently lose or corrupt suppression lists during platform transition, which results in emailing addresses that should not be emailed and triggers reputation problems immediately. We export, validate, and import suppression lists with verification that the counts match on both sides. For platforms with structured suppression categories (hard bounce, complaint, unsubscribe), we preserve the categories.

Sending reputation through gradual cutover

A cliff cutover (100 percent of traffic switches at once) is the most common cause of post-migration reputation problems. The new infrastructure has zero reputation at the moment of cutover; sending full volume immediately looks like a snowshoe spam pattern from receiver-side filters. The gradual cutover (5/30/70/100 over 2 to 4 weeks) builds reputation on the new infrastructure while reputation remains stable on the old, and the transition happens at receiver-acceptable pace.

DKIM key rotation without breaking signatures

Each ESP and MTA has its own DKIM key management. Migrations require either reusing the existing key (rare, since most platforms do not export private keys) or rotating to a new key. The rotation needs to happen with both old and new keys valid simultaneously during the cutover so that messages sent through both old and new infrastructure pass DKIM. We publish the new selector before cutover starts and rotate the active selector after cutover completes.

IP reputation on new infrastructure

For migrations involving new IPs (most ESP-to-self-hosted, many ESP-to-ESP with dedicated allocation), the new IPs start with zero reputation. The migration includes coordinated IP warming aligned with the cutover ramp; by the time cutover reaches 100 percent, the IPs have built sufficient reputation for full volume. This is functionally similar to our /ip-warming product and uses the same engagement pool of around 4,000 actively-engaged inboxes for the warming traffic.

Webhook continuity for downstream systems

Most senders have downstream systems consuming webhook events from their ESP: bounce processing, complaint handling, suppression list updates, analytics pipelines. A migration that breaks webhook delivery breaks all of these silently. We configure webhooks on the new infrastructure to fire to the same endpoints with translated event formats where the destination platform differs, and we document the format changes for your engineering team to update their event handlers.

Pricing — flat-rate engagements, not hourly

How much does a managed migration cost?

Engagements run from €499 (Discovery + Plan) through €2,499 (Standard Migration) and €5,999 (Multi-Platform), plus custom for complex moves. Pricing is flat-rate per engagement, not hourly. The fixed price covers everything from architecture through warming through the 30-day warranty. No scope-creep surprises, no separate warming fees, no hourly overruns when discovery uncovers complexity. Customers occasionally need work that genuinely falls outside engagement scope; in those cases we propose a custom scope rather than billing additional hours.

Discovery + Plan

Architecture review and migration runbook for teams executing the migration themselves.

€499 one-time

Plan delivered within 7 business days

Ideal for

Engineering teams with deliverability experience who need expert architecture review and detailed runbook; customers evaluating whether to DIY or hire full migration; teams with budget constraints needing a starting point.

Discovery call (90 min) with your engineering lead
Current state architecture documentation
Target state architecture proposal
Detailed migration runbook
Risk assessment and mitigation guidance
IP warming schedule for new infrastructure
One follow-up call (30 min) within 30 days
Deduction of €499 from Standard Migration if upgraded within 30 days

Order Discovery

Most chosen

Standard Migration

Single-platform single-domain migration with reputation preservation and IP warming.

€2,499 one-time

Engagement starts within 5 business days; full migration 4 to 6 weeks

Ideal for

SaaS migrating SendGrid to Mailgun, Mailgun to SES, or similar single-platform changes; agencies migrating a single client; senders moving to dedicated IPs for the first time.

Everything in Discovery + Plan
Cutover execution with daily check-ins
DNS record changes coordinated with cutover
Suppression list export, validation, and import
DKIM key rotation through cutover
IP warming on new infrastructure (up to 5 IPs)
Webhook reconfiguration on new infrastructure
30-day post-migration warranty
30-day post-engagement support window

Order Standard Migration

Multi-Platform Migration

For multi-ESP, multi-domain, or stream-separation migrations.

€5,999 one-time

Engagement starts within 7 business days; full migration 6 to 10 weeks

Ideal for

Senders splitting transactional and marketing into separate platforms; agencies migrating multiple clients simultaneously; cloud-to-self-hosted moves; Mandrill refugees with substantial integration complexity.

Everything in Standard Migration
Up to 3 platforms or 5 domains migrated
Stream separation execution if applicable
Multi-IP warming (up to 13 IPs)
Cross-platform reputation coordination
Custom webhook routing for split workflows
Daily reports during cutover phase
60-day post-migration warranty
Quarterly review session post-handoff (free for first 90 days)
Discovery call (90 min) before engagement scoping

Order Multi-Platform

Enterprise Migration

For large-scale migrations with regulatory requirements, /27+ blocks, or multi-region complexity.

Custom engagement

Engagement starts 10 to 15 business days after contract sign

Ideal for

Enterprise SaaS, financial services, healthcare, public sector, large agencies; senders with regulatory constraints (DPA negotiations, audit requirements, formal SLAs); migrations involving 30+ IPs or multiple geographic regions.

Custom engagement scoping based on complexity
Multi-region migration coordination
Regulatory and compliance documentation
Custom DPA negotiation
Dedicated migration engineer assigned
Multi-week or multi-month engagement timelines
Signed SLA with service credits
Custom warranty terms
Coordination with your legal and security teams
Discovery call (2 hours) before engagement scoping

Talk to sales

Engagements include a 30-day warranty (60-day for Multi-Platform, custom for Enterprise) covering migration-caused reputation issues. The warranty does not cover degradation from your post-migration sending behavior changes; the closing review documents the migration baseline so future issues can be classified clearly. Customers upgrading from Discovery + Plan to Standard Migration within 30 days get the €499 Discovery fee deducted from the upgrade. Engagement pricing is fully inclusive: no separate IP warming fees, no separate warming pool fees, no hourly overruns. The flat-rate is the price.

Real questions from buyers

What teams ask before contracting a migration

How is flat-rate pricing real when migrations have so much variability?

It is real because we have done enough of them to scope accurately upfront. Discovery + Plan costs €499 specifically because the Discovery work surfaces almost all the complexity that would otherwise cause hourly overruns: unusual integrations, regulatory requirements, unusual data volumes, technical debt that needs separate handling. After Discovery, the Standard Migration price is honest. Migrations that genuinely cannot fit Standard scope get scoped to Multi-Platform or Enterprise during Discovery; we do not start at Standard price and then bill for overruns. The flat-rate works because Discovery is a real product that surfaces the right scoping signal, not a sales call dressed up as a product.

Why include IP warming when /ip-warming is a separate product?

Because migrations involving new IPs without warming are net negative for the customer. A migration that completes the technical cutover but leaves the customer with cold IPs and crashing placement is worse than the pre-migration state for several weeks. We include warming because the migration outcome only counts if reputation lands stable on the new infrastructure. The pricing reflects this: Standard Migration at €2,499 includes warming that would cost €499 to €1,499 as a separate product. The bundling is honest pricing for the actual outcome customers want, not artificial discounting.

What if we are migrating to a platform you do not have a playbook for?

Send us the platform name and version during Discovery. The playbook coverage includes all major ESPs (SendGrid, Mailgun, AWS SES, Postmark, Mailchimp Transactional/Mandrill, Brevo, Resend, MailerSend) and all major MTAs (PowerMTA, KumoMTA, MailerQ, Halon, Postal, Postfix variants). For platforms outside that list, we work with your team to define the migration approach during Discovery, which adds 1 to 3 days to the planning phase. Custom platforms (in-house Go mailers, forked Postfix variants, unusual ESP integrations) get scoped as Multi-Platform or Enterprise depending on complexity. We have not encountered a platform we could not migrate to or from in the last 24 months.

Can we migrate from your infrastructure to a competitor without you sandbagging the work?

Yes, and customers who do this confirm we run the migration straight. Our long-term reputation is more valuable than any single customer relationship, and a sandbagged migration would burn that reputation faster than any short-term retention benefit. We have run several migrations off our own infrastructure to ESPs and self-hosted setups. The work runs the same way as migrations in any other direction: documented architecture, clean cutover, full warming, 30-day warranty. The only nuance is we do not include our infrastructure decommissioning in the engagement scope (you cancel the subscriptions on your normal billing cycle); other than that the migration is platform-agnostic.

What happens during the gradual cutover if our application code changes break things?

Roll back to old infrastructure and address the issue before resuming. The cutover plan includes rollback procedures specifically for this scenario; the old infrastructure remains active during cutover specifically so rollback is fast (DNS change, traffic returns to old). Application-side issues during cutover (unexpected behavior in template rendering, webhook handling errors, suppression list bugs) are common and the rollback path handles them. After the issue is resolved on your side, the cutover resumes from where it stopped. The flat-rate pricing accommodates one rollback cycle without additional charge; multiple rollback cycles within the same migration may shift scope to Multi-Platform Migration if the underlying complexity warrants it.

How do you handle migration during high-stakes business periods?

We do not, and we are explicit about this on the discovery call. Migrations should not happen during peak business periods because the gradual cutover takes 4 to 6 weeks and rollback during that window is operationally costly. For ecommerce: avoid Black Friday/Cyber Monday window plus 2 weeks before. For SaaS: avoid major product launches and end-of-quarter pushes. For B2B: avoid the start of fiscal year for your customer base. We coordinate the engagement timing with your team during Discovery; if the only available window is a high-stakes period, we discuss the trade-offs and the customer makes the call.

How does this compare to hiring a migration consultant on retainer?

Different shape, similar work for the typical migration. A consultant on retainer at €5,000 to €10,000 per month over 2 to 3 months runs €15,000 to €30,000 total, which is 5 to 10x our Multi-Platform pricing. The consultant has more flexibility (they can pivot scope mid-engagement) and more dedicated attention (they are billing you exclusively); we have flat-rate pricing and run multiple engagements in parallel, so any individual customer gets the engagement scope but not exclusive attention outside of cutover days. For typical migrations, the flat-rate model works better. For genuinely unusual migrations (regulated industries, multi-jurisdiction, novel architectures), the retainer model may fit better. The discovery call helps figure out which.

What level of access do you need to our existing infrastructure?

Read-only access where it helps, no write access ever. For ESPs: read-only API keys to inspect current configuration, suppression lists, sender authentication. For DNS: read-only access to the DNS provider so we can verify current records and confirm propagation during cutover. For application code: we do not need access; your engineering team applies code changes from the runbook we provide. For the new infrastructure: we may have admin access during setup if the customer prefers we configure it directly, but for Standard Migration the customer team usually handles the new infrastructure setup with our guidance. The principle: you should not give third-party engineers write access to your production systems, and we should not have it.

Can the migration include training our team on the new infrastructure?

Limited. The closing review includes operational handoff documentation that covers how to operate the new infrastructure (basic admin tasks, monitoring locations, common runbooks). Beyond that, structured training is not part of standard migration scope; we are not a training company. For Multi-Platform and Enterprise engagements, structured training sessions can be added as scope items if the customer requests; the additional cost depends on the complexity. Most customers find the operational handoff documentation sufficient for in-house operations after migration; teams that want deeper expertise often subscribe to /deliverability-monitoring afterward, which functions as ongoing operational support.

What if reputation degrades on the new infrastructure within 30 days?

30-day warranty kicks in. If the degradation is migration-caused (DKIM alignment issues we missed, suppression list corruption, IP warming insufficient), we re-engage at no charge to fix the underlying problem. If the degradation is from your sending behavior changes (new campaign that triggered complaints, list quality issue, content changes), it falls outside warranty because it is not migration-related; we can engage on a /reputation-recovery basis at standard pricing. The closing review documents the baseline so the classification is clear when issues arise. Most warranty invocations have been migration-caused (about 70 percent) historically; 30 percent get classified as customer-side and fall outside warranty.

Can engagements be paused if our timeline shifts?

Yes, with caveats. Engagements can be paused once for up to 30 days at no additional cost; longer pauses or multiple pauses require renegotiation because the work cycles fall out of alignment. If your timeline is genuinely uncertain at engagement start (regulatory approvals pending, internal organizational changes, dependency on other projects), we recommend deferring the engagement start until the timeline is firm rather than starting and pausing. Discovery + Plan can be purchased independently while the timeline solidifies, and the credit applies if you upgrade within 30 days.

How does the engagement handle our customers experiencing email gaps?

They should not experience gaps if the migration runs correctly. The gradual cutover is specifically designed to avoid hard cutover gaps: traffic shifts gradually with both infrastructures sending in parallel during transition. Customer-facing emails (transactional notifications, account updates, password resets) should not have any gap because the routing logic always has at least one valid endpoint. For very large customer bases (millions of users), some receiver-side caching of MX records or authentication can briefly cause delivery delays during DNS propagation; we communicate the propagation window to your team so customer support is prepared. In practice, customer-noticeable gaps are rare with the gradual cutover approach.

What is the typical breakdown of which products customers buy after migration?

About 40 percent subscribe to /deliverability-monitoring afterward (the natural complement to a fresh migration with documented baseline). About 25 percent subscribe to /managed-dmarc (DMARC discipline being one of the things migrations expose). About 15 percent move sending workload to one of our sending products (/smtp-relay, /email-sending-servers, /cold-email-infrastructure) within 12 months. About 30 percent maintain no ongoing relationship beyond the warranty period; this is a normal outcome and the migration engagement is fully self-contained for this case. Some customers fit multiple categories. The cross-sell is natural rather than aggressive because the migration outcome speaks for itself.

How does pricing scale for very large migrations (10M+ emails per month)?

Enterprise Migration custom-quoted based on actual scope. A migration involving 10M+ monthly emails, /27 or larger IP block, and multi-region coordination typically lands around €15,000 to €30,000 depending on complexity. Add regulatory requirements (financial services audit trails, healthcare HIPAA documentation, public sector procurement) and the price moves toward the upper end. The custom scoping happens during a 2-hour discovery call covering current architecture, target architecture, regulatory constraints, timeline, and success criteria. Customers running ongoing migration operations (large agencies onboarding multiple clients monthly) sometimes shift to a retainer arrangement at €8,000 to €15,000 per month, which is a different product shape.

Do you have references from customers who migrated to platforms you do not operate?

Yes, available on request during sales conversations. Customer references are coordinated case-by-case because most enterprise customers prefer not to publish their email infrastructure details publicly. We can connect prospective customers with past customers who migrated to AWS SES, Mailgun, KumoMTA self-hosted, PowerMTA self-hosted, and several other destinations, including some who migrated explicitly off our infrastructure for reasons unrelated to satisfaction (cost optimization, regulatory consolidation, internal mandates). The reference conversations are usually 30 to 45 minutes and focus on what the migration was like operationally rather than what platform was best.

What is your stance on customer data residency during migration?

Data residency requirements get documented during Discovery and built into the migration plan. Suppression lists and authentication credentials we handle during migration get processed on EU sub-processors only (matches our broader EU sovereign positioning) regardless of the source or destination platform jurisdiction. We sign a standard DPA with you before migration starts, retain migration logs for 90 days post-handoff, and delete them after that. For customers with stricter residency requirements (financial services, healthcare, public sector), we offer custom DPA terms with shortened retention periods and additional confidentiality.

Two ways to start

Discovery + Plan for evaluation, full engagement when ready

For teams not yet sure whether to DIY, hire us, or use someone else, the Discovery + Plan engagement at €499 is the right starting point: it produces the architecture review and runbook regardless of who executes the migration, and the €499 credits against Standard Migration if you upgrade within 30 days. For teams with clear scope, the full engagement is the direct path. The discovery call is no charge regardless of whether the engagement closes.

Order Discovery + Plan Talk to sales for full engagement

Phone +43 1 205 11 80 Mon–Fri · 9–18 CET

Email [email protected] Avg response 4h business

Office Fleischmarkt 1, 1010 Wien By appointment