Starting from nothing is easy. Moving a programme that already works means protecting what you have while changing the pipe it runs through, and there are four specific ways that goes wrong.
The four risks
- Double-sending. Both the old SMS automation and the new iMessage one fire. The customer gets two messages and concludes you are disorganised.
- Losing consent provenance. Your SMS consent records exist for a reason. Migrating contacts without carrying the source and date across destroys the evidence you would need.
- Changing the number. Customers have saved your SMS number. A new number is a new stranger, and your first message from it is judged accordingly.
- Ramping too fast. Your SMS number was warm. Your new iMessage line is not, and pushing existing volume through it on day one is how it gets flagged.
The sequence that works
| Phase | What you do | Duration |
|---|---|---|
| 1. Parallel, one play | Move a single play to iMessage for a slice. SMS keeps everything else | 2 weeks |
| 2. Compare | Outcome rate, not reply rate, against the SMS control | 1 week |
| 3. Warm up | Ramp the iMessage line slowly while SMS carries the volume | 2–4 weeks |
| 4. Route by device | Detect iMessage reachability; route accordingly | Ongoing |
| 5. Retire the duplicate | Switch the SMS version of the migrated play off. Not the number | — |
Never migrate a play in both channels at once
The single most common migration failure is leaving the SMS automation enabled "as a safety net" while the iMessage one goes live. Every customer on iMessage now gets both. Route by reachability instead: one message per customer, chosen by device, decided in one place in your code.
Carrying consent across properly
Consent to receive text messages from you generally covers messaging you regardless of which pipe delivers it — but the record needs to survive the migration. Carry the source and the date, not just a boolean, and keep the original SMS consent evidence rather than overwriting it.
Also carry the suppression list. Someone who replied STOP to your SMS must not receive an iMessage. That is the migration mistake with legal consequences, and it happens because opt-outs live in the old platform and nobody exports them. What consent has to look like.
Keep the SMS number
Do not retire it. You need it for the Android half of your list, as a fallback when the iMessage line degrades, and because customers have saved it. The end state for most businesses is both channels with routing in front, not a replacement.
The warm-up is not optional
Your SMS programme might send 500 messages a day comfortably. A new iMessage line will not. Ramp from tens to hundreds over a few weeks while SMS carries the remainder, and watch the delivered rate as you go. The schedule, and what to monitor.
Migration checklist
- One play moved, to a slice, with an SMS control group.
- Outcome rate compared — not reply rate, which will flatter iMessage.
- Consent records carried across with source and date intact.
- SMS suppression list imported before the first send.
- Routing by device reachability, decided in one place.
- Old SMS automation for the migrated play switched off, not left as a net.
- SMS number retained for Android and for fallback.
- Delivered-rate alerting live before volume increases.