{"id":620,"date":"2026-09-10T09:59:13","date_gmt":"2026-09-10T04:29:13","guid":{"rendered":"https:\/\/smppcenter.com\/journal\/?p=620"},"modified":"2026-09-10T09:59:16","modified_gmt":"2026-09-10T04:29:16","slug":"migrating-jasmin-sms-gateway-licensed-support","status":"publish","type":"post","link":"https:\/\/smppcenter.com\/journal\/migrating-jasmin-sms-gateway-licensed-support\/","title":{"rendered":"Migrating From Jasmin SMS Gateway to a Licensed SMPP Platform"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Jasmin&#8217;s Python\/Twisted core, RabbitMQ, and Redis dependencies create a different migration path than a C-based gateway like Kannel. Here is what actually changes when an aggregator or enterprise moves off Jasmin onto <a href=\"https:\/\/smppcenter.com\" data-type=\"link\" data-id=\"https:\/\/smppcenter.com\">licensed SMPP<\/a> infrastructure.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"584\" src=\"http:\/\/smppcenter.com\/journal\/wp-content\/uploads\/2026\/09\/jasmin-sms-gateway-migration-consolidation-1024x584.webp\" alt=\"Abstract illustration of scattered message queue nodes consolidating into a single routing node, representing SMS gateway migration.\" class=\"wp-image-621\" srcset=\"https:\/\/smppcenter.com\/journal\/wp-content\/uploads\/2026\/09\/jasmin-sms-gateway-migration-consolidation-1024x584.webp 1024w, https:\/\/smppcenter.com\/journal\/wp-content\/uploads\/2026\/09\/jasmin-sms-gateway-migration-consolidation-300x171.webp 300w, https:\/\/smppcenter.com\/journal\/wp-content\/uploads\/2026\/09\/jasmin-sms-gateway-migration-consolidation-768x438.webp 768w, https:\/\/smppcenter.com\/journal\/wp-content\/uploads\/2026\/09\/jasmin-sms-gateway-migration-consolidation.webp 1200w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Moving off a component-based open source gateway means consolidating several separately-run services into one operator surface.<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Table of Contents<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li><a href=\"#the-short-answer\">The Short Answer<\/a><\/li>\n\n\n\n<li><a href=\"#tldr\">TL;DR<\/a><\/li>\n\n\n\n<li><a href=\"#jasmin-vs-kannel\">Why Jasmin Migrates Differently Than Kannel<\/a><\/li>\n\n\n\n<li><a href=\"#pre-migration-audit\">Pre-Migration Audit<\/a><\/li>\n\n\n\n<li><a href=\"#component-mapping\">Mapping Jasmin&#8217;s Components to a Licensed Platform<\/a><\/li>\n\n\n\n<li><a href=\"#cutover-runbook\">The Cutover Runbook<\/a><\/li>\n\n\n\n<li><a href=\"#throughput-throttling\">Throughput and Throttling During Cutover<\/a><\/li>\n\n\n\n<li><a href=\"#dlr-reconciliation\">DLR Reconciliation<\/a><\/li>\n\n\n\n<li><a href=\"#what-this-does-not-claim\">What This Article Deliberately Does Not Claim<\/a><\/li>\n\n\n\n<li><a href=\"#next-steps\">Next Steps<\/a><\/li>\n\n\n\n<li><a href=\"#faqs\">FAQs<\/a><\/li>\n<\/ol>\n\n\n\n<h2 id=\"the-short-answer\" class=\"wp-block-heading\">The Short Answer<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Jasmin SMS Gateway is a Python and Twisted-based open source SMPP\/HTTP gateway that depends on RabbitMQ for message queuing and Redis for delivery receipt correlation. Moving off it onto a licensed SMPP platform means retiring three separately-run services (Jasmin itself, RabbitMQ, Redis) and consolidating routing rules that live in Jasmin&#8217;s jCli console into the target platform&#8217;s route configuration, then re-pointing every SMPP client connector and HTTP integration at the new endpoint one route at a time. The safest sequence runs the two systems in parallel, migrates low-risk traffic first, and keeps Jasmin live as a fallback until delivery receipt reconciliation confirms the new platform is producing matching results.<\/p>\n\n\n\n<h2 id=\"tldr\" class=\"wp-block-heading\">TL;DR<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Jasmin&#8217;s architecture is fundamentally different from a single-binary gateway: it splits work across a core process, RabbitMQ, and Redis, plus a jCli telnet console for configuration.<\/li>\n\n\n\n<li>A migration audit needs to inventory every SMPP client connector, every MT\/MO route, every HTTP connector, and every interceptor script configured in jCli, because none of that transfers automatically.<\/li>\n\n\n\n<li>Jasmin&#8217;s default ports (1401 for HTTP API, 2775 for SMPP server, 8990 for jCli) matter only for your own firewall and monitoring cutover, not for anything the target platform inherits.<\/li>\n\n\n\n<li>A route-by-route parallel-run cutover, not a single flip, keeps risk contained: each MT route or SMPP connector moves independently and gets reconciled before the next one moves.<\/li>\n\n\n\n<li>SMPPCenter&#8217;s default account throughput is 10 TPS with ESME_RTHROTTLED (0x00000058) returned on overage, which is frequently lower than a tuned Jasmin connector&#8217;s throughput ceiling, so throughput planning has to happen before cutover, not during it.<\/li>\n\n\n\n<li>SMPPCenter&#8217;s knowledge base gives Kannel-specific configuration guidance but no Jasmin-specific equivalent; treat generic SMPP bind and throttling behavior, as defined in the public specification, as the confirmed baseline rather than an undocumented Jasmin-specific figure.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"jasmin-vs-kannel\" class=\"wp-block-heading\">Why Jasmin Migrates Differently Than Kannel<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Kannel is a single C-language binary (or a small handful of processes: bearerbox, smsbox, wapbox) with configuration held in flat text files that get read at startup. Jasmin is architecturally further from that. Its own documentation describes Jasmin core and its connectors as &#8220;written in Python and mainly based on Twisted matrix, an event-driven networking engine,&#8221; running as a set of services rather than a single process: an SMPP Client Manager for outbound carrier binds, an SMPP Server API for accepting inbound binds from your own downstream customers, a Router for MT\/MO route and filter logic, an HTTP API and RESTful API for MT submission, and DLR and DeliverSM &#8220;Thrower&#8221; services that push delivery receipts and mobile-originated messages out to HTTP endpoints.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Two of those pieces are not optional add-ons, they are load-bearing infrastructure Jasmin&#8217;s own installation documentation lists as required: a RabbitMQ server, used as Jasmin&#8217;s core AMQP broker, and a Redis server, used mainly for mapping message IDs when delivery receipts come back. If either goes down, submission or DLR correlation breaks, independent of whether Jasmin&#8217;s own process is healthy. That is a meaningfully different operational profile than Kannel, where the failure surface is closer to &#8220;is the binary running and is the config valid.&#8221;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/compare\/smppcenter-vs-jasmin-sms-gateway\/\">comparison of SMPPCenter against Jasmin<\/a> and its <a href=\"https:\/\/smppcenter.com\/journal\/kannel-vs-jasmin-vs-smpp-center-choosing-the-best-sms-gateway-software\/\">three-way comparison against Kannel and Jasmin<\/a> cover that decision. What follows assumes the call to move is already made, and the work ahead is moving binds and routes without breaking live traffic.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The practical consequence for migration planning: a Kannel migration is mostly about translating one configuration file&#8217;s worth of binds and routes. A Jasmin migration is about retiring an entire small service topology (Jasmin process, RabbitMQ, Redis) and every piece of routing logic that currently lives across jCli&#8217;s SMPP connector manager and its MT\/MO router, not just a config file. If your team also built custom interceptor scripts (Jasmin supports a scripting layer for modifying or rejecting messages in flight), that logic has no direct equivalent to import and has to be re-implemented against whatever filtering and routing controls the target platform exposes, such as the sender-name, transaction-ID, and mobile-series filtering, and percentage-based or distributed delivery routing, listed on SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/features\/\">features page<\/a>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"pre-migration-audit\" class=\"wp-block-heading\">Pre-Migration Audit<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before touching any live traffic, build a complete inventory. This is the step teams skip when they are in a hurry to get off an aging open source deployment, and it is the step that causes surprises three weeks into cutover.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>List every SMPP client connector configured through jCli&#8217;s <code>smppccm<\/code> interface: carrier host, port, bind type (transceiver, or separate transmitter\/receiver), system_id, throughput setting, and whether it uses TLS.<\/li>\n\n\n\n<li>List every MT route configured through jCli&#8217;s <code>mtrouter<\/code>: which user groups or filters match which connector, and in what order (Jasmin evaluates routes in priority order, so order matters, not just membership).<\/li>\n\n\n\n<li>List every MO route configured through <code>morouter<\/code>: where inbound messages get forwarded, and under what filter conditions.<\/li>\n\n\n\n<li>List every HTTP connector used by the DLR Thrower and DeliverSM Thrower: destination URLs, auth headers, retry behavior your own applications expect.<\/li>\n\n\n\n<li>Document any custom interceptor scripts and what business logic they enforce (content rejection, header rewriting, logging).<\/li>\n\n\n\n<li>Confirm current sustained and peak TPS per connector, measured over your actual traffic, not the theoretical ceiling Jasmin was configured for.<\/li>\n\n\n\n<li>Confirm which downstream customers or internal systems bind to Jasmin&#8217;s own SMPP Server API, since each of those binds needs new credentials and a new endpoint on cutover day, not just your upstream carrier connectors.<\/li>\n\n\n\n<li>Export or screenshot the full jCli <code>persist<\/code> profile as a point-in-time backup before changing anything.<\/li>\n\n\n\n<li>Confirm your Redis and RabbitMQ retention windows, so you know how long in-flight DLR correlation data survives if you need to keep the old stack briefly reachable during reconciliation.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Skipping the downstream-bind item specifically is the most common gap. Teams plan the upstream carrier side carefully and forget that Jasmin&#8217;s SMPP Server API means other systems bind inbound to Jasmin the same way Jasmin binds outbound to a carrier. Every one of those inbound relationships is a separate cutover event with its own credential change.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"component-mapping\" class=\"wp-block-heading\">Mapping Jasmin&#8217;s Components to a Licensed Platform<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Jasmin Component<\/th><th>Function<\/th><th>Target Platform Equivalent<\/th><\/tr><\/thead><tbody><tr><td>SMPP Client Manager (<code>smppccm<\/code>)<\/td><td>Manages outbound SMPP binds to carriers<\/td><td>SMPP client \/ bind configuration in the licensed platform&#8217;s admin panel, per SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/kb\/bind-smpp-session-transceiver-transmitter-receiver\/\">bind session documentation<\/a><\/td><\/tr><tr><td>SMPP Server API<\/td><td>Accepts inbound binds from your own downstream customers<\/td><td>The platform&#8217;s own SMPP server component, included on SMPPCenter&#8217;s Launch SMPP tier and above per current <a href=\"https:\/\/smppcenter.com\/pricing\/\">pricing<\/a><\/td><\/tr><tr><td>Router (<code>mtrouter<\/code> \/ <code>morouter<\/code>)<\/td><td>MT and MO routing and filtering logic<\/td><td>Delivery routing rules and filtering features listed on SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/features\/\">features page<\/a> (percentage-wise, direct, and distributed routing; sender-name, transaction-ID, and mobile-series filtering)<\/td><\/tr><tr><td>HTTP API \/ RESTful API<\/td><td>MT submission over HTTP instead of raw SMPP<\/td><td>The platform&#8217;s own HTTP API, documented at a category level in SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/kb\/default-apis-available-smpp-center-software\/\">default APIs knowledge base entry<\/a><\/td><\/tr><tr><td>DLR Thrower<\/td><td>Pushes delivery receipts to your application via HTTP webhook<\/td><td>Realtime DLR webhook (POST\/GET\/JSON\/XML) listed on the features page<\/td><\/tr><tr><td>DeliverSM Thrower<\/td><td>Pushes inbound MO messages to your application<\/td><td>Same webhook mechanism, MO-side<\/td><\/tr><tr><td>RabbitMQ<\/td><td>Core AMQP broker Jasmin depends on internally<\/td><td>No customer-facing equivalent; this dependency simply disappears, since the licensed platform runs its own internal queuing<\/td><\/tr><tr><td>Redis<\/td><td>DLR ID correlation store<\/td><td>No customer-facing equivalent; disappears the same way<\/td><\/tr><tr><td>jCli interceptor scripts<\/td><td>Custom in-flight message logic<\/td><td>No direct import path; re-implement against whatever filtering and templating controls the target platform exposes, or handle upstream in your own application layer<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The last three rows are the ones worth sitting with. RabbitMQ and Redis are not things you migrate, they are things you stop operating. That is a genuine simplification of your infrastructure footprint, and it is also why &#8220;just export the Jasmin config&#8221; is not a real migration strategy: there is no config file that captures routing logic the way Kannel&#8217;s does, because a meaningful share of Jasmin&#8217;s behavior lives in jCli session state and, if you used them, custom interceptor code.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"cutover-runbook\" class=\"wp-block-heading\">The Cutover Runbook<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This assumes you are not doing a big-bang cutover, which is the wrong approach for anything carrying live commercial traffic. The sequence below moves one route or connector at a time and validates before moving the next.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Stand up the new platform in parallel.<\/strong> Provision your account, confirm your bind credentials, and complete one test bind (transceiver or transmitter\/receiver pair) without touching production routes yet. Confirm the bind matches your expected <a href=\"https:\/\/smppcenter.com\/kb\/bind-smpp-session-transceiver-transmitter-receiver\/\">bind type<\/a>.<\/li>\n\n\n\n<li><strong>Pick the lowest-risk route first.<\/strong> Usually this is your lowest-volume MT route, or a route serving an internal system rather than a paying downstream customer. Do not start with your highest-volume carrier connector.<\/li>\n\n\n\n<li><strong>Duplicate that route&#8217;s logic on the new platform.<\/strong> Recreate the filtering and routing rules manually using the mapping table above. There is no automatic import; treat this as a rebuild, not a migration of config state.<\/li>\n\n\n\n<li><strong>Send a controlled test batch through the new route.<\/strong> Confirm submission acknowledgment, delivery receipt return, and content integrity (encoding, sender ID, long-message concatenation) match what the old Jasmin route produced.<\/li>\n\n\n\n<li><strong>Split live traffic for that one route.<\/strong> If your upstream application can weight traffic (send a small percentage to the new platform, the rest still through Jasmin), use that instead of a hard cutover, so a problem shows up on a fraction of traffic instead of all of it.<\/li>\n\n\n\n<li><strong>Reconcile delivery receipts for 24 to 48 hours minimum.<\/strong> Compare DLR volume and final-state distribution (delivered, failed, expired) between the old and new route before calling that route migrated.<\/li>\n\n\n\n<li><strong>Cut that route fully to the new platform and remove it from Jasmin&#8217;s active routing<\/strong>, but do not decommission Jasmin itself yet.<\/li>\n\n\n\n<li><strong>Repeat steps 2 through 7 for each remaining MT route, then each MO route, then each downstream SMPP Server API bind<\/strong>, in ascending order of risk and volume.<\/li>\n\n\n\n<li><strong>Only after every route has been reconciled and cut over, and only after a full billing cycle has closed cleanly on the new platform<\/strong>, decommission Jasmin, RabbitMQ, and Redis. Keep a cold backup of the final jCli <code>persist<\/code> profile for audit purposes even after decommissioning.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The downstream SMPP Server API binds deserve their own note: unlike your upstream carrier connectors, you do not control the client side of those binds. Coordinate a specific cutover window with each downstream customer, issue new credentials against the licensed platform&#8217;s SMPP server ahead of time, and confirm they have updated their bind configuration before you remove the old bind from Jasmin. Treat each one as a small customer-facing change management event, not a backend swap.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"throughput-throttling\" class=\"wp-block-heading\">Throughput and Throttling During Cutover<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is where migrations from a self-tuned Jasmin deployment most often stall. Jasmin connectors are typically tuned to whatever throughput the operator configured against the upstream carrier&#8217;s actual contracted rate, which for an established aggregator can be well above default settings on a new account elsewhere. SMPPCenter&#8217;s own knowledge base confirms that SMPP client accounts on its platform carry a <a href=\"https:\/\/smppcenter.com\/kb\/control-throttling-over-smpp-connectivity\/\">default throughput of 10 TPS<\/a>, with submissions over that limit rejected using the generic SMPP error code <code>0x00000058<\/code> (<code>ESME_RTHROTTLED<\/code>), and its guidance is to coordinate submission rate and resubmit throttled messages rather than assume the limit will be raised automatically.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>ESME_RTHROTTLED<\/code> is a standard response code defined in the public SMPP specification, not something specific to any one vendor&#8217;s implementation; it is the correct code for any SMPP server enforcing a rate limit against a client. What is platform-specific is the default ceiling and how it gets raised, and on that point the practical step is to confirm your actual sustained and peak TPS from the pre-migration audit against your target tier&#8217;s TPS ceiling (the tier table on SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/pricing\/\">pricing page<\/a> lists TPS limits by tier) before cutting over any high-volume route, and to request the correct tier or a throughput adjustment ahead of the cutover window rather than discovering a mismatch mid-migration when messages start bouncing with throttling errors.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If a route&#8217;s real traffic pattern is bursty rather than flat (batch sends at the top of the hour, for instance), plan for the burst peak, not the daily average. A route that averages 8 TPS but bursts to 40 TPS for five minutes will throttle constantly against a 10 TPS ceiling even though its average looks comfortably under the limit.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"dlr-reconciliation\" class=\"wp-block-heading\">DLR Reconciliation<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Delivery receipt handling is the part of a migration that is hardest to verify by inspection and easiest to get quietly wrong, because a route can appear to be working (messages submit successfully, acknowledgments return) while its DLR correlation is broken, and that failure mode often does not surface until someone downstream asks why delivery reports stopped arriving.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Because Jasmin uses Redis specifically to map message IDs to their eventual delivery receipts, and a licensed platform will use its own internal correlation mechanism, do not assume DLR format or timing will match exactly during the parallel-run window. Concretely:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm the new platform&#8217;s DLR webhook payload format (POST\/GET, JSON\/XML) against whatever your receiving application currently expects from Jasmin&#8217;s DLR Thrower, and adjust your receiving endpoint or use a translation layer if the formats differ.<\/li>\n\n\n\n<li>Run both systems&#8217; DLR streams into a reconciliation log for the same test batch and diff final delivery states rather than just confirming receipts arrived at all.<\/li>\n\n\n\n<li>Pay particular attention to intermediate states (submitted, enroute) versus only final states (delivered, undelivered, expired); some receiving applications only log final states and will silently under-report a formatting mismatch in intermediate DLRs.<\/li>\n\n\n\n<li>Keep the reconciliation window per route long enough to capture your slowest-completing message class; an OTP route resolves in seconds, a low-priority promotional route queued behind carrier-side delays may take hours to reach a final DLR state.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"what-this-does-not-claim\" class=\"wp-block-heading\">What This Article Deliberately Does Not Claim<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/kb\/how-configure-kannel-smppcenter-smpp-server\/\">Kannel configuration knowledge base entry<\/a> specifies a Kannel version requirement (1.4.3 or greater) and an 8-character password requirement for Kannel compatibility. Neither figure has a confirmed Jasmin equivalent published anywhere on smppcenter.com. Confirm exact bind credential format requirements with SMPPCenter directly before a Jasmin cutover, rather than assuming the Kannel figures carry over.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No bulk import tool for moving jCli route or connector configuration into a licensed platform&#8217;s admin panel is publicly documented. The mapping table above describes conceptual equivalents, not a mechanical migration path; plan the rebuild in step 3 of the cutover runbook as manual work.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Custom Jasmin interceptor script logic has no confirmed equivalent feature on the licensed platform side beyond the filtering and routing controls SMPPCenter states on its features page. If your interceptor scripts perform logic more complex than filtering, routing, or templating (custom API calls to third-party systems mid-flow, for instance), that logic likely needs to move into your own application layer rather than into the new platform&#8217;s configuration.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Exact throughput ceilings above the published tier TPS figures, and whether a temporary throughput increase is available during a migration window specifically, are commercial questions SMPPCenter&#8217;s public pages do not answer; treat the tier TPS figures as the confirmed baseline and negotiate directly for anything a specific cutover requires beyond that.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"next-steps\" class=\"wp-block-heading\">Next Steps<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If your team is running Jasmin today and the RabbitMQ and Redis dependencies, or the jCli-based routing logic, have become more operational overhead than they are worth, the tier comparison on SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/pricing\/\">pricing page<\/a> is the starting point for matching your current connector count and TPS requirements to a tier before you begin an audit. For a harder look at whether licensed infrastructure is the right call at all given your current setup, SMPPCenter&#8217;s <a href=\"https:\/\/smppcenter.com\/why-us\/\">why us<\/a> page lays out the operator-facing case directly.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 id=\"faqs\" class=\"wp-block-heading\">FAQs<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Does a Jasmin migration require downtime?<\/strong><br>Not if it is run as a parallel, route-by-route cutover rather than a single flip. Each route or connector can be validated and shifted independently while the rest of Jasmin&#8217;s traffic continues uninterrupted, and Jasmin itself stays available as a fallback until every route is reconciled.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Can Jasmin&#8217;s jCli configuration be exported and imported directly?<\/strong><br>There is no confirmed bulk import mechanism. Route, connector, and filter logic held in jCli session state needs to be manually rebuilt on the target platform using the audit inventory as a checklist, not transferred as a config file the way a Kannel <code>kannel.conf<\/code> can be adapted.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>What happens to RabbitMQ and Redis after migration?<\/strong><br>They are Jasmin-internal dependencies with no customer-facing equivalent on a licensed platform. Once every route has been cut over and reconciled, they can be decommissioned along with Jasmin itself; there is nothing in them that needs to be preserved beyond an audit backup of the final jCli profile.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Will throughput match what Jasmin was configured for?<\/strong><br>Not automatically. SMPPCenter&#8217;s default SMPP account throughput is 10 TPS, and higher tiers publish their own TPS ceilings; a route tuned to a higher sustained or burst rate under Jasmin needs its target tier confirmed against that real traffic pattern before cutover, not after messages start returning <code>ESME_RTHROTTLED<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Do downstream customers who bind to Jasmin&#8217;s SMPP Server API need new credentials?<\/strong><br>Yes. Anyone binding inbound to your Jasmin SMPP Server API is a separate migration event from your own outbound carrier connectors, since you do not control their client configuration. Each needs new credentials against the licensed platform&#8217;s SMPP server and a coordinated cutover window.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">Recent Articles<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/smppcenter.com\/journal\/migrating-kannel-licensed-smpp-platform-runbook\/\">Migrating From Kannel to a Licensed SMPP Platform: A Practical Runbook<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/smppcenter.com\/journal\/ncpr-dnd-scrubbing-bulk-sms-india-filtering-layer\/\">NCPR and DND Scrubbing for Bulk SMS in India: What the Filtering Layer Actually Does<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/smppcenter.com\/journal\/perpetual-license-vs-subscription-smpp-breakeven-math\/\">Perpetual License vs Subscription: The Real Breakeven Math for an SMPP Platform<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/smppcenter.com\/journal\/smpp-bind-types-transmitter-receiver-transceiver\/\">SMPP Bind Types Explained: Transmitter, Receiver, Transceiver, and Where Throughput Breaks<\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n","protected":false},"excerpt":{"rendered":"<p>Jasmin&#8217;s Python\/Twisted core, RabbitMQ, and Redis dependencies create a different migration path than a C-based gateway like Kannel. Here is what actually changes when an aggregator or enterprise moves off Jasmin onto licensed SMPP infrastructure.<\/p>\n","protected":false},"author":1,"featured_media":621,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[683],"tags":[688,68,690,689,687,15,673],"class_list":["post-620","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-migration-guides","tag-jasmin-sms-gateway","tag-message-routing","tag-open-source-sms-gateway-2","tag-rabbitmq","tag-smpp-migration","tag-smpp-server","tag-sms-aggregator-infrastructure"],"_links":{"self":[{"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/posts\/620","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/comments?post=620"}],"version-history":[{"count":0,"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/posts\/620\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/media\/621"}],"wp:attachment":[{"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/media?parent=620"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/categories?post=620"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smppcenter.com\/journal\/wp-json\/wp\/v2\/tags?post=620"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}