Migration guide
Beyond Halon
Get long-term control without licensing lock-in with KumoMTA
KumoMTA is the open-source, standards-based alternative to Halon for high-volume senders. It combines programmable policy and real-time operational visibility with configuration-as-code, container-ready deployment, and no per-server or volume-based licensing.
Optimizing for the long-term
Organizations evaluating alternatives to Halon typically are making a strategic decision about the future of their MailOps infrastructure. They are prioritizing sustainable, forward-looking control, business continuity, and freedom from proprietary technology.
As email becomes increasingly business-critical, decisions around sending platforms extend beyond issues such as throughput and scripting capabilities. Teams are evaluating who really controls the platform they depend on, how easily it can evolve with changing requirements, and reassessing the risk of keeping critical infrastructure tied to a vendor's proprietary source code, vendor-specific tooling, and commercial licensing.
KumoMTA was built for organizations making that transition. Its open-source architecture gives MailOps teams complete visibility into the platform, the flexibility of industry-standard Lua scripting, and the confidence that comes from owning the infrastructure they rely on. Organizations choose KumoMTA because open source provides greater long-term business flexibility, resilience, and operational independence.
KumoMTA
Trusted by teams
operating high-volume email infrastructure
operating high-volume email infrastructure
Organizations modernizing legacy MTA infrastructure increasingly rely on KumoMTA to support:
High-volume enterprise email delivery
Multi-tenant sending environments
ISP and telco messaging infrastructure
Cloud-native MailOps workflows
Kubernetes-based deployment environments
Modern observability and automation pipelines
KumoMTA
Trusted by Teams
Operating High-Volume
Email Infrastructure
Operating High-Volume
Email Infrastructure
Organizations modernizing legacy MTA infrastructure increasingly rely on KumoMTA to support:
High-volume enterprise email delivery
Multi-tenant sending environments
ISP and telco messaging infrastructure
Cloud-native MailOps workflows
Kubernetes-based deployment environments
Modern observability and automation pipelines
All the performance power. None of the proprietary strings.
KumoMTA delivers ultra-high performance in a platform designed for modern email infrastructure environments, all without commercial licensing dependencies, proprietary scripting language, or vendor lock-in.
Built for today's MailOps requirements, KumoMTA provides:
Open-source transparency with full access to platform source code
Lua-based configuration using a widely adopted scripting language with a large ecosystem
Modern APIs and automation workflows
Cloud-native and Kubernetes-friendly deployment models
Infrastructure-as-code configuration workflows
Fine-grained multi-tenant, IP pool, and policy management
Active community development with a transparent roadmap
KumoMTA was developed by engineers with direct experience building and operating high-volume email infrastructure at scale. Our decades of industry experience informed our vision for creating the ideal MTA for today’s enterprise-scale email operations. As such, KumoMTA allows organizations to modernize without abandoning the operational concepts that made their existing platforms successful.
The composability question
Halon emphasizes a composable email infrastructure approach and frames composability as ready-made by them and controlled by you. What they describe is configurability within a vendor-defined boundary. You are composing with their components, through their language, inside their platform. The control is real, but it is bounded control. At KumoMTA, composable should not mean proprietary. Consider a few points:
1
True composability means owning the architecture, not just the configuration
Halon's composability is a product feature. KumoMTA's openness is an architectural reality. With Halon, you assemble from their catalog. With KumoMTA, you have the source code, so you can change anything, integrate anything, and deploy however your infrastructure demands. That is not composability as a feature. That is actual ownership.
2
Modularity without portability is just a prettier lock-in
The claim that you can add, change, or scale components without downtime is a deployment-flexibility argument, and it is a reasonable one. But that flexibility does not extend outside Halon. Swap Halon out and the modularity disappears with it. KumoMTA's open architecture makes your operational model, scripting logic, and deployment patterns portable by default.
3
10x faster workflows is a feature claim. Open source is a structural one
Speed of iteration is a fair thing to compete on, and Kumo's Lua-as-configuration model is genuinely fast to iterate. But the more durable point is that open source changes the nature of the relationship. You're not dependent on a vendor's release cadence to ship faster. Your team controls when things change and how.
KumoMTA is built on a different set of premises: that real control means access to the platform itself, the source code, the architecture, and the deployment model. Not just the knobs they have decided to expose.
Composability within a proprietary system is configuration. Composability on open source infrastructure is ownership.
The scripting language question
One of the most important and least-discussed differences between Halon and KumoMTA is the different scripting environments the two companies support. Halon’s entire composability story depends on the Halon Scripting Language, a domain-specific language developed and maintained by Halon. HSL is powerful within the Halon platform, but it exists only within the Halon platform. Engineers who build operational expertise in HSL are building knowledge that does not transfer outside of a single vendor’s product.
KumoMTA uses Lua, one of the most widely deployed embedded scripting languages in the world, with a large open ecosystem, extensive documentation, and a substantial pool of engineers who already know it. Lua expertise is transferable, hireable, and not tied to any single vendor’s commercial fortunes. With Halon, the moment you hit something HSL cannot express, or Halon decides not to support, or a new version breaks, you are back to being a customer making a support request. Lua has no such ceiling because Lua has no vendor.
For MailOps teams, the practical implications are significant:
HSL knowledge is specific to Halon. Lua knowledge is broadly applicable.
Hiring for Halon scripting expertise requires finding people who have specifically used Halon. Hiring for Lua expertise draws from a much larger talent pool.
Automation and operational logic built in HSL cannot be ported. Logic built in Lua can be adapted across systems.
Institutional knowledge in HSL creates an additional migration barrier by design.
Halon
KumoMTA
Scripting & openness
Scripting language
HSL — proprietary DSL
Lua — open, widely used
Source code access
Unavailable
Fully open source
Talent pool
Halon-specific only
Broad Lua ecosystem
Deployment & operations
Kubernetes support
Supported
Designed for K8s
Observability
Proprietary insights platform
Modern APIs & metrics
Upgrade cadence
Vendor-managed
Customer-controlled
Business & licensing
Licensing model
Commercial subscription
Open source
Vendor lock-in
High
Low — full source control
Business continuity
Vendor-dependent
Platform-independent
Community
European-focused
Active open source + US presence
Halon describes HSL as a feature. It is also something of an isolated technological island that constricts your options. Every hour your team invests in HSL scripting deepens your dependency on a single commercial vendor’s platform and pricing decisions. KumoMTA uses Lua, the industry-standard policy language. Your operational investment follows you.
Scripting & openness
Scripting language
Halon
HSL- proprietary DSL
KumoMTA
Lua - open, widely used
Source code access
Halon
Unavailable
KumoMTA
Fully open source
Talent pool
Halon
Halon-specific only
KumoMTA
Broad Lua ecosystem
Deployment & operations
Kubernetes support
Halon
Supported
KumoMTA
Designed for K8s
Observability
Halon
Proprietary insights platform
KumoMTA
Modern APIs & metrics
Upgrade cadence
Halon
Vendor-managed
KumoMTA
Customer-controlled
Business & licensing
Licensing model
Halon
Commercial subscription
KumoMTA
Open source
Vendor lock-in
Halon
High
KumoMTA
Low — full source control
Business continuity
Halon
Vendor-dependent
KumoMTA
Platform-independent
Community
Halon
European-focused
KumoMTA
Active open source + US presence
Halon describes HSL as a feature. It is also something of an isolated technological island that constricts your options. Every hour your team invests in HSL scripting deepens your dependency on a single commercial vendor’s platform and pricing decisions. KumoMTA uses Lua, the industry-standard policy language. Your operational investment follows you.
Migration approach for Halon teams
Migrating from Halon to KumoMTA involves transitioning from HSL to Lua, but organizations typically find the move more straightforward than a complete platform replacement. Existing mail policies, routing logic, automation workflows, and operational practices generally translate well because both platforms are designed around programmable, policy-driven message processing.
The objective is to preserve the operational capabilities your team depends on while moving to an open-source platform built for long-term flexibility, transparency, and business continuity.
Halon teams migrating to KumoMTA can typically expect to:
Translate existing policy logic and automation workflows into industry-standard Lua without redesigning operational processes.
Preserve IP reputation, delivery policies, routing behavior, and established sending practices throughout the migration.
Maintain existing monitoring, telemetry, bounce processing, and feedback loop integrations while expanding operational visibility.
Deploy KumoMTA alongside an existing Halon environment to validate production traffic and migrate incrementally.
Adopt an open-source platform that eliminates dependence on proprietary source code, vendor-controlled scripting, and closed commercial roadmaps.
Every migration is different, but the goal remains the same: preserve the operational maturity you have already built while gaining the long-term advantages of open-source MailOps infrastructure.
KumoMTA addresses common Halon migration concerns
Organizations evaluating a Halon migration are often less concerned with whether KumoMTA can deliver enterprise-scale email than with protecting the operational investments they have already made.
Common questions include:
Can existing HSL automation be migrated to Lua?
Existing policy logic and workflows can typically be translated without redesigning how your MailOps team operates.
Will we preserve our IP reputation and delivery behavior?
Yes. IP pools, reputation management, routing strategies, and delivery policies can be maintained throughout a staged migration.
Can we migrate without disrupting production traffic?
KumoMTA can be deployed alongside an existing Halon environment, allowing traffic to be validated incrementally before cutover.
What happens to our monitoring and telemetry?
Existing observability pipelines, bounce processing, and feedback loop integrations can be preserved while expanding visibility into platform performance.
Why move from Halon if it already meets our technical requirements?
For many organizations, the decision is strategic rather than technical. Open-source infrastructure provides greater transparency, operational independence, and long-term business continuity than proprietary platforms.
What changes and what stays the same
Existing capability
What happens in KumoMTA
IP Pools
Preserved
Routing Logic
Adapted
Throttles and Rate Limits
Preserved
Reputation Management
Preserved
Scripting Language
Transitions from HSL (proprietary) to Lua (open)
Telemetry
Expanded
Deployment Process
Modernized
Automation Workflows
Expanded
Observability
Significantly Improved
Vendor License Dependency
Eliminated
Source Code Access
Fully Available
Typical Halon migration approach
Most organizations do not replace Halon through a single cutover event. Instead, migrations are typically staged incrementally to reduce operational and deliverability risk.
Common Halon migration approaches include:
1
Deploying KumoMTA alongside existing Halon infrastructure
2
Migrating specific traffic classes, tenants, or IP pools first
3
Validating routing, telemetry, and deliverability behavior
4
Gradually transitioning additional workloads and scripting logic over time
5
Retiring Halon licensing dependencies in phases
This staged approach allows organizations moving off Halon to modernize infrastructure while minimizing disruption to production sending environments, and to progressively reduce commercial licensing exposure as migration progresses.
Migration
outcomes
outcomes
Organizations migrating onto KumoMTA have reported:
✓
Faster deployment and configuration iteration
✓
Simplified operational management
✓
Reduced infrastructure footprint
✓
Greater visibility into delivery behavior
✓
Improved automation and deployment flexibility
✓
Lower long-term infrastructure and licensing costs
✓
Reduced exposure to renewal-time pricing leverage and license risk
✓
Improved community-driven roadmap input and platform visibility
✓
Full source code access and deployment control
✓
Greater long-term operational independence from vendor licensing cycles
General operational and business considerations beyond throughput
As organizations evaluate email infrastructure, many MailOps and engineering teams are examining not only technical capabilities but also the long-term operational and business implications of proprietary commercial MTA platforms. Common considerations include:
Common considerations include:
Proprietary scripting language lock-in
HSL is a domain-specific language maintained exclusively by Halon. Operational knowledge, automation logic, and engineering expertise built around HSL cannot be transferred outside the Halon platform.
Vendor-controlled product direction
Product roadmaps, feature prioritization, and release timelines are controlled entirely by the vendor. Organizations cannot influence platform development outside of commercial feedback channels.
Renewal and pricing leverage
Commercial licensing creates meaningful leverage at renewal time. As operational complexity and HSL-based automation accumulate, migration costs increase, which strengthens the vendor’s position in pricing negotiations.
Limited transparency into platform internals
Source code access is not available. Direct inspection, security review, internal customization, and debugging of platform behavior are constrained by proprietary architecture.
Business continuity exposure
Platform access depends on maintaining an active commercial agreement. License disputes, acquisition events, or vendor instability can affect deployment continuity in ways that open-source platforms are not subject to.
Hiring and talent pool constraints
Engineers with HSL expertise are, by definition, engineers with Halon experience. The talent pool is far narrower than for platforms using widely known scripting languages with broad open-source communities.
Modest North American ecosystem
Halon’s customer base and community are concentrated primarily in Europe. For US-based organizations, this can affect access to community resources, regional support, and peer knowledge networks.
Acquisition and ownership risk
Commercial MTA platforms have historically changed ownership multiple times. Each transition introduces uncertainty around roadmap continuity, pricing, support models, and long-term strategic direction.
General Operational and Business Considerations Beyond Throughput
As organizations modernize email infrastructure, many teams are reevaluating not only technical capabilities, but also the long-term operational and business implications of traditional commercial MTA platforms.
Common considerations include:
Legacy Architectural Foundations
Many commercial MTAs were originally architected more than a decade ago, with modernization occurring incrementally over time.
Limited Transparency Into Platform Internals
Source code access is generally unavailable, limiting direct inspection, debugging, security review, and internal customization.
Operational Lock-In Risk
Migration complexity often increases over time as infrastructure, automation, and workflows become more tightly coupled to proprietary systems.
Ownership and Acquisition Exposure
Several major commercial MTA platforms have changed ownership multiple times, introducing uncertainty around roadmap continuity, support models, pricing, and long-term strategic direction.
Renewal and Support Dependency
Access to updates, support, security patches, new functionality, and in some cases even continued operation of the software depends on maintaining active commercial agreements.
Business Continuity Considerations
Commercial licensing introduces operational dependencies that can affect deployment continuity, upgrade access, and long-term infrastructure planning.
Software Provenance and Compliance Review
Organizations with strict compliance or security requirements may require greater visibility into software composition, dependency chains, and incorporated third-party code.
License-Based Pricing Models
Volume-tiered commercial licensing can become increasingly expensive as sending volume and infrastructure scale grow.
Vendor-Controlled Product Direction
Product roadmaps, feature prioritization, and release timelines are typically controlled entirely by the vendor.
Why open source matters for MailOps
For many MailOps teams, open source is not primarily about cost reduction — it is about operational control, transparency, portability, and long-term infrastructure continuity.
Organizations operating mission-critical email infrastructure increasingly want direct access to the platform they depend on, without being constrained by proprietary licensing, opaque architectures, or vendor-controlled deployment models.
KumoMTA provides organizations with full access to the platform, allowing teams to retain operational control regardless of vendor changes, acquisitions, roadmap shifts, or licensing transitions.
Why open source matters for MailOps
For many MailOps teams, open source is not primarily about cost reduction — it is about operational control, transparency, portability, and long-term infrastructure continuity.
Organizations operating mission-critical email infrastructure increasingly want direct access to the platform they depend on, without being constrained by proprietary licensing, opaque architectures, or vendor-controlled deployment models.
KumoMTA provides organizations with full access to the platform, allowing teams to retain operational control regardless of vendor changes, acquisitions, roadmap shifts, or licensing transitions.
Halon vs. KumoMTA
Organizations evaluating a Halon alternative are often comparing not only throughput and deliverability performance, but also scripting portability, operational transparency, community support, and long-term infrastructure control.
Area
Halon
KumoMTA
Scripting language
HSL — proprietary Halon-specific DSL
Lua — open, widely used, broadly hireable
Source code access
Unavailable, closed source
Fully available through open-source licensing
Licensing model
Commercial subscription licensing
Open source with optional enterprise support
Vendor lock-in exposure
High — proprietary language, closed source, and commercial dependency
Low — full source access and deployment control
Product roadmap
Vendor-controlled
Open development model with transparent evolution
Talent pool
Engineers with specific Halon and HSL experience
Broad Lua and open-source engineering community
Kubernetes support
Supported
Designed for containerized and Kubernetes-based environments
Deployment model
Commercial cloud and on-premises
Cloud-native, container-friendly, Kubernetes-ready
Multi-tenant control
Supported through Halon policy model
Fine-grained tenant, IP, and pool-based policy control
Observability
Halon Delivery Insights, proprietary tooling
Modern observability, APIs, metrics, and automation workflows
Community
Commercial user base, primarily European
Active open-source community with large US enterprise presence and a global installed base
Upgrade cadence
Vendor-managed release lifecycle
Customer-controlled deployment and upgrade cadence
Business continuity
Dependent on vendor licensing and commercial agreements
Organizations retain operational control regardless of vendor changes
Migration familiarity
Requires HSL-to-Lua transition
Event-driven policy model eases conceptual transition
Long-term cost
Volume-based commercial licensing
Open-source core, with costs scaling with infrastructure rather than vendor pricing
Halon vs. KumoMTA
Organizations evaluating a Halon alternative are often comparing not only throughput and deliverability performance, but also scripting portability, operational transparency, community support, and long-term infrastructure control.
Area
Scripting language
Halon
HSL — proprietary Halon-specific DSL
KumoMTA
Lua — open, widely used, broadly hireable
Area
Source code access
Halon
Unavailable, closed source
KumoMTA
Fully available through open-source licensing
Area
Licensing model
Halon
Commercial subscription licensing
KumoMTA
Open source with optional enterprise support
Area
Vendor lock-in exposure
Halon
High — proprietary language, closed source, and commercial dependency
KumoMTA
Low — full source access and deployment control
Area
Product roadmap
Halon
Vendor-controlled
KumoMTA
Open development model with transparent evolution
Area
Talent pool
Halon
Engineers with specific Halon and HSL experience
KumoMTA
Broad Lua and open-source engineering community
Area
Kubernetes support
Halon
Supported
KumoMTA
Designed for containerized and Kubernetes-based environments
Area
Deployment model
Halon
Commercial cloud and on-premises
KumoMTA
Cloud-native, container-friendly, Kubernetes-ready
Area
Multi-tenant control
Halon
Supported through Halon policy model
KumoMTA
Fine-grained tenant, IP, and pool-based policy control
Area
Observability
Halon
Halon Delivery Insights, proprietary tooling
KumoMTA
Modern observability, APIs, metrics, and automation workflows
Area
Community
Halon
Commercial user base, primarily European
KumoMTA
Active open-source community with large US enterprise presence and a global installed base
Area
Upgrade cadence
Halon
Vendor-managed release lifecycle
KumoMTA
Customer-controlled deployment and upgrade cadence
Area
Business continuity
Halon
Dependent on vendor licensing and commercial agreements
KumoMTA
Organizations retain operational control regardless of vendor changes
Area
Migration familiarity
Halon
Requires HSL-to-Lua transition
KumoMTA
Event-driven policy model eases conceptual transition
Area
Long-term cost
Halon
Volume-based commercial licensing
KumoMTA
Open-source core, with costs scaling with infrastructure rather than vendor pricing
⌕
Frequently Asked Questions
Why would a team using Halon consider switching to KumoMTA?⌄
For teams considering a transition, the decision often comes down to long-term infrastructure control. Common migration drivers include a preference for open-source infrastructure, concern about HSL scripting lock-in, the need for broader engineering talent access, and the desire for vendor-independent platform continuity. If you want to own your infrastructure rather than license it, KumoMTA offers a strong alternative.
How difficult is the scripting transition from HSL to Lua?⌄
Halon and KumoMTA share an event-driven policy model, so the conceptual framework carries over well. HSL and Lua use different syntax, but both support email policy logic for routing, throttling, queue management, and tenant control. Teams with strong HSL experience usually find the Lua learning curve manageable, and Lua’s larger ecosystem helps speed up adoption.
Can KumoMTA match Halon’s performance at scale?⌄
Yes. KumoMTA is designed for ultra-high-volume sending environments and supports the performance requirements of large ESPs, ISPs, and enterprise senders. Concurrency management, queue behavior, and delivery optimization are handled within the platform’s core architecture.
Can existing IP reputation and warmup behavior be preserved?⌄
Yes. IP pool structures, warmup logic, and reputation management behavior can be preserved through the migration. KumoMTA’s policy model supports the same delivery control and routing flexibility that Halon operators rely on.
Can routing and delivery logic be migrated from Halon?⌄
Routing logic, throttles, and delivery policies can be adapted from Halon’s HSL model into KumoMTA’s Lua configuration. The syntax changes, but the policy model maps well and most operational logic can be translated without rebuilding everything from scratch.
Does KumoMTA support multi-tenancy?⌄
Yes. KumoMTA provides fine-grained tenant, IP pool, and policy control for the multi-tenant sending environments common in ESP, ISP, and enterprise email infrastructure.
How does KumoMTA compare on licensing costs?⌄
KumoMTA’s open-source core removes volume-based commercial licensing costs associated with Halon. Infrastructure costs scale with your deployment, not with a vendor pricing model. Enterprise support and services remain available if you want them.
How is migration typically structured?⌄
Most migrations are staged rather than handled as a single cutover. KumoMTA can run alongside existing Halon infrastructure while traffic moves incrementally by tenant, traffic class, or IP pool. That gives your team time to validate delivery behavior, translate scripting logic, and build operational confidence before fully moving production workloads.
Ready to move beyond proprietary MTA infrastructure?
Whether you are evaluating a Halon alternative, exploring open-source MTA options, or planning a phased migration away from commercial email infrastructure, KumoMTA provides a modern operational foundation built for today’s MailOps environments.
Get the 2026 MTA Buyer’s Guide
Make infrastructure decisions with clarity and confidence.
Get the guide⌕
Frequently Asked Questions
Why would a team using Halon consider switching to KumoMTA?⌃
For teams considering a transition, the decision often comes down to long-term infrastructure control. Common migration drivers include a preference for open-source infrastructure, concern about HSL scripting lock-in, the need for broader engineering talent access, and the desire for vendor-independent platform continuity. If you want to own your infrastructure rather than license it, KumoMTA offers a strong alternative.
How difficult is the scripting transition from HSL to Lua?⌃
Halon and KumoMTA share an event-driven policy model, so the conceptual framework carries over well. HSL and Lua use different syntax, but both support email policy logic for routing, throttling, queue management, and tenant control. Teams with strong HSL experience usually find the Lua learning curve manageable, and Lua’s larger ecosystem helps speed up adoption.
Can KumoMTA match Halon’s performance at scale?⌃
Yes. KumoMTA is designed for ultra-high-volume sending environments and supports the performance requirements of large ESPs, ISPs, and enterprise senders. Concurrency management, queue behavior, and delivery optimization are handled within the platform’s core architecture.
Can existing IP reputation and warmup behavior be preserved?⌃
Yes. IP pool structures, warmup logic, and reputation management behavior can be preserved through the migration. KumoMTA’s policy model supports the same delivery control and routing flexibility that Halon operators rely on.
Can routing and delivery logic be migrated from Halon?⌃
Routing logic, throttles, and delivery policies can be adapted from Halon’s HSL model into KumoMTA’s Lua configuration. The syntax changes, but the policy model maps well and most operational logic can be translated without rebuilding everything from scratch.
Does KumoMTA support multi-tenancy?⌃
Yes. KumoMTA provides fine-grained tenant, IP pool, and policy control for the multi-tenant sending environments common in ESP, ISP, and enterprise email infrastructure.
How does KumoMTA compare on licensing costs?⌃
KumoMTA’s open-source core removes volume-based commercial licensing costs associated with Halon. Infrastructure costs scale with your deployment, not with a vendor pricing model. Enterprise support and services remain available if you want them.
How is migration typically structured?⌃
Most migrations are staged rather than handled as a single cutover. KumoMTA can run alongside existing Halon infrastructure while traffic moves incrementally by tenant, traffic class, or IP pool. That gives your team time to validate delivery behavior, translate scripting logic, and build operational confidence before fully moving production workloads.
Ready to move beyond proprietary MTA infrastructure?
Whether you are evaluating a Halon alternative, exploring open-source MTA options, or planning a phased migration away from commercial email infrastructure, KumoMTA provides a modern operational foundation built for today’s MailOps environments.
Get the 2026 MTA Buyer’s Guide
Make infrastructure decisions with clarity and confidence.
Get the guide