Before the dialling tone changes: assuring emergency access in a UK telephony migration

A telephony migration is rarely just a technology swap. It changes the route by which people reach help, the way premises signal an alarm, and the assumptions embedded in systems that nobody has reviewed for years. For UK organisations, the retirement of legacy telephone networks makes this a live programme issue rather than a distant concern. The project plan may be thorough on handsets, contact centre routing and number porting. It is often much thinner on the services that depend on a phone line but do not look like phones.

Emergency access deserves its own assurance track. Not because it is a niche technical concern, but because it is one of the few migration risks that can become a serious operational incident within minutes. The test is not whether a handset can make a call. The test is whether a person, a lift, an alarm or a payment terminal can still reach the right destination, with the right location information, when it matters.

Emergency access is a resilience dependency, not a telephony feature

Most migration plans treat emergency calling as a configuration item. In practice it is a chain of dependencies: the device, the network, the power supply, the routing configuration, the receiving centre, the location data and the person who knows what to do when a test fails. A voice over IP service can be perfectly adequate for ordinary calls and still leave an alarm panel unable to signal, a lift line unable to connect, or a lone worker unsure whether their device has switched from mobile to Wi-Fi.

The starting point is to stop relying on the supplier inventory as the definitive list. Telecoms inventories are built for billing and network management, not for operational resilience. They rarely capture the alarm panel in a basement, the payment terminal in a pop-up shop, the telecare device in a supported living property or the out-of-hours line used by a security team. A short physical walk of each site, combined with interviews with facilities and operations, will usually find more than a spreadsheet review.

Build a lifeline register before design is fixed

A lifeline register is a simple control with a long reach. For each dependency, record the location, the current line or connection type, the receiving destination, the business owner, the fallback arrangement, the test method and the evidence location. The register should cover, at minimum:

• Emergency call points in reception, security rooms and public-facing areas.
• Lift autodiallers and any line used by lift maintenance or monitoring.
• Fire and intruder alarm signalling, including dual-path or Redcare-style arrangements.
• Nurse call, telecare and supported-living alarm systems.
• Payment terminals, EPOS connections and card machines that depend on a fixed line.
• Lone-worker devices, man-down alarms and check-in systems.
• Door entry, CCTV monitoring, utility meters and out-of-hours service lines.
• Fax or analogue lines still used by clinical, legal or property teams.

The register is not an end in itself. It becomes useful when it is assigned to named owners and reviewed alongside the migration design. If a dependency cannot be explained by an operational owner, that is a warning sign. If a supplier cannot confirm compatibility in writing, that is a gate, not a note for later.

Test the route, not just the handset

A common mistake is to test a sample handset and declare the site ready. Emergency access is not proven by a dialling tone. It is proven by observing the full route from initiation to answer, including location data where relevant, call handling at the receiving end and behaviour during a power or network interruption.

Do not place speculative 999 or 112 calls. Agree a controlled test plan with the supplier and, where relevant, the alarm receiving centre or emergency service contact. The test should confirm that the correct address or location is presented, that the receiving operator can call back where required, and that the fallback works if the primary connection is unavailable. For alarm systems, ask the maintainer to evidence signalling compatibility rather than assuming that an analogue adapter is sufficient. For payment terminals, test a real transaction in the live environment, not just a ping.

Use cutover gates to make go-live conditional

A migration should not proceed on a single go/no-go meeting. Use a small number of cutover gates with named evidence. Before cutover, the lifeline register should be signed off by operations and facilities, fallback arrangements should be documented, and receiving centres should be notified of the change window. During cutover, keep the old service available in parallel where technically possible, or have a tested diversion in place. After cutover, test the highest-risk dependencies first and record the result immediately.

A practical gate structure is:

1. Register complete and owners confirmed.
2. Supplier compatibility evidence received for alarm, lift and payment systems.
3. Fallback tested and communicated to front-line staff.
4. Cutover completed with old service retained or diversion active.
5. Emergency and alarm tests passed and logged.
6. Thirty-day review completed with incidents and near misses reviewed.

If a gate fails, the migration does not need to stop everywhere. It should stop for the affected service. That distinction matters: a site can move ordinary telephony while a lift line remains on a supported legacy arrangement until the maintainer has certified the replacement.

Produce an evidence pack the board can rely on

The output should be short enough to be read and specific enough to be challenged. A one-page dashboard is usually sufficient: service, site, owner, test date, result, fallback, open actions and next review date. Attach the test logs, supplier confirmations and alarm receiving centre acknowledgements. Keep the pack with the business continuity and operational resilience records, not buried in a project folder.

The evidence routine should also capture near misses. A call that connects on the second attempt, an alarm that signals but presents the wrong location, or a payment terminal that works only on one network path are all findings. They may not be outages, but they are exactly the kind of operational weakness that a migration can expose.

The test before the test

The most useful question is not whether the new system supports emergency calls. It is whether the organisation can prove, service by service, that emergency access still works after the change. That requires a register, controlled testing, cutover gates and an evidence pack that operations, facilities and IT can stand behind. A telephony migration can then be judged on more than cost per seat or handset count. It can be judged on whether the quiet dependencies were brought into the plan before the dialling tone changed.