✓ Established business numbers
✓ Small-team provider changes
✓ Inbound route acceptance
— Emergency and life-safety systems
— Outbound sales automation
— Agency software resale
— Guaranteed uninterrupted migration
Confirm the provider event
Record the receiving provider’s actual completion notice or status for each number. Check the intended scope rather than assuming a completed batch means every number succeeded. Keep uncertain or rejected items visible and assigned to the relevant provider conversation.
Check the caller journey
Use the agreed authorised acceptance process to observe the required inbound route, answering destination and fallback. Calls originating inside the same platform may not establish reachability from all external networks. Avoid promising universal reachability from one successful call.
Do not rush cancellation
Before retiring old services, confirm dependencies, final billing and what remains outside the order. Keep specialist equipment and safety-critical services under their separate review. A successful application login is not a cancellation prerequisite.
A fictional partial acceptance
Two numbers show completed status but a third is still pending. The team accepts the verified routes individually and leaves the remaining line active with its old provider. It does not collapse the project into a single green status that conceals the unresolved number.
Use a release decision with exceptions
Prepare a short acceptance summary with three parts: verified numbers and routes, unresolved items with owners, and services that must remain active. Ask the authorised decision owner to compare it with the original scope before making any cancellation decision. Include the actual observation time and the provider's completion reference, because a later issue may need that context. Do not overwrite an earlier failed observation when a subsequent check passes; preserve the sequence so the team can explain the change. If one secondary line remains uncertain, decide explicitly whether the rest can operate safely as a partial acceptance. A project-wide green label should never conceal that exception. The summary is an operating decision aid, not a warranty of future availability or universal carrier reachability.
The evidence behind this buying guidance
This guide draws on CloudTalk porting requests, CloudTalk inbound diagnosis, CloudTalk external reachability. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.
Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- CloudTalk porting requests — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28
- CloudTalk inbound diagnosis — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28
- CloudTalk external reachability — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28