A customer asked us last week about migrating from their current SendGrid setup to self-hosted infrastructure. They are at approximately 350,000 monthly messages and growing at 30% annually. Their SendGrid bill has crossed €1,800 per month. They see the trajectory and want to evaluate alternatives.

The conversation is one we have regularly. The pattern is consistent: customer crosses a volume threshold, SaaS ESP economics become questionable, they evaluate alternatives, eventually some migrate to self-hosted infrastructure.

This post is the operational reality of the SaaS-to-self-hosted migration based on the customers we have worked with through this transition. What works, what does not, what to plan for, and how to think about whether the transition makes sense for your specific situation.

When the migration makes sense

The threshold varies by operator but the pattern is consistent.

Volume-based threshold

For monthly volumes below approximately 100,000 messages, mainstream SaaS ESPs are typically the right answer. The cost is bounded; the operational simplicity is valuable; the scale does not justify migration complexity.

For monthly volumes between 100,000 and 500,000, the economics start to favor self-hosted but the decision is nuanced. Specific operator factors matter.

For monthly volumes above 500,000, the economics typically clearly favor self-hosted. The savings justify the migration work.

For monthly volumes above 2 million, self-hosted is almost always the right answer. The cost savings are substantial.

Strategic considerations beyond volume

Volume is the primary factor but not the only factor.

Content category restrictions matter. Some operations are in content categories that mainstream ESPs do not serve well (or at all). Self-hosted may be required regardless of volume.

Geographic considerations matter. Operations in regions with different regulatory frameworks may need infrastructure aligned with those frameworks.

Strategic positioning matters. Some operations sell services where ESP dependence would compromise positioning. Self-hosted aligns better with their brand.

Operational control matters. Some operators value the operational control of self-hosted regardless of cost considerations.

Cases where migration does not make sense

Even with high volume, some operations should stay on SaaS ESPs:

Operations without operational capability for self-hosted infrastructure Operations with bounded growth where the savings will not accumulate Operations with very simple sending patterns where ESP convenience exceeds the cost premium Operations facing time constraints that do not accommodate migration projects

The cost economics

Specific numbers help frame the decision.

SaaS ESP cost trajectory

Mainstream SaaS ESPs (SendGrid, Mailgun, Postmark) charge based on monthly message volume. Typical pricing at various volumes:

100K monthly: €100-€300
500K monthly: €500-€1,200
1M monthly: €1,000-€2,500
5M monthly: €4,000-€10,000
10M+ monthly: €8,000-€25,000+

The pricing scales roughly linearly with some tier breaks.

Self-hosted cost trajectory

Self-hosted infrastructure cost is more bounded:

Server hosting: €200-€600 per month (one dedicated server typically sufficient up to 1-2M monthly volume)
IPs: €5-€10 per dedicated IP per month (typically 4-12 IPs needed)
Software licensing (PowerMTA optional): €5,000-€15,000 annually if used
Operational time: 5-20 hours per month depending on volume

Total monthly cost approximate:

100K monthly: €400-€700
500K monthly: €500-€900
1M monthly: €700-€1,200
5M monthly: €1,000-€1,800
10M+ monthly: €1,500-€3,500

The self-hosted cost grows much more slowly than SaaS ESP cost as volume scales.

Crossover analysis

The crossover point where self-hosted becomes more cost-effective:

100K monthly: SaaS ESP often equal or better
250K monthly: depends on specific ESP pricing and self-hosted scale
500K monthly: self-hosted often 30-50% cheaper
1M monthly: self-hosted typically 50-70% cheaper
5M+ monthly: self-hosted typically 70-85% cheaper

The cost savings grow approximately linearly with volume.

Total cost of ownership considerations

The direct cost is not the only factor. Total cost of ownership includes:

Migration cost (one-time): typically €5,000-€25,000 for technical work plus organizational change Operational learning: significant initial investment in team capability Ongoing operational complexity: more than SaaS ESP, less than custom development Risk management: self-hosted has different risk profile than SaaS ESP

The total cost of ownership comparison should account for these factors honestly.

The migration process

For customers who decide to migrate, the process has consistent elements.

Phase 1: Planning and assessment

Inventory current setup:

Sending volumes and patterns
Recipient list size and engagement profile
Sending domains and authentication setup
Application integrations with current ESP
Custom features being used
Operational team capability

Define target infrastructure:

Server requirements based on volume
IP requirements based on sending pattern
Software stack selection (MailWizz, Acelle, PowerMTA, Postal, etc.)
Integration patterns for application code

Define migration timeline:

IP warmup time (typically 30-45 days)
Customer transition timing
Risk tolerance for compressed timelines

Phase 2: Infrastructure provisioning

Server deployment with appropriate sizing.

Software installation and configuration.

IP allocation with pre-flight verification.

Authentication setup (SPF, DKIM, DMARC, PTR).

Monitoring infrastructure setup.

Internal documentation creation.

Phase 3: Data export from current ESP

Subscriber list export. Suppression list export. Campaign templates export. Engagement history export. API documentation for current integrations.

The export volume varies. Most ESPs support reasonable exports. Some specific data formats may not transfer cleanly.

Phase 4: Data import to new infrastructure

Subscriber list import to new platform. Suppression list import (critical to do before any sending). Template porting (typically the most time-consuming step). Segmentation logic recreation. Custom field mapping.

The import work varies by complexity. Standard setups are bounded; complex setups require more work.

Phase 5: IP warmup

Engagement-focused warmup over 30-45 days as covered in our 2025 warmup post.

The warmup is the longest single phase. The schedule cannot be compressed without consequences.

Phase 6: Cutover

Gradual transition from old ESP to new infrastructure. Typically 10% → 25% → 50% → 75% → 100% over 2-4 weeks.

The old ESP remains active during cutover as fallback. The fallback is removed only after stable production on new infrastructure.

Phase 7: Production stabilization

After full cutover, several weeks of intensive monitoring confirm stable production.

Reputation metrics, delivery rates, customer-facing metrics all monitored carefully.

Phase 8: Old infrastructure retirement

Old ESP account closed after stable production confirms migration success.

Final data archived. Operational documentation finalized.

The total elapsed time is typically 10-14 weeks. Compressed timelines (the 72-hour emergency migration covered in another post) are exceptional.

What customers underestimate

Across many migrations, customers consistently underestimate several elements.

Template porting work

Templates from one ESP do not always port cleanly to another. Custom merge tags, conditional logic, ESP-specific features all require adaptation.

Plan for 1-3 hours per active template. Customers with 30+ active templates face significant work here.

Segmentation logic recreation

ESP segmentation logic does not transfer mechanically. Recipient segments need to be recreated using the new platform’s logic.

The work is bounded but requires understanding both platforms. Plan adequate time.

Integration code changes

Application code that calls the ESP’s API needs to call the new platform’s API. The interfaces differ.

For simple integrations, the work is bounded. For complex integrations with many touchpoints, the work is substantial.

Operational learning curve

Self-hosted infrastructure requires different operational practices than SaaS ESP. The team needs to learn:

Monitoring patterns specific to self-hosted
Deliverability operations
Incident response for infrastructure issues
Capacity planning
Customer support for delivery-related questions

The learning curve is 2-6 months depending on team starting capability.

Ongoing operational time

After migration, operational time is meaningful. The “we run it ourselves” reality requires ongoing attention.

For typical operations: 10-20 hours per month of dedicated operational time. For larger operations: 30-60 hours per month.

This is real ongoing cost that the simple “savings” calculation may not capture.

Customer-facing communication

Customer communication about the migration matters more than expected. Customers who learn about delivery changes from issues rather than from proactive communication produce support load.

Plan for explicit customer communication strategy.

What works well in self-hosted

After migration, customers consistently report several benefits.

Cost predictability

Self-hosted costs are predictable. Volume growth does not produce proportional cost growth. Budget certainty improves.

Operational control

The operator controls the infrastructure. Specific configurations, specific behaviors, specific integrations all controllable.

Customization flexibility

The infrastructure supports customizations that SaaS ESPs typically do not.

No content restrictions

Subject to legal requirements only. The ESP’s content policies do not apply.

Deliverability ownership

Sender reputation is the operator’s. Better practices produce better deliverability without averaging with other senders.

Strategic independence

Future ESP policy decisions do not affect the operation. Strategic continuity is improved.

Better economics at scale

The economics favor self-hosted at scale. The savings fund other operational priorities.

What is harder in self-hosted

Some aspects are harder than SaaS ESP.

Initial setup complexity

The setup is more complex than signing up for SaaS ESP. The work is bounded but real.

Ongoing operational responsibility

The operator is responsible for ongoing operations. SaaS ESP outsources the operational work to the ESP.

Incident response

Production incidents become the operator’s responsibility. SaaS ESP incidents are handled by the ESP’s team.

Specialized expertise

Some operations require specialized expertise (deliverability, infrastructure, security). The expertise can be developed in-house or purchased through managed services.

Customer support load

Delivery-related customer support comes to the operator. SaaS ESP often has support infrastructure handling some of this load.

Capacity planning

Capacity decisions are the operator’s. SaaS ESP handles capacity transparently. Self-hosted requires explicit planning.

What we provide for customers in transition

For customers migrating to self-hosted, we provide several services.

Managed infrastructure

We operate the infrastructure layer (PowerMTA, Postal, supporting services). Customers focus on their application layer and operations.

The managed infrastructure reduces the operational learning curve significantly.

Deliverability operations

We provide ongoing deliverability monitoring, incident response, and operational consultation. Customers benefit from specialist expertise without hiring it in-house.

IP pool management

We manage IP allocation, pre-flight verification, warmup operations, and ongoing reputation monitoring. Customers receive IPs ready for production.

Migration support

We help customers through the migration process. Planning, data migration assistance, integration support, customer communication templates.

Customer education

We educate customer teams on self-hosted operational patterns. The education builds team capability over time.

Ongoing consultation

For ongoing operations, we provide consultation on specific situations. Strategic decisions, operational refinements, incident handling all covered.

For customers evaluating whether to migrate:

Honest assessment of current state

Quantify current SaaS ESP costs accurately. Include all costs, not just the headline subscription.

Quantify current operational time spent on ESP-related work. The work continues after migration; the comparison should be accurate.

Honest assessment of capability

Evaluate team capability honestly. Self-hosted requires capability the team may not have. Plan for either capability development or external support.

Realistic timeline planning

Plan for 10-14 weeks. Compressed timelines produce mistakes.

Adequate budget allocation

Migration is a project with real costs. Allocate appropriate budget for the work.

Stakeholder alignment

Internal stakeholders need to understand the migration scope and timeline. Surprises during migration produce poor outcomes.

Risk planning

Migrations have risks. Plan for the risks rather than hoping they will not materialize.

Quality over speed

Better to migrate well over 14 weeks than poorly over 8 weeks. The savings from compressed timeline rarely justify the risks.

Some approaches we see that produce poor outcomes.

Cost-only motivation

Customers motivated only by cost savings often fail to invest adequately in the operational work. The savings appear briefly then are consumed by operational problems.

The migration should produce both cost savings and operational improvements. Cost-only motivation usually produces incomplete work.

Compressed timeline ambitions

Compressed timelines (4-6 weeks instead of 10-14) produce shortcuts. The shortcuts produce production issues.

The 72-hour emergency migration covered in another post was exceptional and acknowledged the compressed timeline trade-offs. Routine migrations should not be compressed.

Internal-only execution

Customers attempting migration without external expertise often face avoidable problems. The migration involves specific knowledge that is hard to develop in-house quickly.

Working with external expertise (us or others) typically produces better outcomes than going alone.

Underestimating operational continuity

The operational work after migration is significant. Customers underestimating this face accumulating issues.

The migration is not “set it up once and forget it.” The migration produces an operation that requires ongoing investment.

The longer-term outcome

Looking at customers 12-24 months post-migration:

Most customers report the migration was worth doing. Cost savings continue. Operational control continues. Strategic positioning improves.

Some customers report the migration was harder than expected but ultimately worthwhile.

A small minority of customers report the migration was a mistake for their specific situation. Usually because their operation did not align with self-hosted requirements or because they lacked operational capability.

The pattern: customers who entered the migration with realistic expectations and adequate preparation succeed. Customers who entered with optimistic expectations and minimal preparation struggle.

The customer mix we serve

Across our customer base, the mix reflects various paths into self-hosted operation.

Customers who migrated from SaaS ESP (the focus of this post): approximately 40%.

Customers who started directly with self-hosted: approximately 30%.

Customers who came from custom in-house development: approximately 15%.

Customers who use us alongside SaaS ESP for specific use cases: approximately 15%.

Each path has its operational patterns. The migration-from-ESP path is the most common; the patterns described in this post reflect that path.

What we expect over time

Looking forward at the SaaS ESP to self-hosted migration trend:

The migration trend continues. Operators crossing volume thresholds continue evaluating alternatives. Some migrate; some stay on SaaS ESP.

The economics continue favoring self-hosted at scale. The crossover thresholds may shift slightly but the broad pattern holds.

The operational tooling continues maturing. Self-hosted infrastructure becomes easier to operate over time.

The mainstream SaaS ESPs continue evolving their pricing and capabilities. The comparison continues being relevant.

The specialist providers (us and similar) continue serving the segment effectively. The professional service of operating self-hosted infrastructure on behalf of customers continues being valuable.

The honest summary

Migrating from SaaS ESP to self-hosted is a real project with real costs and real benefits. The economics favor self-hosted at scale. The operational reality requires capability and discipline.

For operators considering the migration: honest assessment of your situation produces good decisions. The migration suits some operators; it does not suit others. Either outcome is fine as long as it matches your actual situation.

For operators committed to the migration: adequate planning, realistic timeline, appropriate budget, and proper preparation produce good outcomes. Cutting corners produces problems.

For operators who completed the migration: continued operational discipline produces continued benefits. The work continues; the savings continue; the strategic positioning continues paying back.

We continue working with customers across the migration journey. Each customer’s specific situation produces specific recommendations. The general pattern is consistent: operations crossing certain thresholds benefit from self-hosted infrastructure; the migration is bounded but real work; the benefits accumulate over time.

The current customer who started this post is evaluating their situation. They have the volume to justify the migration. They have growth that will compound the benefits. They have technical capability that supports the operational transition. The migration likely makes sense for them.

For other operators in similar situations: the assessment process is the first step. Quantify honestly. Plan adequately. Execute professionally. The migration produces sustainable operational improvement for operations whose situation aligns. The customers who go through this transition successfully continue benefiting for years after the migration completes.

The work is real. The benefits are real. The pattern is repeatable. The customers we have served through this transition continue producing the outcomes we and they expected. The trajectory continues.