What this playbook covers
Most partners come to us from another texting vendor with live clients mid-cycle. That is the normal case, not the hard case, so migration is built into onboarding rather than bolted on. This guide is the full version of that process: what happens, in what order, who does each step, and what can bite if it is done out of order.
It covers texting-first books, which is where the real migration work lives: phone numbers, 10DLC registrations, lists, and templates. Voice, mail, and digital programs move alongside with far less ceremony because they carry no registrations to transfer.
The pre-migration audit
Everything starts with a fifteen-minute call and your current invoice. Before anything moves, we build a complete inventory of what you are running today. If the numbers do not work in your favor, we tell you on that call and nothing moves.
What the audit produces
- A line-by-line rate comparison against your current invoice, so the economics are settled before any work starts
- A registration and number inventory: every 10DLC brand and campaign, every long code and toll-free number, and which client each belongs to
- A send-calendar map of every wave scheduled in the next sixty days, because the calendar drives the sequence
- A written migration plan with dates, including anything that cannot transfer and has to be re-filed
What to gather before the call
You do not need all of this to book the audit, but each item you bring makes the plan more precise: your most recent invoice, a list of active clients and which are mid-flight, your current vendor contract with its notice terms, and login access or an export of your current templates and lists if your vendor allows it.
What moves, asset by asset
A texting operation is four kinds of asset, and each moves differently. This table is the whole migration at a glance.
| Asset | How it moves | Who does it |
|---|---|---|
| Phone numbers | Ported end to end, long codes and toll-free alike. Porting is scheduled so a number is never in transit during one of its own sends. | FullPAC |
| 10DLC registrations | Brands and campaigns tied to your clients are transferred where the registrar allows it and re-filed where it does not. The audit tells you upfront which is which. | FullPAC |
| Lists and universes | Exported from your current platform and rebuilt inside each client's sub-account, with opt-outs preserved and deduplicated. | FullPAC, from your export |
| Templates and creative | Rebuilt in your sub-accounts and re-checked against current carrier content rules before the first send. | FullPAC, from your export |
| Reporting history | Your old platform's reports do not transfer between vendors. Export them before you lose access; new reporting accumulates from the first send. | You, before access ends |
The 10DLC question, specifically
Registrations are the asset partners worry about most, because they were slow and expensive to get the first time. The honest picture: registrations tied to your clients’ own brands can generally be transferred or re-filed, and we handle the paperwork either way. Where a re-file is unavoidable, you will know from the audit, not discover it mid-move. For the full registration process, field by field, see the 10DLC Quick Start Guide.
Sequencing around live sends
The single rule that protects your clients: nothing about a client moves during that client’s send window. The migration plan is built from your send calendar backwards, not from our convenience forward.
Freeze windows are mapped first
Every scheduled wave in the next sixty days gets a freeze window around it. No port, registration change, or list rebuild for that client lands inside its window.
Assets move in dependency order
Registrations before numbers, numbers before lists, lists before templates. A number that ports before its campaign registration is ready cannot send, so the order is not negotiable and we enforce it per client.
Parallel running covers the tight spots
Where a client’s calendar leaves no clean gap, both platforms run side by side: scheduled sends finish on the old platform while the new one is proven with a test universe. Nothing cuts over until you have seen it work.
The pilot client
The first client to move is a deliberate choice, not whoever is alphabetically first. A good pilot has a live program substantial enough to prove the migration end to end, but a calendar forgiving enough that a one-day slip costs nothing.
Picking the pilot
- A real, active program: a dormant client proves nothing
- No must-hit send inside the next two weeks
- A typical asset mix: at least one registration, one list, one template set
- A client relationship where you are comfortable watching closely
What “proven” means
The pilot is done when the client has completed a full send cycle on FullPAC: list loaded, campaign registered and active, wave sent, replies handled, opt-outs synced, and the white-label report delivered under your brand. Every one of those is checked before the rest of the book moves. Most pilots reach this point within days of the audit.
Rolling the rest of the book
After the pilot, the remaining clients move in batches you choose. Most partners group by urgency: clients between sends move first, clients deep in a flight move last, and anything wrapping up this cycle can simply start its next race on FullPAC and never migrate at all.
Each batch repeats the pilot’s sequence with the same freeze-window rules. Your named account partner tracks every client’s state on a shared checklist, so at any moment you can see exactly which assets have moved for which client. The pace is yours: some partners finish a dozen clients in three weeks, others spread it across a quarter to match their cycle.
If something goes wrong
A serious playbook says what happens when a step fails, so here it is. Every step in the sequence is individually reversible before cutover: a port can be cancelled while pending, a rebuilt list can be discarded, and parallel running means the old platform is still standing until you decide it is not.
If you stop a migration halfway, you keep everything: your data and registrations remain yours throughout, exports are available at any point, and there are no exit fees. That is not a courtesy, it is a contractual term of the Partner Protection Guarantee, and it applies from the first day of onboarding, not after some loyalty threshold.
The migration checklist
The condensed version of everything above, in order. Print it, or just watch us work through it.
- Book the audit with your current invoice in hand
- Bring your vendor contract and flag notice or auto-renewal terms
- Export reporting history for every client while access lasts
- Review the written migration plan and its dates
- Approve the pilot client and its freeze windows
- Verify the pilot's full send cycle under your brand
- Batch the remaining clients and set the pace
- Confirm every number, registration, list, and template per batch
- Close the old platform only after the last client cuts over
Questions partners ask
Will my clients notice the switch?
That is the design goal of the whole sequence. Numbers port, sender identity stays consistent, and reporting continues under your brand. Most partners migrate mid-cycle without telling their clients anything happened.
How long does a full book take?
A single pilot client is usually live within days. A full book of a dozen clients is typically weeks, spread to suit your send calendar rather than compressed into one risky weekend. The audit produces a written plan with dates for your specific book.
Do I have to move everything at once?
No, and you should not. The playbook is built around moving one client first, proving the migration end to end, then moving the rest at your pace. Race by race, cycle by cycle.
What does the migration cost?
Migration work is part of partner onboarding, not a billed service. Where a 10DLC re-file is unavoidable, the registration fees are the same third-party fees you would pay anywhere, and the audit tells you about them upfront.
What happens to my current vendor contract?
Read it before the audit and bring it. Notice periods and auto-renewal dates change the sequencing, not the feasibility. Running both platforms in parallel through a notice period is a normal pattern.