Moving Bulk SMS Providers Without Losing Your DLT Approvals

Switching bulk SMS providers in India is rarely an integration problem. The API is a few lines either way. What takes the time is DLT — the registration framework every commercial sender operates under — and a migration planned without accounting for it will go quiet at exactly the wrong moment.

What actually has to move

Under the DLT regime a business registers as an entity, registers its sender headers, and registers content templates. Messages are then scrubbed against those registrations before delivery. Anything not matching a registered template is rejected.

The entity registration belongs to you. Headers and templates are tied to your entity, but the operational link between them and a provider has to be established for the new provider before it can send on your behalf. This is the step that surprises people, because nothing about it is under the new provider's control — it depends on approvals that move at their own pace.

Sequence that works

1. Inventory what you send. Every distinct message, categorised as transactional, service-implicit, service-explicit or promotional. Most businesses find messages nobody remembers configuring — a password reset from a system replaced two years ago, a birthday greeting.
2. Export template text exactly. Registered templates match on content with variable placeholders. A single changed word makes a template a different template. Copy the registered text verbatim rather than retyping from the application.
3. Get the new provider linked before touching anything. Headers and templates associated with the new provider while the old one still runs. This is the long pole; start here.
4. Send one real message per template. Not a test string — the actual template with real variables, to a real handset on each major operator. Delivery reports lie less than dashboards.
5. Move one low-risk flow first. A marketing message, not the OTP. If something is wrong, you find out on a message nobody is blocked by.
6. Move OTP and transactional last, and keep the old provider active but unused for a couple of weeks.

The failure that hurts most

OTP delivery. It is the flow with the least tolerance — a customer cannot log in, cannot complete a payment, and support has no answer. Move it last, and before you do, check delivery latency rather than just delivery success. An OTP arriving in ninety seconds is a failed OTP in practice, because the user has already requested another.

Ask the new provider what route your transactional traffic takes and what their typical delivery latency is on it. Then measure it yourself for a week before cutting over.

Things worth checking during evaluation

• Delivery reports per message with operator-level status, not an aggregate percentage.
• Retry behaviour when a handset is unreachable, and whether you can control it.
• Rate limits that will not throttle a result-day or fee-reminder burst.
• Unicode handling if you send in Hindi or other Indian languages — character limits per message differ and cost follows.
• A sandbox that does not consume credits.

Keep both live longer than you think you need

The cost of running two providers for a fortnight is small. The cost of discovering a broken template during an admission cycle or a fee deadline is not. Keep the old credentials valid and the failover path documented until a full billing cycle has passed cleanly on the new one.

About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.