A modern school communications environment may need to integrate thousands of classroom and administrative phones with paging systems, emergency calling, door entry systems, analog devices, Microsoft 365, mobile applications, call queues, voicemail, network infrastructure and public-safety procedures.
That makes writing an effective Request for Proposal (RFP) particularly important.
An RFP that simply asks vendors to provide "a cloud phone system for 2,500 users" may result in proposals that appear comparable but actually include very different capabilities, quantities and assumptions.
One vendor may price every telephone as a full user license. Another may use lower-cost classroom or common-area licensing. One may include paging integration while another assumes the district will handle it. One may include E911 location management while another prices only basic 911 calling.
Those differences may not become apparent until after a vendor has been selected.
High Country Workplace Technologies (HCWT) has worked with school districts and other public-sector organizations operating legacy Mitel, ShoreTel and Avaya telephone systems as well as modern cloud communications platforms.
Based on that experience, the most effective school district RFPs define not only how many phones are needed, but how the district actually communicates.
This guide identifies the major areas a school district should address when preparing an RFP to migrate from a legacy PBX to cloud communications.
Before evaluating cloud platforms, document what exists today.
For a legacy Mitel, ShoreTel, Avaya, Cisco or other PBX environment, the inventory should include:
Do not assume that the number of telephones equals the number of employees.
That distinction is particularly important in K-12 environments.
This may be one of the most important requirements in the entire RFP.
A traditional PBX may have 3,000 extensions without having 3,000 individual users requiring full unified communications licenses.
A classroom telephone might serve a room rather than a specific employee. A common-area phone may only need internal and emergency calling. A receptionist may need dozens of monitored extensions. An administrator may require a desk phone, desktop application and mobile application.
These are very different use cases.
Your RFP should therefore identify quantities separately for:
Full UC users – staff requiring calling, voicemail, desktop and mobile applications.
Classroom phones – devices associated primarily with classrooms.
Shared or common-area phones – break rooms, hallways, offices, workrooms and other shared spaces.
Operator/receptionist positions – users requiring extensive Busy Lamp Field (BLF), transfer and call-coverage capabilities.
Conference phones – shared meeting-room devices.
Special-purpose SIP devices – door stations, paging endpoints and similar equipment.
Analog devices – fax, paging interfaces, modems and specialty equipment.
This approach also exposes an important pricing question:
Does a classroom or common-area phone require the same license as a superintendent, principal or administrative employee?
Require every bidder to answer that question explicitly.
A sophisticated RFP should require classroom/common-area telephone licensing to appear as its own line item, rather than allowing it to disappear inside a generic per-user price. That is exactly the type of distinction a current school-district procurement is making. LCSD1 Phone System RFP Word doc…
Classroom communications can be surprisingly complex.
In some districts, the classroom telephone represents the classroom itself. In others, it also serves as the teacher's primary extension.
There may even be multiple staff members sharing one classroom telephone while requiring individual voicemail boxes.
Your RFP should explain:
One recent district RFP, for example, specifically requires vendors to explain how a classroom phone shared by two to four staff members, each with individual voicemail, would operate. LCSD1 Phone System RFP Word doc…
That is far more useful than simply specifying "2,000 users."
Replacing thousands of telephones can represent a substantial portion of a migration budget.
Before automatically purchasing new phones, determine whether existing endpoints can be reused.
Some newer Mitel and Avaya phones may be capable of being converted or reprovisioned for certain cloud platforms.
However, compatibility should never be assumed based solely on the manufacturer's name or phone model.
Evaluate:
HCWT recommends testing representative phones before including phone reuse as a guaranteed migration assumption.
The RFP should ask bidders to identify:
Which existing phones can be reused?
Which require firmware changes?
Which have functional limitations?
Which should be replaced?
What is the cost difference between reuse and replacement?
Do not accept a proposal containing only:
Cloud communications — 2,500 users — $XX per user/month.
Require a complete Bill of Materials (BOM).
Every separately licensed component should be identified.
That includes:
Also require vendors to disclose assumptions whenever the RFP does not provide an exact quantity.
This prevents a low initial bid from becoming a substantially different price after discovery.
For many school districts, paging is one of the most difficult parts of a cloud phone migration.
Do not reduce this requirement to:
"System must support paging."
Schools may have decades of paging infrastructure installed across different generations of buildings.
A single district can contain:
The RFP should require the bidder to explain exactly how each paging environment connects to the proposed cloud platform.
A current school-district RFP we reviewed illustrates the complexity particularly well: bidders must account for analog paging in different electrical orientations, SIP trunks, individually registered SIP paging endpoints, multiple paging zones and buildings where multicast is unavailable between sites. LCSD1 Phone System RFP Word doc…
That is the level of detail districts should seek.
This deserves its own RFP question.
Legacy paging equipment can connect to a PBX in different ways.
In one building, the phone system may need to provide dial tone, talk battery and ringing to the paging equipment.
At another building, the paging head-end may provide the analog telephone interface to the phone system.
Those scenarios can require different gateway interfaces.
Therefore, don't simply specify:
"Provide an analog adapter for paging."
Require the vendor to identify:
The district may not know the orientation at every building before issuing the RFP. That's fine.
Require the successful vendor to determine it during the site survey and price the necessary equipment in advance.
Newer schools may use SIP-connected paging or network-based intercom platforms rather than analog paging.
Your RFP should ask:
This is particularly important if the district's WAN does not transport multicast between buildings.
The RFP should not allow a bidder to design a solution around multicast unless the district's network actually supports the proposed architecture.
Paging and intercom are not necessarily the same thing.
A school may require the front office to speak with a classroom and the classroom to respond through the intercom system.
Some facilities also have emergency all-call functionality initiated by a fire alarm or other life-safety system independent of the PBX.
Require vendors to explain how the proposed solution preserves those workflows.
For districts using platforms such as Audio Enhancement EPIC, ask bidders whether the integration is a supported product capability, whether they have implemented it previously, and whether integration occurs through SIP stations, SIP trunks or another interface. These are examples of the detailed questions appearing in current school-district procurement documents. LCSD1 Phone System RFP Word doc…
Door stations are another commonly overlooked system.
Schools may have SIP-based devices from manufacturers such as AXIS or Aiphone that call the front office when a visitor presses a button.
Document:
Then ask bidders whether existing devices can register directly to the cloud platform.
Also consider the actual user experience.
A particularly useful requirement from a current district RFP addresses a real operational problem: a door call should not interrupt an employee's existing telephone call. The proposed system must provide another way to alert or route the entry call. LCSD1 Phone System RFP Word doc…
Requirements like this distinguish an operational RFP from a feature checklist.
Moving to the cloud doesn't necessarily eliminate analog devices.
School districts may still have:
Document each device individually.
Ask vendors to state how it will be supported and identify the required gateway.
If faxing remains analog, ask about T.38 support.
If modems or specialty devices remain, ask whether G.711 pass-through or another method is supported.
A district RFP we reviewed goes further by requiring analog interfaces to provide appropriate central-office-style talk voltage and ringing for attached devices. LCSD1 Phone System RFP Word doc…
That is an excellent requirement because "has an analog port" does not necessarily mean "works with every analog device."
E911 should never be a checkbox buried under general telephone features.
School districts have distributed buildings, classrooms, floors and campuses. Emergency responders need meaningful dispatchable location information.
Your RFP should address:
A strong RFP should ask what happens when someone physically moves a telephone.
That matters in schools because phones may be disconnected and moved during summer cleaning, remodeling or classroom changes.
One current district RFP explicitly asks vendors how the district can ensure phones are not returned to the wrong classroom following summer deep cleaning. It also asks vendors to distinguish the cost of roughly building/floor-level ERLs from individual station-level identification. LCSD1 Phone System RFP Word doc…
That is exactly the kind of real-world question an E911 design needs to answer.
When someone dials 911, designated district personnel may also need to know immediately.
Ask whether the system can notify:
And specify whether notifications can be delivered by:
The notification should identify the calling endpoint and its dispatchable location.
The district should also be able to configure different recipients by school or building.
A cloud provider saying simply "we are E911 compliant" is not an adequate RFP response.
Moving the PBX to the cloud moves greater responsibility onto the data network.
Require a predeployment network assessment.
Ask vendors to specify acceptable thresholds for:
Also ask whether the cloud platform provides real-time and historical call-quality information.
If an employee reports:
"My call sounded terrible yesterday at 10:15."
IT should have enough information to determine whether the problem was packet loss, latency, the local network, ISP connectivity, endpoint, carrier or cloud service.
A current district RFP specifically requires vendors to describe what they measure, how long they measure it, how many locations they test, what constitutes acceptable voice quality and what happens if the network fails the assessment. LCSD1 Phone System RFP Word doc…
Ask what happens when:
Then determine what level of survivability the district actually requires.
Cloud platforms vary significantly in how they handle outages.
Mobile applications, cellular forwarding, redundant Internet circuits, local gateways and other strategies may be appropriate depending on the site.
The important point is to design the failure behavior intentionally rather than discovering it during an outage.
Most school districts already have a substantial Microsoft environment.
The RFP should distinguish between:
Microsoft 365 integration and Microsoft Teams calling integration.
They aren't necessarily the same thing.
Ask about:
Also specify how many employees actually require Teams telephony integration.
Don't automatically purchase the feature for every classroom or common-area telephone.
Teachers, administrators, facilities personnel and other employees increasingly use smartphones.
If employees use personal devices for district business, the RFP should require the mobile application to place and receive calls using the district's business identity, without exposing the employee's personal cellular number.
A current district requirement specifically calls for this behavior on both iOS and Android. LCSD1 Phone System RFP Word doc…
Also ask whether mobile functionality requires an additional license.
Receptionists use a telephone system differently than classroom users.
Document requirements for:
Don't assume a generic softphone provides the same workflow as the existing operator station.
Test it.
A school district may need call queues without needing a full contact-center platform.
Examples include:
Ask for:
Then ask vendors to identify whether these capabilities are included in the base UC license or require separate queue/contact-center licenses.
A large school district should rarely be migrated as one giant cutover.
Instead, establish phases.
For example:
Pilot → selected administrative site → several schools → larger migration groups → remaining sites
The existing PBX and new cloud system may therefore need to coexist for weeks or months.
Your RFP should explicitly require:
During migration, can an employee already migrated to the cloud call an employee still on the legacy PBX by extension?
And:
Can calls be transferred between the old and new systems?
This may require temporary SIP connectivity and coordinated dial plans between the systems.
The LCSD procurement we reviewed explicitly requires approximately 40 locations to migrate in phases and calls for SIP trunk integration with the existing Mitel system plus coordinated digit insertion/deletion so users on either platform can communicate during the transition. LCSD1 Phone System RFP Word doc…
This is an excellent requirement for any large district.
HCWT strongly recommends:
Do not make the telephone-number port the beginning of your testing process.
The new cloud environment should be substantially built before production numbers move.
Configure and test:
Then perform the number port.
This provides a much safer migration path and a meaningful rollback strategy.
A district should define several testing stages.
Unit Testing (UT) verifies individual components.
System Integration Testing (SIT) verifies that those components work together.
User Acceptance Testing (UAT) confirms that the system actually meets the district's operational requirements.
Include real-world scenarios.
Can a receptionist transfer a parent to a classroom?
Can a teacher dial 911?
Does the correct location appear?
Does a school page reach the correct speakers?
Can the front office answer a door station?
Does voicemail-to-email work?
Can a cloud user transfer a call to someone still on the legacy PBX?
A current district RFP explicitly requires vendor UT and SIT before joint UAT. LCSD1 Phone System RFP Word doc…
That is a good model.
Every site should have a documented cutover plan.
Specify:
Pay particular attention to telephone numbers used by fire, burglar or other monitoring services.
A current district RFP requires those critical numbers to be verified both before and after each site's cutover and requires the vendor to state its rollback position if one fails. LCSD1 Phone System RFP Word doc…
That's an excellent requirement.
Different users need different training.
Separate training into:
Administrators – provisioning, reporting, troubleshooting, E911, moves/adds/changes and system management.
Receptionists and power users – transfers, BLF, park, queues, directories and advanced call handling.
General users – calling, voicemail, applications, mobile use and basic features.
Require:
Training shouldn't end the day the system goes live.
Cloud communications places calling, voicemail, messages and potentially recordings outside the district's traditional PBX.
The RFP should address:
Don't accept "enterprise-grade security" as the complete answer.
Require vendors to explain what that means.
Ask who actually answers when the district has a problem.
Is it:
Require the bidder to identify responsibilities.
The SLA should address:
For a school district, the implementation partner's capabilities can be just as important as the underlying cloud platform.
Don't simply request "three references."
Ask for projects that resemble yours.
Request:
Also ask:
Have you completed a migration from the PBX platform we currently operate?
Experience migrating 2,000 users from one cloud platform to another is useful, but it isn't necessarily the same as extracting call flows, hunt groups, extensions, analog devices and paging interfaces from a 15-year-old PBX.
This is frequently overlooked.
A cloud communications provider supplies the platform.
Someone still needs to understand the existing environment and migrate it.
For a legacy PBX conversion, evaluate whether the implementation organization understands:
A partner that understands both the legacy environment and the destination platform can identify problems that might otherwise appear only during deployment.
Don't choose a system based only on monthly price per user.
Calculate a multi-year TCO that includes:
Also ask how licensing works during a phased migration.
If only 500 of 3,000 endpoints have been migrated, does the district immediately pay for all 3,000 cloud licenses?
A current school-district RFP requires vendors to explain their assumed licensing ramp as part of the five-year TCO and confirm whether quoted unit rates remain unchanged if the district chooses a different migration ramp. LCSD1 Phone System RFP Word doc…
That's an excellent procurement practice.
Every bidder should price against the same quantities.
Provide a pricing schedule containing specific line items and quantities.
Then require:
Quantity × unit price × term = extended cost
Separate mandatory requirements from optional capabilities.
For example:
This makes proposals much easier to compare.
A good RFP should force vendors to answer several questions that often aren't discovered until implementation:
What happens to our paging system?
Can our existing classroom phones be reused?
Does every classroom phone require a full user license?
How are multiple teachers with individual voicemail handled on a shared classroom phone?
What happens when someone moves a phone to another classroom?
Can our door stations register to the new system?
Will a door call interrupt a call already in progress?
What happens to fax machines and other analog devices?
How do cloud and legacy PBX users communicate during a phased migration?
What happens if the Internet connection to a school fails?
How does a 911 call identify the correct building, floor or classroom?
Who receives an alert when 911 is dialed?
Can the system integrate with Microsoft 365 and Teams without licensing every classroom phone for Teams?
When does billing begin during a phased rollout?
What exactly constitutes final acceptance?
Those questions can reveal far more about a proposed solution than a 200-line generic feature checklist.
The objective of an RFP isn't to identify the cloud provider with the longest feature list.
It is to determine whether the proposed communications environment can support the way the district actually operates.
A well-designed RFP allows vendors to propose different technologies while requiring each vendor to demonstrate how its solution handles the same operational requirements.
For a school district, those requirements extend far beyond dial tone.
They include classrooms, emergency communications, paging, intercom, door access, mobile employees, network reliability, Microsoft integration, analog equipment, migration planning and long-term support.
The safest cloud migration is one in which the new environment has already been configured and tested before the legacy PBX disappears.
HCWT recommends completing discovery, system design, provisioning, integration, testing and user acceptance before the final production number ports whenever possible.
For larger districts, temporary coexistence between the legacy PBX and cloud platform can make it possible to migrate building by building rather than attempting a district-wide flash cut.
The goal should be a controlled migration—not simply a replacement.
High Country Workplace Technologies helps school districts evaluate, design and migrate business communications environments.
HCWT's experience spans legacy and current communications technologies including Mitel, ShoreTel, Avaya, RingCentral, Zoom, Microsoft Teams integration, SIP, paging, networking and analog telecommunications.
That combination is particularly important during legacy PBX migrations because the challenge is often not installing the new cloud platform.
The challenge is understanding everything connected to the old one.
HCWT can assist with:
A school district cloud communications RFP should include requirements for user and device licensing, classroom and common-area phones, E911, paging and intercom, analog devices, door stations, call queues, Microsoft 365 and Teams integration, network readiness, security, phased migration, testing, training, support and long-term total cost of ownership.
Not necessarily. A classroom phone may be a shared or location-based device and may not require the same capabilities as an administrator who needs a desk phone, desktop application, mobile application and advanced unified communications features. Districts should require vendors to separately identify classroom and common-area licensing rather than assuming every telephone requires a full UC user license.
Sometimes. Certain newer Mitel, Avaya and other IP phones may be candidates for reuse depending on the cloud platform, exact phone model, hardware revision, firmware and provisioning requirements. Districts should inventory existing phones and require vendors to identify which models can be reused, which require modification and which should be replaced.
The RFP should inventory existing paging and intercom systems by building and identify whether they use analog interfaces, SIP stations, SIP trunks, IP speakers or network-based intercom platforms. Vendors should explain the required gateways or interfaces, paging zones, licensing requirements and how two-way classroom intercom and emergency all-call functions will continue to operate.
The RFP should require compliance with applicable emergency-calling requirements, including Kari's Law and RAY BAUM'S Act, and should address dispatchable location, ERLs, ELINs, local PSAP routing, callback numbers, internal emergency notifications and location updates when phones move. The district should also determine whether emergency locations will identify buildings and floors or individual classrooms.
Analog devices should be inventoried individually. Fax machines, paging systems, modems, courtesy phones and other specialty equipment may require analog gateways, replacement devices or alternative services. The RFP should require vendors to identify the proposed solution and cost for each type of analog device.
Yes, if the migration is properly designed. For larger districts, the legacy PBX and cloud communications platform may coexist temporarily while schools and administrative buildings are migrated in phases. The RFP should require vendors to explain how users on the old and new systems will extension-dial and transfer calls between platforms during the transition.
HCWT recommends building and testing the new cloud communications environment before production numbers are ported whenever possible. Phones, call routing, voicemail, E911, paging, analog devices, door stations, mobile applications and other critical functions should be tested before the final cutover.
Districts should compare total cost of ownership rather than only monthly cost per user. Pricing should separately identify licenses, classroom and common-area devices, phones, E911, paging interfaces, analog gateways, implementation, training, support, optional features and other recurring charges. A three- or five-year TCO can provide a more meaningful comparison.
One of the biggest mistakes is treating the project as simply replacing one telephone with another. The existing PBX may also support paging, classroom communications, door stations, emergency calling, analog equipment, voicemail, call routing and other systems. These dependencies should be discovered and documented before vendors provide final pricing.
Whether your district is operating Mitel, ShoreTel, Avaya or another legacy PBX, the best time to discover hidden requirements is before the RFP is released and before pricing is finalized.
HCWT can help identify the technical requirements, integration points and migration risks that should be included in the procurement process. Contact Us.
This article was authored by Jim Whitfield