Here's the failure mode nobody warns you about when you migrate SMS providers: the phone numbers move, the messages keep sending, everything looks fine — and your legal consent record is gone. Every subscriber who opted in on your old platform is now, as far as your new records show, a cold number you're texting for the first time. The list works. The proof that it's allowed to work doesn't.
Full disclosure: I work for Ready, an SMS platform, so I have a horse in the migration race. But this isn't a "switch to us" pitch — the consent-preservation problem is identical no matter where you're moving to or from, and getting it wrong is expensive whether or not Ready is involved. So let's talk about the fields that actually matter.
Why "the numbers transferred fine" isn't the finish line
When an ecommerce brand exports its SMS list, most people grab three columns: phone number, first name, maybe email. That's a contact export. It is not a consent export.
TCPA consent isn't a boolean stored on the number. It's a record — a claim you can defend if a plaintiff's attorney asks, "Prove this person agreed to receive marketing texts." That defense lives in metadata that most exports silently drop:
- When consent was captured (timestamp, to the second, ideally with timezone)
- How it was captured (source: checkout checkbox, keyword opt-in, quiz, popup)
- What they saw when they agreed (the exact disclosure text and program terms)
- From where (IP address, and for keyword opt-ins, the inbound message itself)
If those fields don't survive the move, your new platform shows a list of numbers with no provenance. You didn't lose the subscribers. You lost the ability to prove they're subscribers — which, in a TCPA dispute where exposure runs $500 to $1,500 per text, is the only thing that matters.
The consent fields that must transfer — with a checklist
Before you export anything, make a list of what you're actually pulling. Here's the minimum set that keeps an opt-in defensible after a migration:
| Field | Why it matters | What breaks if it's missing |
|---|---|---|
| Consent timestamp | Proves when they opted in; anchors the audit trail | Can't show consent predated the first text |
| Opt-in source / method | Distinguishes checkout vs. keyword vs. quiz | Can't defend the type of consent (marketing vs. transactional) |
| Disclosure text shown | The exact language they agreed to | Can't prove they saw required program terms |
| IP address (web opt-ins) | Ties consent to a device/session | Weakens the record in a dispute |
| Inbound keyword message (SMS opt-ins) | The subscriber's own "START"/"YES" | No first-party proof of double opt-in |
| Opt-out (STOP) status & date | Suppression list — who you can't text | Re-texting someone who opted out = fresh violations |
| Consent status (subscribed/pending/unsub) | Current state per contact | You blast people mid-lifecycle |
The last two are the ones that quietly cause the most damage, so they get their own section below.
If your current provider won't export these — some do lock consent metadata behind their platform — that's a red flag worth raising before you commit to the switch. You can't defend a record you can't produce.
The STOP list is the field that gets people sued
Every subscriber who texted STOP on your old platform is on a suppression list there. That suppression is honored by that platform. It does not follow the phone number to a new one automatically.
Migrate carelessly and here's what happens: someone opted out six months ago, their number is still in your master export (because opt-outs stay in your CRM as suppressed, not deleted), and your new platform imports it as a fresh, mailable contact. Your first blast texts a person who explicitly told you to stop. That's not a gray area — it's a clean, provable violation, and it's the kind of thing that turns one annoyed recipient into a demand letter.
So the migration checklist has a hard requirement: **export your opt-out / STOP list separately and import it as a suppression list first, before you import anything mailable.** Load the "do not text" set into the new platform before the "please text" set. Order matters.
Ready handles inbound STOP automatically — an opt-out propagates so the contact can't be messaged again across any campaign — but that only protects opt-outs that happen on Ready. A STOP that happened on your old system is historical data you have to bring with you. No platform can honor an opt-out it was never told about. This is the same "who owns the opt-in list" problem agencies hit at offboarding, and the fix is the same: treat the suppression list as a first-class export, not an afterthought.
Marketing vs. transactional consent doesn't survive on its own
An "Order Shipped" text and a "20% off this weekend" text ride on completely different consent. The first is transactional and permitted by the purchase relationship; the second requires express written marketing consent. Your old platform may have tracked which subscribers gave which — through the opt-in source field.
If you flatten every contact into one "subscribed" bucket during migration, you lose that distinction. Now you can't tell who agreed to promos and who only ever agreed to shipping updates. Text the shipping-only crowd a promo and you've crossed the line the transactional-vs-marketing consent post walks through in detail.
Preserve the opt-in source/method field and you can re-segment on the other side: checkout-with-marketing-checkbox in one group, keyword opt-ins in another, order-tracking-only in a third. That segmentation is your proof-of-consent by cohort.
A sequenced cutover that doesn't reset anyone
Don't do a big-bang switch. Sequence it so consent is verifiable at each step:
- Export everything, including metadata. Pull the full consent field set from the checklist above — not just numbers. Keep the raw export file; it's your audit trail if the new platform's import mangles anything.
- Export the STOP/suppression list separately. This is non-negotiable and goes in first.
- Register your 10DLC brand and campaign on the new platform. Your registration doesn't transfer either — new platform, new campaign registration. Match the campaign use-case to what you actually send so delivery doesn't silently throttle. (Here's why use-case mismatch kills deliverability.) With Ready this runs in-app; brand + campaign registration is roughly ~$10/mo per brand and ~$20/mo per campaign, and most approvals land same-day.
- Import suppression list first. Load "do not text" before "text these."
- Import contacts with consent metadata mapped. Map timestamp, source, and IP into fields on the new platform — don't let them fall on the floor during CSV import.
- Spot-check before any send. Pull 20 random contacts and confirm their consent timestamp, source, and opt-out status all came through. If they didn't, stop and fix the mapping.
- Run a small first send, not a full blast. A few hundred contacts, watch for STOP replies and delivery errors, then scale up.
Don't run both platforms sending simultaneously to the same list — that's how you double-text people and rack up complaints. If you're moving multiple brands or clients, the mid-month cutover sequencing post covers the billing-overlap traps too.
What Ready's compliance stack does — and doesn't — do here
Since consent is the whole point, here's an honest scope of what carries over automatically versus what's on you:
Ready handles going forward:
- Automatic STOP/opt-out honoring, propagated across campaigns
- Quiet-hours enforcement based on the recipient's local time (relevant if your old blasts were hitting West-Coast customers at 6am)
- Consent/attestation capture recorded for bulk and API sends
- In-app 10DLC registration, so you're not waiting weeks on manual A2P onboarding
- Optional litigator/DNC scrubbing at $0.005/contact — worth running your migrated cold segments through once
Still your responsibility:
- Bringing your historical consent metadata and STOP list with you
- Segmenting marketing vs. transactional consent correctly on import
- The truthfulness of the opt-in records you migrate
Compliance is ultimately the sender's job. A good platform reduces risk and automates the tedious parts; it can't retroactively manufacture consent you never captured, and it can't honor an opt-out you didn't import. That's the honest line.
The practical takeaway
A platform migration is a data-integrity project wearing a marketing-tool costume. The numbers moving is table stakes. Whether the consent record — timestamp, source, IP, disclosure text, and especially the STOP list — moves with them is what determines if your first send on the new platform is a clean campaign or a stack of provable violations.
Export the metadata. Import the suppression list first. Spot-check before you scale. Do those three things and the switch is boring, which is exactly what a migration should be.
If you're planning a move and want to see how the in-app 10DLC and STOP handling fit your list, the Ready product page lays out the compliance stack, and there's a step-by-step Twilio migration playbook if that's where you're coming from. You can start with 2,500 free credits and test the import on a small segment before you commit the whole list.