Join the waitlist

Let us know how we should get in touch with you.

Thank you for your interest! We’re excited to show you what we’re building very soon.

Close
Oops! Something went wrong while submitting the form.

Bringing Your Existing Sales Phone Numbers: Verify Porting Before Switching

Unify Team
·
Updated on: November 13, 2026

Before switching sales dialers, verify that the destination provider supports porting the exact existing numbers your business intends to keep. Confirm current control, number eligibility, authorization requirements, the transfer sequence, and continuity for outbound calls and callbacks. Being able to select a new number in a dialer is not evidence that an existing number can be ported into it.

Unify’s current setup documentation describes adding available numbers, assigning them to reps, and configuring callback forwarding. It does not establish support for porting existing numbers into Unify. Treat port-in capability, eligibility, and timing as questions requiring explicit confirmation for your proposed migration.

Separate porting from assigning and forwarding

Porting changes the service provider responsible for an existing number under the supported transfer process. Assigning a number selects which user can use a number already available within a workspace. Forwarding determines where an incoming call is routed. These operations can be related, but one does not prove support for another.

Unify’s dialer setup guide explains assigning available numbers and setting a callback number. Review those documented capabilities on their own terms. A callback destination can receive forwarded calls without the source number having been ported into the platform.

The dialer overview describes calling from person records or tasks and tracking conversations. It provides workflow context, but it does not replace number-specific portability evidence.

Write the intended outcome in plain language: which existing number must remain reachable, which service should originate calls from it, and where callbacks should arrive. That prevents a demonstration of a new assigned number from being accepted as proof that the existing number can move.

Establish control of each existing number

Inventory the numbers in scope using your approved internal records. Identify the current provider, the business account responsible for the service, the authorized administrator, and the evidence available to support a transfer request. Keep the inventory access-controlled because it may contain account and operational details.

Do not assume the salesperson using a number is the person authorized to transfer it. Operational assignment and provider account control are different facts. Confirm the authorized business owner before initiating any request.

Record which workflows depend on each number. Include outbound identity, callbacks, published contact routes, and any other actual use relevant to your business. Do not expand the migration to unrelated numbers merely because they appear in the same account.

If ownership or control is uncertain, resolve that uncertainty before planning a cutover. A number that appears in a dialer interface is not sufficient evidence that your organization can port it or that the destination will accept it.

Ask the destination for explicit eligibility

Request confirmation for the exact number type, country, current provider, intended plan, and business use. Ask which documentation the destination needs and which party initiates the supported request. Preserve the response and its scope in the migration record.

Keep eligibility separate from availability of newly issued numbers. Unify’s international calling guide documents country-specific access and availability requirements. Those requirements concern the documented calling service; they are not a portability guarantee for every existing number in those markets.

Review dialer pricing for published number allowances and usage costs. Ask separately about any terms that apply to the proposed transfer. Do not infer a transfer fee, supported timeline, or waived cost from pricing for newly added numbers.

When comparing providers, record an unverified answer as unverified. “We support business calling” is not an answer to “Can this existing number be ported into this account under these conditions?” The narrower question is the one that protects the migration decision.

Confirm the authorization process

Ask the current and destination providers which approved documents, account details, and authorized signatures are required. Use their current process rather than a generic checklist copied from another carrier or market. Do not share account credentials in an ordinary project worksheet.

Identify who can submit the request, who can approve changes, and who can receive status updates. If another organization controls the current service, obtain the appropriate documented authority before proceeding.

Record the dependency between authorization and scheduling. A proposed transfer date should not be treated as confirmed while required information remains unresolved. Keep the provider’s actual status distinct from your internal target date.

Unify’s members and roles documentation describes workspace administration. That role model can help assign internal responsibilities, but workspace administrator status alone does not establish authority over a number held by another provider.

Build a continuity plan before submitting the request

List the functions that must continue during the transition. Separate outbound calling, incoming callbacks, rep assignment, call logging, and any connected CRM activity. Determine which functions have a supported fallback and which depend on the transfer completing.

Do not release or cancel the existing number before the providers confirm the supported transfer sequence. A migration plan should preserve current service until the approved process says otherwise. Avoid promises of zero downtime unless the providers explicitly support that claim for the scoped operation.

The broader sales engagement migration guide can help coordinate related workflow changes. Keep phone-number portability as its own acceptance item so that an otherwise complete platform rollout does not conceal an unresolved number transfer.

Record how the team will handle callbacks while the status is uncertain. The callback ownership guide addresses internal responsibility after numbers are assigned. Use it for that handoff, while keeping provider-level porting eligibility separate.

Inspect the destination configuration

Once the supported transfer or alternative arrangement is available for an approved check, inspect the destination’s actual number assignment. Confirm the rep, the selected calling number, and the callback destination. Do not rely only on a migration ticket marked complete.

Use the making calls documentation to understand how calls are placed and logged in Unify. Test only authorized destinations and permitted workflows. Check the calling route your team will actually use, including the relevant task or person-record entry point.

Review call recording settings separately. A transferred number does not prove that recording behavior, regional configuration, or saved artifacts meet your requirements. Those controls should be reviewed by the appropriate owners before the team starts calling.

If call activity must reach the CRM, inspect the call sync documentation. Logging a call, syncing activity, and making a number reachable are separate outcomes. Accept each required outcome on its own evidence.

Verify outbound identity and callbacks

Plan an approved receiving-end check. Compare the number selected by the rep with the number observed by the authorized receiving party. Record the route and the observed presentation without assuming that a caller-name display or network label will be identical everywhere.

For callbacks, inspect where a return call actually arrives and who is responsible for responding. A forwarding number displayed in settings is configuration evidence; an approved callback observation establishes behavior for the tested route. Preserve both without overstating the scope.

Do not use a successful outbound call as proof that inbound callbacks work, or the reverse. Keep each direction in the acceptance record. If the team uses more than one approved route, identify which routes were checked and which remain unverified.

The country-support evaluation guide helps frame market-specific questions. A successful check in one market does not establish the same behavior in another, especially where access requirements or product availability differ.

Use a number-portability worksheet

Create one entry per number and destination arrangement. The blank worksheet below is designed for evidence collection; it contains no assumed transfer outcome or promised completion time.

Review field What to establish Observed evidence or value
Existing number Approved internal identifier and current service context
Current control Provider account owner and authorized administrator
Destination eligibility Explicit port-in support for the scoped number and plan
Authorization requirements Provider-approved documents and responsible owner
Transfer sequence Supported steps and dependency between providers
Continuity plan Outbound, callback, and operational fallback decisions
Destination assignment Intended rep and actual configured number
Receiving-end check Authorized route and observed outbound presentation
Callback check Observed destination and accountable recipient
Unresolved condition Missing confirmation, owner, and release dependency
Acceptance decision Approved scope and conditions for ending old service

Store sensitive provider-account evidence in an approved controlled location and reference it from the worksheet. Do not place secrets or authorization documents in a broadly shared checklist.

Leave result fields blank until inspected. A provider’s eligibility statement can support planning, but it is not an observed successful transfer. Keep capability confirmation and operational acceptance as separate evidence types.

Handle delays and rejected requests explicitly

Ask the providers how status and rejection reasons are communicated. Establish who will correct missing or inconsistent information and how the team will confirm that a revised request was accepted. Do not invent a standard transfer duration or promise that resubmission resolves every issue.

Preserve the original request reference and the provider’s explanation. A corrected request should remain traceable to the same intended number and authorized account. Avoid starting parallel, conflicting requests merely because the first status is unclear.

Keep the old-service decision tied to verified status. If the request is delayed or rejected, review the continuity plan with the responsible owner rather than allowing a previously scheduled cancellation to proceed automatically.

If the destination cannot support the port, evaluate alternatives explicitly. A newly assigned number or forwarding arrangement may satisfy some requirements and fail others. Document the tradeoff instead of calling the alternative a completed port.

Measure migration readiness by number and function

Define the population as the approved inventory of numbers in a saved migration snapshot. For readiness, the numerator is numbers with all required eligibility, authorization, continuity, and acceptance evidence. The denominator is every number in that approved scope.

Report ineligible, unverified, pending, and accepted numbers separately. Preserve function-level gaps, such as an accepted outbound route with an unresolved callback requirement. A single readiness label should not hide a missing critical function.

If the scope contains no numbers, report not applicable rather than a perfect readiness rate. State the snapshot time so that later additions do not silently change the denominator. These definitions are proposed planning methods, not observed migration performance.

Use the measure to explain remaining dependencies, not to pressure the team into declaring an uncertain transfer complete. A smaller accepted scope is more useful than a broad migration claim that cannot be supported.

Close the migration with an accountable handoff

Before ending the prior arrangement, have the authorized owner review provider confirmation and the required observed checks. Preserve the evidence showing the current number route, assignment, callback destination, and remaining limitations.

Update the team’s operating instructions so reps know which number to use and where callbacks arrive. Review the dialer product overview alongside the operational documentation, but use the actual account configuration as the basis for the handoff.

Keep provider-level portability separate from future internal reassignment. Changing which rep owns a number after migration is another operational decision and should follow the supported workspace controls. A successful initial transfer does not remove the need to review ownership when roles change.

The purchase decision should state precisely what is supported: the eligible numbers, the verified arrangement, the required manual steps, and any unresolved restrictions. That is more useful than a general claim that your team can bring its phone numbers without qualification.

Reconcile the number inventory with the proposed scope

Before accepting a transfer plan, compare the approved inventory with the numbers named in the provider’s response. Confirm that each response applies to the intended number and account. A general eligibility answer can leave individual numbers unresolved, particularly when the inventory includes different service arrangements.

Keep numbers excluded from the migration visible with an approved reason. Do not allow an omitted number to disappear from the continuity discussion if customers or prospects still use it. Assign an owner for the continuing arrangement and make sure the migration team understands which service remains responsible.

If the inventory changes during planning, revise the scope explicitly. A new number added to the project should receive its own eligibility and authorization review. Do not treat it as accepted merely because the provider approved the earlier inventory.

Define evidence for each cutover decision

Separate permission to submit a transfer request, permission to change the operating configuration, and permission to end the prior service. These decisions occur at different points and depend on different evidence. The authorized owner should know which decision is being requested rather than receiving a broad migration-complete notification.

For submission, verify control and required authorization. For configuration, verify the supported destination arrangement and the team’s readiness to use it. For ending prior service, verify the provider’s confirmed sequence and the required operational checks. Keep unresolved dependencies attached to the relevant decision.

Avoid relying on elapsed time as proof of completion. A target date, an estimated processing period, and an actual provider confirmation are different facts. If the observed status does not match the plan, preserve current service under the approved continuity process while the responsible parties resolve the discrepancy.

Prepare the people who handle the first callbacks

The operational handoff should explain who receives return calls, how that person identifies the relevant conversation, and how activity is recorded. Number portability does not automatically transfer the team’s knowledge of existing conversations. Make the approved context available through the normal record and task workflow.

Review the destination’s supported callback behavior with the people responsible for responding. If the arrangement routes calls to another phone, confirm that the assigned recipient understands that responsibility and the process for changing it later. Do not assume the migration administrator will remain the callback owner.

After acceptance, retain a concise record of the supported arrangement and the unresolved limits. Future administrators should be able to distinguish a ported number from a newly assigned or forwarded number without reconstructing the original project. That distinction will matter when the team changes providers or responsibilities again.

Retain the provider confirmation and accepted routing evidence after the project closes. A future administrator should be able to determine who controls the number, which provider currently serves it, and what process is required for another move. Keep that information distinct from the rep assignment, which may change more often. If an acceptance condition remains unresolved, preserve its owner and business impact rather than archiving it with completed project tasks. The record should describe the current arrangement accurately.

Frequently asked questions

Does Unify’s number selector prove existing numbers can be ported in?

No. The setup documentation describes selecting available numbers and assigning them to users. It does not establish port-in support for existing numbers. Confirm eligibility and the supported process directly for the proposed migration.

Is callback forwarding the same as porting a number?

No. Forwarding routes incoming calls to another destination. Porting changes the provider responsible for an existing number through a supported transfer process. Verify the arrangement your business actually needs.

When should the old number service be cancelled?

Follow the providers’ confirmed transfer sequence and your authorized continuity plan. Do not release or cancel the existing number before the supported process and required acceptance evidence permit that step.

What should be checked after the transfer?

Inspect assignment, authorized receiving-end presentation, callbacks, and any required logging, recording, or CRM sync behavior. Keep untested routes and unresolved functions visible rather than treating one successful call as complete acceptance.