Validate selected paths
Check the approved inbound, outbound, transfer, voicemail, schedule, application, and exception cases that apply to the configuration.
Phone-system migration guide
Treat the transition as an operating project.
A migration includes more than moving telephone numbers. Use this guide to inventory the current environment, define the future behavior, assign decisions, and prepare evidence for testing and cutover.
Six planning phases
Make the current state and future behavior visible before the transition.
The sequence is a discovery framework. It does not establish a delivery timeline or imply that every item is included.
- 01
Inventory the current system
List numbers, users, locations, devices, call paths, schedules, voicemail destinations, integrations, messaging, reporting, recording, emergency-calling requirements, and exceptions.
- 02
Collect account records
Gather current bills and carrier records without publishing account numbers or credentials. Confirm the responsible account owner and the records needed to evaluate each number.
- 03
Document the future call flow
Define business-hours, after-hours, holiday, no-answer, overflow, on-call, voicemail, and exception behavior before configuration.
- 04
Confirm site and user readiness
Review internet and local-network dependencies, power, user roles, approved devices or applications, installation needs, administration, and support paths.
- 05
Stage and validate
Confirm the selected configuration, prepare eligible devices and users, test approved call paths and workflows, and record unresolved exceptions before cutover.
- 06
Coordinate cutover and follow-up
Assign owners for number movement, installation, communication, contingency decisions, validation, issue reporting, and post-launch review.
Number ownership and porting
Preserve service until the movement plan is confirmed.
Inventory each business number, its current account context, its purpose, and its desired destination. Number-porting requirements and eligibility must be validated during planning.
Migration worksheet
Record facts, owners, acceptance criteria, and open questions.
This worksheet prepares a migration review. It does not authorize a port, order equipment, or establish a cutover date.
Current environment
- Locations, users, roles, and administrators
- Numbers, extensions, devices, applications, and services
- Current bills, carrier records, contracts, and account ownership
- Call flows, schedules, integrations, messaging, reporting, and recording
Future design
- Approved business-hours and exception routing
- User roles and proposed device/application needs
- Administration, support, and escalation ownership
- Optional messaging, reliability, reporting, recording, integration, or AI requirements
Readiness and staging
- Internet, local network, power, cabling, and installation dependencies
- Approved configuration and supported equipment still to confirm
- Test cases, expected results, and unresolved exceptions
- User and administrator preparation needs and responsible owners
Cutover and contingency
- Port, installation, communication, and decision owners
- Conditions required before proceeding
- Defined response if a dependency or validation step is not ready
- Post-launch checks, issue path, and follow-up owner
Call-flow documentation
Test the business behavior—not only whether a phone rings.
Use fictional data in early diagrams and remove customer identifiers before sharing examples. The implemented configuration must be validated against the approved business rules.
- Normal operationMain numbers, direct numbers, departments, queues where configured, schedules, voicemail, and outbound calling.
- ExceptionsNo answer, busy, overflow, after-hours, holiday, on-call, unavailable user, and known special-number behavior.
- Related workflowsMessaging, reporting, recording, integrations, and other selected services tested only where their exact configuration is approved.
- Responsible reviewA named customer decision-maker verifies that the documented route matches the intended business behavior.
Post-launch validation
Close the project with evidence and open issues—not assumptions.
Confirm user readiness
Verify that intended users and administrators know the approved tools, responsibilities, and support path. No training format or scope is assumed here.
Record exceptions
Document missing, unexpected, or disputed behavior and assign the next responsible action instead of representing the migration as complete by default.
Protect the evidence
Keep account records, credentials, real call data, and customer-specific diagrams in approved channels—not public forms, demonstrations, or website assets.
Next step
Bring the inventory and the intended call flow to discovery.
Heritage can then identify which porting, design, site, device, staging, training, contingency, testing, and commercial facts still require confirmation.