A client's business number can finish a port successfully, carry calls normally, and still have campaign texting fail without warning, because the number, the carrier-side messaging registration tied to it, and the sending path wired into GoHighLevel are three separate things that do not move together. The number itself can transfer in days or weeks depending on volume. The messaging registration that lets that number send SMS or MMS is tied to a brand and campaign record, not the digits, and HighLevel's own documentation says it does not automatically travel with a port (HighLevel: porting a US number to a location). Treat those pieces separately before a client's number moves, not after a workflow goes quiet.
Key takeaways
- The number, the A2P 10DLC messaging registration, and the GoHighLevel sending path are three separate things. A completed port only guarantees the first one.
- HighLevel documents full call access during a port but warns of a brief service impact during the port window; messaging capability is not guaranteed the same way.
- A2P 10DLC registration is tied to a brand and campaign, not the number, so a ported number usually needs new registration before it can send again.
- Run dated control texts to iPhone and Android test phones before and after the port so you have evidence of what changed, not a guess.
- Give the client a range from HighLevel's documentation, never a committed completion date.
What three things actually move separately when a client's number ports?
Start by naming the pieces instead of treating "the number" as one bundled asset.
The number. This is the ten-digit identifier the client has used on invoices, Google listings, and their website. HighLevel's porting guide requires a signed Letter of Authorization, a billing statement no older than 90 days showing the number and account holder, the number in E.164 format, the destination location, and the carrier account number and PIN for wireless numbers before it will submit a port request (HighLevel: porting a US number to a location). Getting this piece right moves the digits. It does not touch the next two.
The carrier-side messaging registration. A2P 10DLC is the registration system for application-to-person SMS and MMS sent over US local numbers, and Twilio's own documentation describes that registration as tied to a brand (the verified business identity) and a campaign (the declared message use case and opt-in process), which are then associated with specific numbers (Twilio: A2P 10DLC). The brand and campaign live in a platform's system of record, not on the number. HighLevel's porting article is direct about the result: "SMS/messaging capabilities don't automatically transfer" when a number ports, and a US local number needs A2P 10DLC completed again, while a toll-free number needs Toll-Free Verification completed again, before either can send (HighLevel: porting a US number to a location).
The sending path wired into GoHighLevel. A number landing in a GoHighLevel location is not the same as a working send path. The regular Send SMS workflow action uses the location's default SMS provider. A separate integration, such as a Custom Webhook pointed at an outside messaging tool, is a different configured path with its own setup. Beam's own documentation makes the same distinction for its iMessage channel inside GoHighLevel: iMessage and FaceTime Audio run outside the carrier A2P system entirely, while any SMS fallback on that workspace still follows the applicable carrier requirements (see the GoHighLevel iMessage integration guide). A ported number that lands in a location does not automatically know which of these paths it should use.
Which migration route fits a client who still needs to keep texting?
Agencies usually have three realistic options when a client's existing number needs to move. They carry different risk to texting continuity.
| Migration route | What the client keeps | What has to be re-approved | What breaks mid-switch |
|---|---|---|---|
| Port the number to the new provider | The number itself, on every listing, card, and contact record | A2P 10DLC brand and campaign (or Toll-Free Verification) on the new provider before SMS/MMS can send again (HighLevel: porting a US number to a location) | Texting during the port window; prior SMS conversation history does not move with the number, so export it first |
| Host messaging only, keep voice at the current carrier | The existing voice carrier relationship and the number's call routing, unchanged | A messaging-only hosting process: ownership verification, a signed Letter of Authorization, and carrier registration and testing, which Twilio documents at roughly one business day for a landline-type number and two to three days for toll-free (Twilio: hosted numbers) | Nothing on the voice side; the number cannot send or receive messages on the new platform until hosting finishes its carrier processing and testing stages |
| Stand up a new number and forward the old one | The old number as a working forwarding front door; the new number carries no history | A full new A2P 10DLC brand and campaign for the new number, built from nothing | Reply continuity: anyone who texts the old number does not land in the new campaign unless the agency builds a separate route for inbound replies |
Twilio's own framing of a full port versus a hosted number is a useful way to explain this choice to a client: a hosted arrangement "only registers the number for messaging to route in and out" of the new platform while voice stays where it is, whereas a full port moves both voice and messaging and creates a new number record on the receiving side that needs its own configuration (Twilio: hosted numbers). Neither Twilio nor HighLevel documents a route where messaging capability follows the number automatically. Pick the route based on how much the client depends on the number's existing call routing versus how much they depend on an unbroken texting thread, not on which option sounds simplest to sell.
How should an agency test a port before it starts?
The procedure below is a proposed acceptance test an agency can run around a client's port window. It is not a report of results from a specific client's account, and it will not tell you when a particular port finishes; HighLevel's documented range is two to four weeks for fewer than 50 numbers and six to eight weeks for larger or more complex ports, and only the losing carrier's processing determines where in that range a given port lands (HighLevel: in-app vs. international porting).
-
Inventory the number and who it is billed to.
Record the exact number in E.164 format, the current carrier, the account holder name on file, and who at the client's business can authorize a Letter of Authorization. HighLevel's porting requirements call for a billing statement no older than 90 days and, for wireless numbers, the account number and PIN, so confirm the client can actually produce those before you schedule anything (HighLevel: porting a US number to a location).
-
Capture the current messaging registration details.
Write down whether the number is already A2P 10DLC registered, under which brand and campaign, and on which platform that registration lives. If the client's current provider handled registration, note that the brand and campaign record will need to be recreated or re-associated on the receiving side, since Twilio's documentation ties that registration to the brand and campaign rather than the number (Twilio: A2P 10DLC).
-
Send dated control texts to iPhone and Android test phones and record what each shows.
Before the port starts, send a short, clearly labeled test message from the client's number to a test iPhone and a test Android phone your team controls. Record the date, the exact message, which app received it, whether it arrived as a blue bubble, RCS, or SMS fallback, and whether it was marked delivered. This is your baseline. Without it, a quiet failure after the port has nothing to compare against.
-
Freeze automated campaigns before the port window.
Pause workflows that send from the porting number, or route them to a holding state, before the scheduled port window begins. A workflow that fires mid-port can land on a number with no confirmed sending path, generate failures the client sees as missed follow-up, and make it harder to tell whether a failure came from the port itself or from an unrelated workflow bug.
-
Confirm the port completed on a live call and an inbound text.
Once the provider reports the port complete, place an actual call to the number from an outside line and have someone answer it. Separately, send an inbound text to the number from a phone you control and confirm it reaches the intended GoHighLevel conversation or inbox. A completed port notice is not the same as a working inbound path; test both channels yourself.
-
Re-check the messaging registration status before unfreezing anything.
Confirm the number shows an active, approved A2P 10DLC campaign association (or Toll-Free Verification, for toll-free numbers) on the new provider before you resume any automated sends. HighLevel's documentation is explicit that this step does not happen automatically during the port, so treat an unregistered number as expected, not as an error, and work it as its own task (HighLevel: porting a US number to a location).
-
Re-run the same control texts and compare them with the pre-port record.
Send the same style of message to the same test iPhone and Android phones, logged with a new date. Compare channel, delivery status, and timing against the baseline from step 3. Only resume client-facing automated campaigns once the control texts match what the number did before the port, or once any difference is explained and resolved rather than assumed away.
What should you tell the client about the quiet window?
Tell the client, before the port window opens, that calls are likely to keep working through the process because HighLevel documents full number access without planned downtime, but also to expect a brief service impact during the actual window and to hold onto their old account until the port is confirmed rather than canceling it early (HighLevel: porting a US number to a location). Separately, tell them that texting is not guaranteed to resume the moment the port completes, because the messaging registration is a second approval step that has to happen on the new side.
Give a range, not a date. HighLevel's own published timeline for a port is two to four weeks for fewer than 50 numbers and six to eight weeks for larger or more complex ports (HighLevel: in-app vs. international porting). Federal rules distinguish a simple port, generally the same service address and the same type of service, from a more complex transfer, and only a simple port carries the shortest completion expectations under FCC rules; a business number changing carrier type, or bundled with other service changes, does not automatically qualify as simple (FCC: porting, keeping your phone number when you change providers). None of that tells you when this specific client's port finishes. Set the expectation with the published range and the control-text procedure, and update the client when you actually have a result, not before.
Also tell the client what will not move with the number: prior SMS conversation history stays with the old provider unless someone exports it before the port, which is a separate action from the port itself.
Who owns the number after the port, and how do you document it?
A completed port changes who the number's carrier is. It does not, by itself, settle who controls the account that holds it, who is the authorized contact if a future transfer is needed, or who can request the next port if the agency relationship ends. Put those answers in writing at the time of the port, while the Letter of Authorization, billing statement, and account access are already assembled for the porting request, rather than trying to reconstruct them later. The same documentation discipline applies at the other end of the relationship: the existing guide on who owns the number and text history after an agency split covers what to settle in the client agreement so a later separation does not turn into a dispute over an asset nobody wrote down.
If the client's agency also routes calls on that number through RizzDial's GoHighLevel integration, confirm separately that voice routing and any call-handling workflows point at the new carrier path once the port finishes. A voice integration configured against the old provider's routing can keep working through a grace period and then fail quietly once that routing is retired, which is the same kind of silent gap this article describes for texting.
For the registration side specifically, the A2P 10DLC registration guide walks through brand and campaign setup from scratch, and the GoHighLevel texting guides hub collects the workflow and sender-identity articles an agency needs once the number is active again. Keep a copy of the pre-port and post-port control text results with the client file, alongside the registration confirmation, so the next person who touches this account is not left guessing what changed.
What questions do agencies ask about porting a number without losing texting?
Does porting the number pause the client's phone calls?
Not by design. HighLevel's porting documentation says there is full access to the number throughout the process because no downtime is built into a port, while also telling agencies to expect a brief service impact during the actual port window and to keep the old carrier account active until the port confirms.
Does the A2P 10DLC messaging registration travel with the number when it ports?
No. Twilio's A2P 10DLC documentation ties registration to the brand and campaign you create, not to the phone number itself, and HighLevel's porting article confirms that messaging capability does not automatically transfer. Expect to complete A2P 10DLC requirements again on the new provider before a ported US local number can send SMS or MMS.
Is hosting messaging on a number the same thing as porting it?
No. Twilio describes a hosted number as registering only the messaging route to a new platform while voice stays with the original carrier. A full port moves both voice and messaging and issues a new number record, which is why the two routes carry different risk and different approval steps.
Can you tell a client exactly which day texting will work again?
No. HighLevel publishes a range, not a date: two to four weeks for fewer than 50 numbers and six to eight weeks for larger or more complex ports. Give the client that range and the control-text procedure instead of a committed date, since the agency does not control the losing carrier's processing time.
What should you do before the next client port request?
Write down the three pieces, the number, the messaging registration, and the GoHighLevel sending path, as three separate line items on the port checklist instead of one task called "port the number." Run the control-text procedure around the actual window instead of assuming a completed port means a working campaign. For agencies evaluating Beam's own iMessage channel inside those same client workspaces, text our team to try it and bring the number and registration details above to the conversation.