Migrating from a legacy PBX to a cloud phone system can improve reliability, mobility, administration, reporting, and business continuity. However, a successful migration requires much more than selecting a cloud provider, ordering phones, and transferring telephone numbers.
A business phone system connects employees, customers, emergency services, analog devices, contact centers, applications, and multiple business locations. Every one of those connections must be identified, designed, configured, and tested before the organization moves its production telephone numbers.
The safest migration sequence is to document the existing environment, design the replacement, prepare the network, build the cloud system, and test it using temporary telephone numbers. The production port request should be submitted only after the new system is ready and the organization can accept a scheduled port date.
This guide explains the complete PBX-to-cloud migration process.
What Is a PBX-to-Cloud Migration?
A PBX-to-cloud migration replaces some or all of an organization’s locally installed phone-system infrastructure with a cloud communications platform.
The existing system might be:
- Avaya IP Office or Communication Manager
- Mitel MiVoice Business or MiVoice Connect
- ShoreTel
- Cisco Unified Communications Manager
- NEC
- Toshiba
- Panasonic
- Another discontinued or aging PBX
The replacement is commonly called Unified Communications as a Service, or UCaaS. Depending on the provider and licenses selected, the new platform may include:
- Business calling
- Auto attendants
- Interactive voice response
- Voicemail
- Desktop and mobile applications
- Video meetings
- Team messaging
- Business SMS
- Call recording
- Analytics and reporting
- Contact center capabilities
- Microsoft Teams integration
- Microsoft 365 or Google Workspace integration
- CRM and business-application integrations
Moving the service to the cloud changes where the telephone system operates. It does not eliminate the need for careful design, reliable networks, emergency-calling compliance, or experienced support.
Why Are Organizations Replacing Legacy PBX Systems?
Many organizations begin planning a migration because their existing PBX has reached the end of its practical life.
Common reasons include:
- The manufacturer has discontinued the platform or reduced support
- Replacement parts are becoming scarce
- The system depends on aging servers, gateways, or voicemail appliances
- Software upgrades have become difficult or expensive
- Remote and hybrid employees need better communications tools
- The organization wants centralized administration across multiple locations
- Current reporting and call analytics are inadequate
- The system does not integrate well with Microsoft Teams or other applications
- The organization needs improved disaster recovery
- Separate voice, video, messaging, and contact center systems have become difficult to manage
- Existing carrier services are expensive or inflexible
A cloud migration can address these concerns, but only if the replacement system is designed around the organization’s operational requirements.
The Correct PBX-to-Cloud Migration Sequence
A well-managed migration generally follows this order:
- Inventory the existing PBX and carrier services
- Document current call flows and business requirements
- Identify users, licenses, phones, and specialty devices
- Evaluate UCaaS and contact center requirements
- Assess the network and internet connectivity
- Design emergency calling and business continuity
- Select the provider and implementation partner
- Gather and validate porting records
- Build the cloud phone system
- Configure temporary telephone numbers
- Test the system before porting
- Train administrators and key users
- Submit the port request
- Complete final pre-port testing
- Port the production telephone numbers
- Validate the system after porting
- Provide post-cutover support
- Decommission the old PBX and carrier services
Porting documentation should be collected early because carrier records can take time to correct. The actual port request should normally wait until the cloud system has been built and tested.
Step 1: Inventory the Existing PBX
Begin by documenting the current environment. An extension list or carrier invoice rarely provides a complete inventory.
Users and extensions
Document every:
- Employee extension
- Common-area phone
- Conference-room phone
- Reception phone
- Shared workspace
- Security desk
- Classroom phone
- Guest-room phone
- Courtesy phone
- Lobby phone
- Elevator phone
- Emergency phone
- Voicemail-only mailbox
- Virtual extension
- Announcement-only extension
Identify which employees need a physical phone, desktop application, mobile application, voicemail, business SMS, call recording, or contact center access.
This prevents the organization from assigning the same license to every person when different users may have different requirements.
Telephone numbers
Create an inventory of:
- Direct inward dial numbers
- Main published numbers
- Departmental numbers
- Toll-free numbers
- Fax numbers
- Alarm lines
- Elevator numbers
- Modem lines
- Emergency numbers
- Numbers forwarded to outside services
- Numbers that appear inactive but remain on carrier invoices
For each number, document:
- Current carrier
- Billing account number
- Billing telephone number
- Service address
- Current destination
- Published business purpose
- Whether the number must be ported
- Whether the number can be disconnected
- Whether temporary forwarding is available
Compare carrier records with the PBX programming. A number may appear on an invoice without an obvious destination, while an active PBX route may use a number that employees no longer recognize.
Phones and endpoints
Inventory:
- Desk-phone manufacturer and model
- Hardware revision
- Firmware version
- Conference-room devices
- Wireless handsets
- Reception consoles
- Headsets
- Analog telephone adapters
- Paging interfaces
- Door phones
- Emergency devices
Existing phones may sometimes be reused, but compatibility depends on the model, revision, firmware, provider, and provisioning method. A phone that can register with the new service may not support every cloud feature.
Step 2: Document Current Call Flows
The implementation team must understand how calls are handled today.
Document call routing during:
- Normal business hours
- Lunch schedules
- Evenings
- Weekends
- Holidays
- Weather closures
- Emergencies
- Staff meetings
- Seasonal operations
- High-volume events
Record every:
- Auto attendant
- Menu option
- Call queue
- Hunt group
- Ring group
- Overflow destination
- Recorded announcement
- Voicemail box
- Operator destination
- After-hours route
- Emergency route
- External answering service
Do not assume the new platform should reproduce every old programming decision. Legacy call flows often contain outdated departments, temporary routing, abandoned extensions, and workarounds created to accommodate limitations of the former PBX.
Use the migration to confirm how the organization wants calls handled now.
Step 3: Inventory Analog and Specialty Devices
Analog devices are among the most frequently overlooked parts of a cloud migration.
Inventory equipment such as:
- Fax machines
- Fire alarm panels
- Security alarm panels
- Elevator phones
- Gate and door-entry systems
- Overhead paging systems
- Modems
- Emergency call boxes
- Pool phones
- Courtesy phones
- Credit-card terminals
- Postage machines
- Building automation equipment
- Hotel guest-room phones
- Wireless or cordless systems
Each device should have a documented telephone number, location, connection type, purpose, and replacement strategy.
Some devices can connect through an analog telephone adapter. Others may require an analog gateway, carrier-provided line, cellular service, or specialized replacement.
Faxing, alarm transmission, modem communication, and older data devices do not always perform reliably over a standard cloud voice connection. Test every specialty device independently.
Step 4: Define the Future Communications Requirements
Interview representatives from IT, administration, customer service, public safety, facilities, finance, human resources, and other affected departments.
Questions should include:
- Which employees need physical phones?
- Which employees need desktop and mobile applications?
- Should users keep their current extension numbers?
- Does the organization need business SMS?
- Which calls must be recorded?
- How long must recordings be retained?
- Does the organization need advanced analytics?
- Will users work in Microsoft Teams?
- Are CRM, help-desk, property-management, or other integrations required?
- Does reception need user-presence information?
- Are shared lines, paging groups, or monitored extensions required?
- What should happen during an internet or power outage?
- Are seasonal, emergency, or holiday schedules needed?
- Does the organization need a formal contact center?
The answers determine the platform, design, licensing, devices, and implementation scope.
Step 5: Decide Whether UCaaS or Contact Center Is Required
A cloud business phone system and a contact center serve different requirements.
UCaaS commonly provides:
- Business calling
- Voicemail
- Auto attendants
- Basic call queues
- Desktop and mobile applications
- Meetings
- Messaging
- Business SMS
- Basic recording and analytics
A contact center may add:
- Skills-based routing
- Advanced interactive voice response
- Customer callback
- Supervisor monitoring
- Quality management
- Screen recording
- Agent evaluations
- Workforce management
- Service-level reporting
- Digital channels
- Customer surveys
- Advanced artificial intelligence tools
A department with a basic call queue may not need contact center licensing. An operation that manages formal agents, supervisors, service levels, quality reviews, or complex customer routing probably does.
Identify exactly which employees need UCaaS licenses and which employees need contact center licenses.
Step 6: Create the Licensing and Device Design
Create a licensing matrix that separates:
- Full UCaaS users
- Phone-only users
- Desktop-application users
- Mobile-application users
- Voicemail-only users
- Common-area phones
- Conference-room phones
- Contact center agents
- Contact center supervisors
- Reception consoles
- Analog ports
- Fax services
- Recorded users
- Additional telephone numbers
- Toll-free numbers
- SMS-enabled numbers
Also identify the equipment required:
- Desk phones
- Conference-room systems
- Headsets
- Analog adapters
- Analog gateways
- Paging interfaces
- Session border controllers
- Firewalls
- Network switches
- Wireless access points
- Battery backup
Licensing should be based on the completed inventory rather than total employee headcount.
Step 7: Evaluate the Network
A cloud phone system depends on the organization’s network and internet connectivity.
Internet connectivity
Evaluate:
- Available bandwidth
- Upload and download capacity
- Latency
- Packet loss
- Jitter
- Historical service reliability
- Firewall compatibility
- Secondary internet options
- Automatic failover behavior
Voice calls use relatively little bandwidth, but call quality depends on consistent network performance. A fast internet circuit can still produce poor voice quality when it experiences packet loss, congestion, or unstable latency.
Local network infrastructure
Review:
- Network switches
- Power over Ethernet capacity
- Virtual LAN configuration
- Quality of service
- Cabling
- Wireless coverage
- DHCP
- DNS
- Firewall rules
- Firmware versions
- Switch-port availability
- Uninterruptible power supplies
Replacing the PBX will not correct poor cabling, overloaded switches, weak Wi-Fi, or an unreliable internet connection.
Remote users
Test the platform from:
- Home networks
- Mobile networks
- VPN connections
- Branch offices
- Temporary work locations
- Public Wi-Fi where permitted
Desktop and mobile applications improve flexibility, but their performance depends on the user’s device and network connection.
Step 8: Design Business Continuity
Cloud communications reduce dependence on a PBX installed in one building, but local network and internet failures can still affect service.
The continuity plan should address:
- Internet circuit failure
- Local power failure
- Firewall or switch failure
- Cloud-provider interruption
- Building evacuation
- Regional emergency
- Mobile-network interruption
- Failure of an analog gateway
- Loss of access to a primary office
- Number-porting delays
Possible continuity measures include:
- Secondary internet connections
- Cellular or 5G failover
- Battery backup
- Mobile applications
- Automatic call forwarding
- Alternate answering locations
- Redundant network equipment
- Documented emergency-routing procedures
Test failover before declaring the migration complete.
Step 9: Plan Emergency Calling
Emergency calling requires more than allowing users to dial 911.
The design must address:
- Accurate dispatchable locations
- Buildings
- Floors
- Suites
- Wings
- Room numbers
- Common-area phones
- Remote employees
- Mobile applications
- On-site security notifications
- Front-desk notifications
- Phone movement between locations
- Emergency-call testing
- Applicable legal requirements
Organizations with multiple buildings or large facilities should create an emergency-location plan before users and phones are configured.
Test emergency calling through an approved procedure. Do not place an unannounced test call to 911.
Step 10: Select the Provider and Implementation Partner
Cloud communications platforms differ in licensing, administration, integrations, reporting, device support, contact center features, analog options, and customer support.
Evaluate providers based on actual requirements rather than advertised per-user pricing.
Consider:
- Platform reliability
- Calling and routing capabilities
- Contact center functionality
- Microsoft Teams integration
- Supported phones and analog devices
- Reporting and analytics
- Recording retention
- Security
- Compliance requirements
- Number-porting experience
- Administrative controls
- Identity-management integration
- Implementation services
- Post-installation support
- Contract term
- Renewal conditions
- Multilocation capabilities
An experienced implementation partner should understand the legacy PBX as well as the replacement platform. Knowledge of Mitel, Avaya, ShoreTel, Cisco, and other established systems helps the implementation team recognize call-routing behavior and dependencies that might otherwise be missed.
Step 11: Gather and Validate Porting Records
Begin gathering porting information early, but do not submit the port request yet.
Required information may include:
- Current carrier invoices
- Customer service records
- Billing telephone numbers
- Account numbers
- Service addresses
- Authorized signer information
- Letters of authorization
- Porting PINs
- Recent carrier changes
- Lists of telephone numbers to port
The information submitted to the new carrier must match the losing carrier’s records. Differences in company names, addresses, account numbers, or authorization can cause rejections.
Use this preparation period to:
- Correct carrier records
- Identify numbers on separate accounts
- Separate numbers that should not be ported
- Confirm service addresses
- Remove account freezes when appropriate
- Identify dependencies on the billing telephone number
- Decide whether the migration will use one port or several phases
Do not cancel the existing telephone service.
Step 12: Build the Cloud Phone System
The implementation team should build the cloud platform before the production port request is submitted.
Configure:
- Users and extensions
- Sites
- Emergency locations
- Temporary telephone numbers
- Auto attendants
- Call queues
- Ring groups
- Business-hour schedules
- Holiday schedules
- Voicemail boxes
- Call forwarding
- Caller ID settings
- Paging groups
- Shared lines
- Reception functions
- Call recording
- Contact center routing
- Microsoft 365 or identity integration
- Phones
- Desktop applications
- Mobile applications
- Administrative permissions
Temporary numbers allow the implementation team to test the new system while the production numbers remain active on the existing PBX.
Step 13: Test Before Submitting the Port
Test the cloud platform thoroughly before committing to a production port date.
Use temporary numbers to test:
- Internal calling
- Incoming calls
- Outgoing calls
- Auto attendant options
- Call queues
- Ring groups
- Voicemail
- Voicemail-to-email
- Transfers
- Call forwarding
- Paging
- Desktop applications
- Mobile applications
- Microsoft Teams integration
- CRM integration
- Call recording
- Reports
- Contact center routing
- Internet failover
- Emergency locations
- Faxing and analog devices where possible
Create written test cases with an expected result and assigned reviewer.
Temporary numbers cannot fully test the final production-number routing or production outbound caller ID. Those items must be verified immediately after the port. Nearly every other feature should be operational before the organization commits to the port date.
Step 14: Train Administrators and Key Users
Training should begin before the production numbers move.
End-user training
Users may need instruction on:
- Making and receiving calls
- Holding and transferring calls
- Accessing voicemail
- Using the desktop application
- Using the mobile application
- Managing presence
- Forwarding calls
- Joining meetings
- Sending business text messages
- Using headsets
- Reporting problems
Reception and supervisor training
Receptionists and supervisors may need additional instruction on:
- Monitoring user status
- Managing multiple calls
- Transferring calls to voicemail
- Using shared lines
- Monitoring queues
- Reviewing reports
- Listening to recordings
- Changing schedules or announcements
Administrator training
Administrators should understand how to:
- Add and disable users
- Assign licenses
- Update telephone numbers
- Change call routing
- Manage emergency locations
- Reset voicemail access
- Replace phones
- Review call quality
- Run reports
- Open support cases
Administrators and selected department representatives should participate in pre-port acceptance testing.
Step 15: Submit the Port Request
Submit the production port request only after:
- The cloud platform has been built
- Temporary-number testing is complete
- Phones and applications are working
- Call flows have been approved
- Network preparation is complete
- Administrators have received training
- Analog-device plans are confirmed
- The organization can accept a scheduled port date
The new carrier will review the request and seek approval from the losing carrier. Once approved, the carrier normally assigns a firm order commitment date.
Some providers allow the customer to select a requested port date. Others assign the first available date. Understand the provider’s process before submission because changing an approved port date may be difficult.
Continue operating the existing PBX while the port request is pending.
Step 16: Complete Final Pre-Port Testing
Before the scheduled port date, confirm:
- All users have correct licenses
- Phones are provisioned
- Desktop and mobile applications work
- Auto attendants have approved recordings
- Business and holiday schedules are correct
- Queue members are accurate
- Voicemail boxes are configured
- Emergency locations are correct
- Analog devices are ready
- Internet failover works
- Support contacts are available
- Temporary routing remains available
- The existing PBX remains operational
- The organization has communicated the cutover schedule
Freeze nonessential configuration changes shortly before the port so the tested system remains consistent.
Step 17: Execute the Number Port and Cutover
The cutover plan should identify:
- Port date and time
- Participants
- Responsibilities
- Provider escalation contacts
- Carrier escalation contacts
- Testing order
- Communication procedures
- Backup routing
- Decision points
- Response procedures for unresolved problems
After the numbers move, verify:
- The main numbers reach the correct destinations.
- Direct numbers reach the correct users.
- Toll-free numbers route correctly.
- Outgoing caller ID displays correctly.
- Auto attendants and schedules work.
- Queues and voicemail operate correctly.
- Transfers and forwarding work.
- Emergency calling uses the correct location.
- Fax and analog services function.
- Call recording and reporting operate correctly.
- Mobile and desktop applications work with the production numbers.
- Backup routing remains available.
Keep the existing PBX operational until the new platform passes acceptance testing whenever practical.
Step 18: Provide Post-Cutover Support
The migration does not end when the numbers port.
The first days after cutover often identify adjustments such as:
- Ring times that need modification
- Users who require different permissions
- Queue membership changes
- Incorrect after-hours routing
- Missing voicemail notifications
- Caller ID corrections
- Training gaps
- Headset or phone issues
- Reporting requirements
- Previously undocumented numbers or devices
Schedule follow-up reviews after the first day, first week, and first month. Review user feedback, call quality, unanswered calls, queue performance, porting issues, and support cases.
Step 19: Decommission the Old PBX and Carrier Services
Do not immediately disconnect the old PBX or cancel every carrier service after the port.
First confirm:
- Every required number has moved
- No numbers remain on the former carrier unintentionally
- Fax, alarm, elevator, and analog services have working replacements
- The new system has passed acceptance testing
- Call records and voicemail data have been retained when required
- Hardware ownership and disposal requirements are understood
- Remaining carrier services have been identified
- Final carrier invoices can be reconciled
Retain system backups, configuration exports, telephone-number records, and call-flow documentation according to the organization’s policies.
Cancel obsolete services only after verifying that they are no longer required.
Common PBX-to-Cloud Migration Mistakes
Submitting the port request before the system is ready
A port date can arrive before phones, call flows, networks, or users are prepared. Build and test the new system before submitting the production port request.
Ordering licenses before completing discovery
Employee headcount does not equal the correct license count. Shared phones, voicemail-only users, contact center agents, analog devices, and mobile users may require different licenses.
Ignoring analog devices
Fax machines, alarms, elevators, paging systems, and door phones can delay a migration when discovered late.
Assuming the network is ready
Reliable web browsing does not prove that a network can consistently support real-time voice traffic.
Rebuilding outdated call flows
A cloud migration should not automatically reproduce call routing that no longer matches the organization’s operations.
Canceling existing service too early
Do not cancel existing telephone service before porting and acceptance testing are complete.
Failing to review carrier accounts
A large organization may have numbers spread across multiple accounts, carriers, service addresses, and billing telephone numbers.
Providing only generic training
Receptionists, administrators, supervisors, and contact center agents require role-specific training.
Treating deployment and ongoing support as the same service
Implementation may not include long-term administration, carrier coordination, user changes, analytics assistance, or troubleshooting. Define post-cutover support before signing the agreement.
How Long Does a PBX-to-Cloud Migration Take?
A small office with straightforward call routing may migrate in several weeks. A multilocation organization with complex call flows, analog devices, contact center requirements, and numerous telephone numbers may require several months.
The schedule depends on:
- Number of users
- Number of locations
- Number-porting complexity
- Procurement requirements
- Network upgrades
- Device availability
- Analog-device requirements
- Contact center configuration
- Integrations
- Training
- Internal approval processes
Schools and universities often schedule cutovers during summer or another low-activity period. Government organizations may require additional time for procurement, security review, emergency-calling design, and department coordination. Hotels may need phased installation to protect front-desk and guest services.
How Much Does a Cloud Phone System Cost?
Cloud phone-system pricing may include:
- Monthly user licenses
- Contact center licenses
- Telephone numbers
- Toll-free services
- Usage charges
- Phones
- Headsets
- Analog adapters
- Analog gateways
- Network upgrades
- Implementation
- Training
- Number porting
- Ongoing support
- Recording storage
- Integrations
The lowest advertised per-user price rarely represents the complete project cost.
Compare the total cost over the proposed contract term. Confirm which implementation, equipment, carrier, training, and support services are included.
Should Every Organization Move Completely to the Cloud?
Not necessarily.
Some organizations benefit from a phased or hybrid migration. A legacy PBX may temporarily remain in service for certain buildings, analog devices, contact center functions, or specialized integrations while other users move to the cloud.
A phased migration may be appropriate when:
- Locations have different carrier or support contracts
- Network upgrades are incomplete
- Specialized devices need additional testing
- The organization cannot support one large cutover
- Certain departments have complex requirements
- Existing phones or infrastructure must remain in service temporarily
The correct strategy depends on business requirements, system condition, available resources, and risk tolerance.
Complete PBX-to-Cloud Migration Checklist
Before porting production numbers, confirm the project includes:
- Complete user and extension inventory
- Complete telephone-number inventory
- Documented call flows
- Analog and specialty-device inventory
- Network assessment
- Internet redundancy plan
- Emergency-calling design
- UCaaS and contact center requirements
- Licensing matrix
- Phone and device plan
- Microsoft Teams and application integrations
- Verified carrier records
- Cloud system configuration
- Temporary telephone numbers
- Written pre-port testing
- User and administrator training
- Approved port request
- Final pre-port review
- Written cutover plan
- Post-port validation
- Post-cutover support
- Existing-system decommissioning plan
Frequently Asked Questions
Should the new cloud phone system be built before submitting the port request?
Yes. Gather and validate carrier records early, but build and test the cloud system before submitting the production port request. Temporary numbers can be used to test phones, applications, auto attendants, queues, voicemail, integrations, and other functions.
Can we keep our existing telephone numbers?
Most existing business telephone numbers can be ported. Porting depends on number availability, accurate carrier records, account status, and authorization. Do not cancel the existing service before the port completes.
Can temporary numbers be used for testing?
Yes. Temporary numbers allow the organization to test the new system while production calls remain on the existing PBX. Production number routing and final outbound caller ID still require validation after the port.
Can we reuse our existing phones?
Sometimes. Compatibility depends on the phone model, hardware revision, firmware, ownership status, and cloud provider. Some features may operate differently after reprovisioning.
What happens if the internet connection fails?
Phones at the affected location may lose access unless the site has a secondary internet connection or cellular failover. Calls can often route automatically to mobile phones, another location, or an answering service.
Will fax machines and analog devices work?
Some devices work through analog adapters or gateways. Compatibility depends on the device and communications protocol. Fax machines, alarms, modems, elevators, and paging systems should be reviewed and tested separately.
Can cloud communications integrate with Microsoft Teams?
Yes. Available approaches include direct integration, operator connectivity, and a UCaaS platform that adds enterprise calling capabilities to Microsoft Teams. The proper design depends on routing, administration, contact center, reliability, and support requirements.
How far in advance should planning begin?
A straightforward office should begin several weeks before the desired cutover. Multilocation, government, education, hospitality, healthcare, and contact center projects should often begin several months in advance.
Can we migrate one location or department at a time?
Yes. A phased migration can accommodate different carrier contracts, budgets, construction schedules, network readiness, and operational requirements.
How long should the old PBX remain operational?
Whenever practical, keep it operational until the number port completes and the new system passes acceptance testing.
How HCWT Helps Organizations Migrate from PBX to Cloud Communications
High Country Workplace Technologies helps organizations evaluate, design, implement, and support cloud communications migrations.
HCWT has experience supporting and migrating Mitel, Avaya, ShoreTel, and other legacy telephone environments. This experience helps our team understand the existing programming, identify system dependencies, and translate established business processes into a modern cloud design.
HCWT migration services can include:
- Existing-system discovery
- User, telephone-number, and device inventories
- Call-flow documentation
- Cloud-provider evaluation
- UCaaS and contact center design
- Network and internet assessment
- Licensing and device design
- Number-porting preparation and coordination
- System programming
- Temporary-number testing
- Phone and analog-device planning
- User and administrator training
- Cutover assistance
- Post-installation support
HCWT works with commercial organizations, government agencies, school districts, universities, hotels, resorts, and multilocation businesses throughout the United States.
If your organization operates an aging or discontinued PBX, begin planning before a hardware failure, support expiration, or carrier change forces a rushed migration.
This article was authored by Jim Whitfield
Contact High Country Workplace Technologies to review your current telephone environment and develop a practical PBX-to-cloud migration plan.