SMS panel migration: from SaaS to self-hosted, step by step

Leaving a rented SMS panel is a project with a known shape. The parts that go wrong are always the same ones: a sender ID registered under the vendor’s name, an API hostname your clients hard-coded, a ledger that does not export, a cut-over done on a Friday. This is the SMS panel migration checklist we use when we move a reseller onto their own platform, written so you can run it with any self-hosted platform. It covers the move from a SaaS panel to self-hosted in seven stages: inventory, exports, the new platform, the items that do not travel, the parallel run, cut-over and the shutdown of the old panel. The SaaS panels comparison covers whether to leave; this guide covers how.

Stage 0: decide the calendar by the slowest item

Before touching data, list the things that run on somebody else’s clock. Sender ID and short code re-registrations under your own entity, regulatory identities (DLT in India, 10DLC in the United States, and their equivalents), carrier approvals for your own SMPP binds, and, if you add WhatsApp, Meta’s business verification. Each is weeks, not days, and none can be started too early. Start all of them in the first week, in parallel with everything below, and the rest of the migration will finish waiting for them rather than the other way around.

Stage 1: the SMS panel migration inventory

Write down, from the panel’s admin console, one line per item:

• Clients: every account, its billing model (prepaid credit, wallet, postpaid), its current balance, its rate plan, its contact person, and whether it integrates by console, HTTP API or SMPP bind.
• Rate plans and routes: every price plan, every destination row, every supplier route with its credentials and cost.
• Sender IDs and numbers: alphanumeric IDs, long numbers, short codes, and under whose entity each is registered with each carrier.
• Integrations: every hostname your clients call (API, panel URL, webhook endpoints they receive receipts on), and whether it is on your domain or the vendor’s.
• Data volumes: contacts, templates, campaign history, delivery logs, invoices, by month.
• Contracts: the panel’s notice period, and every client contract that mentions the panel’s name or URL.

This inventory is the migration plan. Everything below is the inventory with dates on it.

Stage 2: get real exports while you are still a customer

Ask for exports now, before you give notice, because the answer is friendlier while you are paying. Ask for each item on the inventory in a machine-readable format (CSV is fine) and open every file: check row counts against the console, check that consent records travel with the contacts, check that delivery logs carry the message ID and the final status and not just a count. “We support CSV export” and “the file contains what my clients would need” are different sentences.

Expect the ledger to be the least portable thing in the building: balances and invoice history often export as PDFs or not at all. If so, reconstruct balances from your own records (invoices you issued, payments you received, the panel’s current balance screen on a dated screenshot) and agree the opening balance with each client in writing at cut-over. That is a one-line email per client and it prevents every dispute you would otherwise have.

Stage 3: stand up the new platform on your own domain

Install the platform on your own server, on your own domain, before any client moves. Two rules from the comparison guide apply from this day forward: the panel and the API live at hostnames you own (panel.yourcompany.com, api.yourcompany.com), and sender IDs and regulatory identities are registered under your entity wherever the regulator allows it. Then:

1. Connect your own carrier contracts as supplier routes, and test each with real handsets in each destination before any client traffic touches it.
2. Rebuild the rate plans from the export, per destination and per client tier, and put a margin floor under every row (the billing guide explains the three billing models and why the model is chosen at account creation and locked afterward, so decide it now).
3. Create the client accounts with the right billing model, rate plan, sender IDs and contacts, but with sending disabled and balances at zero until cut-over.
4. Import contacts, consent records and templates. A business tip we give every buyer: import the opt-in records with the contacts, so you are compliant on day one instead of rebuilding consent later.
5. Import history if you can. Campaign history and delivery logs are worth carrying across so clients keep their reports; on Smppcube this is the difference between the Standard import (contacts, templates, sender and route configuration) and the Full migration (everything plus send history, campaigns and billing records) on the pricing page.
6. Set up the SMPP server for the clients who bind, with per-account credentials, throughput caps and IP allowlists ready to hand out; on Smppcube the SMPP server and the HTTP API are part of the platform, not an add-on.

Stage 4: the items that do not travel

Four things need their own plan because no export carries them.

The API hostname. If your clients call api.vendor.com, their code has to change or something has to answer at the same interface. The better option is a compatibility layer on your platform that accepts the old request shape and maps it to the new API, so a client’s integration keeps working on the day their traffic moves; they can migrate to your native API at their own pace. If the old hostname is the vendor’s, you cannot take it with you, so the compatibility layer lives at your hostname and each client changes one line: the host.

Webhooks. Clients who receive delivery receipts by webhook have configured that on the old panel. Collect each client’s receipt URL now and configure it on the new platform before cut-over, so the first message they send through you produces a receipt where they expect it.

Sender IDs, short codes, regulatory identities. Re-register under your entity, per carrier, per country. Where the vendor holds them and will not release, the client’s sender ID may change, which is a conversation to have early and honestly, with the date on which their messages will carry the new one.

SMPP binds. Each binding client needs new host, port, system_id, password, allowed IPs and throughput cap, and a test window on your test route before their live traffic moves. Send the credential pack in one document and schedule a 30-minute test with their engineer.

Migration fails on the items nobody exported, not on the ones everybody did. Hostnames, webhooks, sender IDs and binds are the plan; the CSV files are the easy part.

Stage 5: the parallel run

Keep the old panel live and paid for 60 to 90 days after the new platform is ready. Move one friendly, low-volume client first, ideally one who will tell you the truth. Their traffic runs on your platform, your routes, your ledger; the old panel stays as fallback. Reconcile daily: messages sent, receipts matched, balance movements, against what the client sees. When a week passes with nothing to explain, move the next client, and the next. Move the largest client last, once every boring problem has been found by the small ones.

During the run, three checks belong on a daily list: receipt latency per route (a carrier bind that is slower on your platform than on the panel is usually a window or throttling setting), margin per client against the old panel’s blended price (this is where you see the margin tax disappearing), and support tickets by category (a spike in “where is my receipt” points at a webhook, not a route).

Stage 6: cut-over, client by client

For each client, cut-over is a dated checklist: balance agreed in writing, sender IDs live under your entity, integration tested (API compatibility layer or new credentials, webhook receiving receipts, SMPP bind tested on the test route), sending enabled, first campaign watched end to end, old panel account set to receive-only or disabled. Do it on a Tuesday morning with the client’s contact reachable, never on a Friday.

Communication is most of the work. A short note to each client a month ahead (“we are moving to our own platform, here is what changes for you, here is what does not”), a reminder a week ahead with their specific date, and a confirmation on the day. Clients leave over surprises, not over changes.

Stage 7: shut the old panel down properly

When the last client has moved and the parallel run has been quiet for a month: take a final export of everything, keep it in your archive with the date, revoke every API key and integration the panel held, remove the panel’s IPs from your carrier allowlists, give notice according to the contract, and confirm in writing that your data has been deleted from their systems. Then close the account. The double payment stops here, and every month from now on the platform fee that scaled with your traffic is margin on your own ledger.

What it costs, and what it is worth

Budget the migration honestly: two to six weeks of elapsed time, most of it waiting on carriers, plus 60 to 90 days of paying twice, plus whatever the new platform charges for the import. At the volumes where leaving makes sense, that total is smaller than one or two months of the per-message platform fee you are leaving behind, and unlike that fee it is paid once. On Smppcube, migration of users, routes, rate cards and balances is a scoped, standard part of the build, and the Standard import and Full migration options are priced on the pricing page rather than quoted by surprise. Whatever platform you choose, the rules that make the exit cheap are the same two you should have applied on your first day: your domain, your registrations.