Start where the upside is biggest and the content is most visual or interactive, a promotional flow with images and a buy button, or appointment reminders with confirm/reschedule. Prove the lift, then roll RCS out across the rest of your messaging.
A platform that handles registration, verified-sender approval, and fallback turns migration into a configuration step rather than a project. The SimplyRCS platform is built to manage the carrier approval and fallback so you can move flow by flow. If you already run on GoHighLevel, that migration is mostly turning RCS on inside the automations you already have, which we set up with you on a call (book a demo).
Plan the calendar around the parts you cannot compress. Brand and campaign registration and verified-sender approval involve review by parties outside your control, so treat them as lead time to start immediately rather than as a task to schedule once the content is ready. The work that is genuinely yours, mapping flows, writing templates, wiring the API and webhooks, can happen in parallel while approval is in progress, and teams that sequence it the other way lose weeks waiting with everything else finished.
Consent is the question that most often goes unasked, and it is worth resolving before the first send rather than after a complaint. A customer who opted in to receive texts from you has, in the ordinary case, opted in to messages from your brand rather than to a particular transport, and RCS with SMS fallback delivers the same programme they agreed to. That said, the scope of the original consent still governs: an opt-in collected for delivery notifications does not become permission for promotional offers because the channel got richer. Check that your opt-in language and privacy policy describe what you now send, keep the record of when and how each consent was captured, and take advice if your existing wording named SMS narrowly.
Sequence the flows by how easy the result is to defend. Appointment or delivery confirmations first, because no-show and failed-delivery rates are numbers the business already tracks and the improvement is legible without a marketing argument. Then reminders and status updates, which reuse the same templates and integration. Then promotional and conversational flows, once the verified sender is familiar to the audience and you have real delivery data. Keep the SMS version of each flow running until its RCS replacement has been measured, and keep a holdout so you can attribute the difference rather than assert it.
Migration, step by step
Six steps. The first two involve review by parties outside your control, so start them on day one and do the rest in parallel.
Step 1. Register the brand and campaigns. File the 10DLC brand record and one campaign per use case with The Campaign Registry, with screenshots of the live consent flow attached; this is the SMS-fallback side of the programme and it is what most rejections are about. How 10DLC registration works walks through it.
Step 2. Submit the verified RCS sender. Create the agent profile (name, logo, colour, use case) and submit it for Google and carrier approval. Allow two to four weeks on SimplyRCS, where the filing is done for you, and four to six on a self-serve platform.
Step 3. Turn on automatic fallback. Every send goes out RCS-first with a per-recipient fallback to SMS or MMS, so the programme keeps its full reach from the first message. Write the plain-text fallback version first and treat the rich version as an upgrade on top of it.
Step 4. Convert the highest-value flows first. Appointment and delivery confirmations, then reminders and status updates, then promotional and conversational flows. Start where the result is a number the business already tracks.
Step 5. Measure against the SMS version. Keep the SMS version running for a control group and compare delivered-as-RCS share, read rate, tap rate and the outcome the flow exists for, confirmations or conversions, before moving volume.
Step 6. Expand, and re-check consent scope. Roll the remaining flows across once the first ones have proven the lift. Existing SMS consent generally carries to RCS as the same programme, but the original scope still limits what you may send; anything outside it needs a fresh opt-in.
Keep the numbers, re-file the rest, run in parallel
Most programmes are not starting from nothing: they move from an SMS vendor or a CPaaS API, with numbers, registrations and consent records already in place. Three things keep that move safe.
Keep the numbers. Customers should keep seeing the number they know, now with the verified name on top. A long code moves by standard number porting on a Letter of Authorization, a toll-free number by a change of Responsible Organization, and a short code carrier by carrier. Long codes and toll-free numbers carry no carrier migration fee; short-code migrations carry carrier-set fees, passed through at cost: $500 T-Mobile, $250 Verizon, $150 Claro. The account name and address on the request must match the losing provider's record exactly, which is the commonest reason a port is rejected. Porting a number to a new messaging provider has the process, and moving from Twilio without losing your numbers walks through the most common case.
Re-file what does not travel. The 10DLC brand and campaign registrations and the verified RCS agent stay with the old provider; the new one files them again. They ask for the same legal entity, EIN, website and opt-in proof, so prepare one document set and reuse it word for word: a mismatch between the filings is the commonest reason a launch slips. 10DLC vs RCS explains why both are needed.
Run in parallel. Keep the old provider live while the new one carries a first flow, typically order confirmations or the weekly promotion, and compare delivered-as-RCS share, read rate and tap rate side by side before moving the rest. No message class should be without a route at any point. SimplyRCS runs in parallel with the outgoing provider until you cut over.
Make the fallback safe
Fallback is what protects reach during the move, so it has to be driven by delivery status rather than by a timer, or some customers get the same message twice. The safe sequence: send the RCS message and wait for its DELIVERED receipt for a window that suits the message (minutes for a passcode, longer for a promotion); if no receipt arrives, revoke the RCS message; send the SMS version only if the revoke succeeds, keyed to the original message ID so nothing goes out twice. How does RCS fall back to SMS? has the full sequence and the API calls.
Plan the audience in three parts. A customer receives the RCS version only when the phone supports it, RCS is switched on with a data connection, and your verified agent has launched on that customer's carrier. Everyone else receives the SMS version, which carries no verified identity, so it should name your business in its first words. Device capability (roughly 87% of US smartphones by SimplyRCS's own derivation) is not your reachable audience; your delivery reports are.
What changes on the bill
On SimplyRCS the per-message rate does not change with the channel: an RCS text segment costs the same as an SMS segment ($0.0039) and a card, carousel or media message the same as an MMS ($0.0150), with no monthly platform fee on either. What differs is the carrier fee, passed through at cost on its own line: RCS and SMS have separate carrier schedules, and the RCS fee is slightly higher on most carriers (every carrier's fees). A verified sender also carries one-time charges: a $250 RCS Sender ID setup and review (waived with Premium Support), $200 a year for the Aegis review, and a $500 T-Mobile activation where it applies. To price a month of your own volumes line by line, with every rate sourced and dated, use the cost worksheet.
Pre-migration checklist
- Legal business name, EIN and address ready for brand registration, matching each other exactly.
- A screenshot of every live opt-in flow, with its disclosure wording.
- Logo, brand colour and a one-line agent description approved by whoever owns the brand.
- Each existing SMS flow mapped to a use case (transactional, promotional, OTP) and an owner.
- The plain-text fallback written for every message before the rich version.
- Numbers to keep listed, with their type (10DLC, toll-free, short code), so porting can start.
- Webhooks or reporting in place to see delivered-as-RCS share and taps from day one.
- A control group and a success metric agreed for the first flow.
- Migration is additive: keep SMS fallback, add RCS on top, no risky cutover.
- Steps: register brand/campaign → verify sender → enable fallback → convert high-value flows → measure → expand.
- Begin with visual/interactive, high-value flows to prove the lift early.
- Start registration and sender approval immediately, and do the content and integration work in parallel with the review.
- Existing SMS consent generally carries to RCS as the same programme, but the original scope still limits what you may send.
- Migrate confirmations first, keep the SMS version running until measured, and hold out a control group.
- Keep your numbers (long codes and toll-free port with no carrier fee; short codes carry carrier-set fees), re-file 10DLC and the RCS agent from one document set, and run the old provider in parallel until cutover.
- Drive fallback by delivery receipts, not a timer: wait for DELIVERED, revoke, then send SMS only if the revoke succeeds.
For the wider category, including the carrier, registration, and billing questions that separate providers, see what an enterprise messaging service covers.