Migration guides

npayload can replace or complement your existing messaging infrastructure. Whether you are running self-managed clusters or using cloud-native services, npayload provides a fully managed alternative with built-in delivery guarantees, encryption, and developer-friendly SDKs.

Why migrate to npayload?

• Fully managed infrastructure. No brokers, clusters, or nodes to provision, patch, or scale.
• Built-in delivery guarantees. Dead letter queues, circuit breakers, configurable retries, and exponential backoff included out of the box.
• No cluster management. No partition rebalancing, no consumer lag monitoring, no broker disk alerts.
• SDK simplicity. A single @npayload/node package replaces vendor-specific client libraries and serialization boilerplate.
• Cross-region built in. Multi-region messaging works without manual replication configuration.

Migration guides by platform

From Apache Kafka

Map topics, partitions, consumer groups, and offsets to npayload concepts

From RabbitMQ

Map exchanges, queues, bindings, and routing keys to npayload channels and subscriptions

From AWS SNS/SQS

Replace SNS topics, SQS queues, and EventBridge with a single unified messaging service

General migration checklist

Regardless of which system you are migrating from, the high-level process follows the same pattern:

1. Map your existing topics or queues to npayload channels. Identify each topic, exchange, or queue in your current system and create a corresponding npayload channel.
2. Set up subscriptions to match your consumer configuration. For each consumer, create an npayload subscription with the appropriate delivery mode (webhook, queue, or consumer group).
3. Update publishers to use the npayload SDK. Replace your existing producer client with @npayload/node publish calls.
4. Run both systems in parallel during transition. Use connectors or dual-write patterns to send messages to both the old system and npayload simultaneously.
5. Migrate consumers one at a time. Switch each consumer from the old system to npayload independently, verifying correctness at each step.
6. Decommission the old system. Once all producers and consumers have been migrated and validated, shut down the legacy infrastructure.

Next steps

• Channels concept for understanding npayload's core messaging primitive
• Subscriptions concept for delivery modes and consumer configuration
• Connectors guide for bridging npayload with external systems