{"id":618,"date":"2026-09-08T10:28:59","date_gmt":"2026-09-08T04:58:59","guid":{"rendered":"https:\/\/smppcenter.com\/journal\/?p=618"},"modified":"2026-09-08T10:29:01","modified_gmt":"2026-09-08T04:59:01","slug":"migrating-kannel-licensed-smpp-platform-runbook","status":"publish","type":"post","link":"https:\/\/smppcenter.com\/journal\/migrating-kannel-licensed-smpp-platform-runbook\/","title":{"rendered":"Migrating From Kannel to a Licensed SMPP Platform: A Practical Runbook"},"content":{"rendered":"\n

A step-by-step runbook for moving a production SMS gateway off Kannel and onto a licensed SMPP platform<\/a><\/strong>, covering the pre-migration audit, credential and bind mapping, parallel-run cutover, throughput differences, and DLR reconciliation.<\/p>\n\n\n\n

\"Abstract
Moving a multi-process open-source gateway to a single licensed platform is an architecture change, not just a config swap.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h2>\n\n\n\n

Publishing note: WordPress does not auto-generate anchors from headings. For each H2 below, set the matching HTML anchor manually in the block editor (Block settings > Advanced > HTML anchor) so these links resolve.<\/em><\/p>\n\n\n\n

    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. Why Teams Move<\/a><\/li>\n\n\n\n
  4. Kannel Architecture Recap<\/a><\/li>\n\n\n\n
  5. Mapping The Pieces<\/a><\/li>\n\n\n\n
  6. Pre-Migration Audit<\/a><\/li>\n\n\n\n
  7. The Runbook<\/a><\/li>\n\n\n\n
  8. Throughput And Throttling<\/a><\/li>\n\n\n\n
  9. DLR Reconciliation And Testing<\/a><\/li>\n\n\n\n
  10. Common Pitfalls<\/a><\/li>\n\n\n\n
  11. What This Article Deliberately Does Not Claim<\/a><\/li>\n\n\n\n
  12. Next Steps<\/a><\/li>\n\n\n\n
  13. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    <\/p>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    Moving a production SMS operation off Kannel is a bind-and-cutover exercise, not a rewrite. Kannel’s bearerbox<\/code>, smsbox<\/code>, and (optionally) sqlbox<\/code> processes each map to a piece of functionality that a licensed platform like SMPPCenter<\/a> delivers as one bound application, so the migration work is mostly about auditing what your current smsc.conf<\/code> and routing rules actually do, replicating that behavior on the new side, running both systems in parallel against a slice of live traffic, and cutting over route by route once delivery receipts reconcile. The risk is almost never the SMPP bind itself; it is silently losing a routing rule, a retry policy, or a DLR mapping that lived only in Kannel’s configuration and nobody wrote down.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n