Telecare migration before 31 January 2027: a fixed date and a closing window

In the delivery model used in this article, completion also requires end-to-end testing and formal acceptance by the service owner. Programmes should therefore plan against 31 January 2027 rather than assume that further time will become available. Replacing or reconfiguring an alarm is not enough on its own: the new path must be demonstrated from the dwelling through to the monitoring centre. Without that test, the first proof of whether the service works may be a resident pressing a pendant during a genuine emergency.

The line an analogue telecare alarm unit was designed around is being withdrawn. That one analogue line carries the resident’s phone calls and the alarm’s calls to its monitoring centre, so the withdrawal affects both. Analogue units commonly signal in the voice band, and a digital voice service introduces different codecs, packetisation and timing. Compatibility therefore depends on the particular combination of alarm unit, signalling protocol, communications service and receiving-centre platform. An end-to-end test provides evidence that a given alarm unit can reach its monitoring centre over the new digital path at the time of testing.

Testing, therefore, turns an assumption into evidence, and authorised acceptance turns that evidence into a completion. 

A service owner is the council, housing provider or operator accountable for the telecare service. For the purposes of this model, the service owner should hold the consolidated assurance position and ensure that each alarm has an approved treatment, whether that involves replacement, reconfiguration or confirmed compatibility with the digital service. 

The Ofcom power-resilience requirements discussed here apply to communications providers and concern access to emergency organisations through the communications service. Openreach’s Prove Telecare service works with communications providers and telecare organisations. It completes the migration where the telecare equipment is shown to be compatible and restores the line to the original copper service where it is not, pending further action (Openreach, 2025). Both are important safeguards, but neither provides end-to-end acceptance of the telecare service on the service owner’s behalf.

Additional safeguards may also be needed in post-PSTN scenarios where systems require mains power rather than being powered through the line, as was often the case for PSTN telephones and some line-powered devices. Ofcom’s guidance expects at least one solution giving access to emergency organisations for a minimum of one hour during a power cut at the premises (Ofcom, 2018). In its 2018 response to Ofcom, the TSA pointed to UK and European telecare standards associated with longer battery back-up periods for home alarm equipment, including 24-hour provision, for extended outages such as storm damage (TSA, 2018). The applicable requirement should be confirmed against the relevant current standard and service specification.

The two are often read as one requirement, but the durations protect different functions. Ofcom’s one-hour provision concerns access to emergency organisations through the communications service. The longer telecare battery provision cited by the TSA concerns the home alarm unit remaining available during an extended outage. Neither duration, however, establishes the end-to-end resilience of the complete communications path to the monitoring centre on its own.

Power is an important issue. On a full-fibre service, the alarm may signal through the optical network terminal and broadband router. Both draw mains power, so the alarm path remains available during a power cut only while every required component has a functioning back-up power supply. The required duration and performance should be defined by the applicable standards, service specification and risk assessment.

Where the alarm unit uses its own cellular connection, however, the optical network terminal and fixed-line router, together with their premises-power dependencies, are removed from the alarm path. The achievable operating duration then depends on the telecare unit’s own battery specification, condition and configuration and must be verified as part of the service design and testing. Where CSL DualCore® provides that connection, the service can use multi-network roaming profiles routed through separate operator cores. This reduces dependence on a single operator core and supports continuity where a failure affects one of those core routes. The precise resilience and security controls depend on the implementation and end-to-end service design.

While Openreach plans a limited emergency voice-only service for some remaining lines (Openreach, 2025), published information about Emergency Voice Access does not establish compatibility with every telecare alarm, signalling protocol or monitoring-centre configuration. It should therefore not be treated as a substitute for planned migration, end-to-end testing and service-owner acceptance. 

For the underlying regulatory and industry detail, the primary sources are important. Ofcom publishes its General Conditions and guidance, Openreach publishes information about its migration programme, and the TSA publishes its standards framework and industry guidance. None of them, however, independently confirms or accepts a service owner’s individual units on its behalf.

Productive weeks for completing PSTN replacements are the weeks genuinely available for delivery, testing and acceptance. Time unavailable for those activities because of procurement, mobilisation, training, design approval, resident communications, governance holds and final assurance must first be removed from the calendar. The number removed will differ by programme and must be calculated from its procurement position, governance cycle, workforce and holiday pattern. The table below cannot determine those local inputs.

The required weekly output is the verified number of analogue alarm units still awaiting acceptance, divided by the productive weeks remaining and rounded up. An accepted completion is a service that the service owner has accepted on recorded evidence across the complete alarm path. Using this method, a programme with 5,000 units and 15 productive weeks needs 334 accepted completions a week.

If six weeks are removed (caused by delays or unproductive weeks), the productive window falls from 15 weeks to nine, increasing the requirement for the same 5,000 units to 556 accepted completions a week. The workload remained at 5,000 units, but the weekly requirement increased from 334 to 556 accepted completions a week because the same work was compressed into a shorter available timeframe. A delay therefore does not push the work later; it concentrates it into fewer weeks.

Figure 1 shows how quickly the weekly requirement rises as the productive window contracts. To use, select the verified remaining workload on the left, then read across to the number of productive weeks genuinely available. 

Figure 1: Accepted completions required each week, by units awaiting acceptance and productive weeks remaining. Each value is the remaining workload divided by the productive weeks available, rounded up. 

At 1,000 units across 15 productive weeks, the requirement is 67 accepted completions a week. At 10,000 units across three productive weeks, it rises to 3,334. Once the remaining workload and productive window have been established, the table shows both the weekly requirement and the effect of losing further weeks. 

The table applies no contingency, so every value can be checked by division. Where identified uncertainty requires a planning allowance, it should be added to the verified workload and stated separately as a percentage. For example, a 15 per cent allowance increases a verified workload of 5,000 units to an adjusted workload of 5,750, raising the 15-week requirement from 334 to 384 accepted completions a week. 

In this example delivery model, four records separate a delivery from an accepted completion: 

• an asset record that identifies the equipment, its location and the responsible service owner 

• an approved treatment that records what must be done 

• a test result that demonstrates end-to-end operation from the dwelling to the monitoring centre 

• an authorised acceptance confirming that the service owner has accepted the service on the recorded evidence 

Where one record is absent, the item remains at the last stage supported by the available evidence and cannot be counted as an accepted completion. Reporting it as complete can conceal unresolved risk and leave the resident dependent on a service that has not been fully evidenced. In England, the Telecare National Action Plan states that no telecare user should be migrated until a compatible and functioning solution has been confirmed (Telecare National Action Plan, 2025). The plan states that confirmation may come from the communications provider, the customer, the telecare supplier or the telecare service provider. The four-record approach above is the method used in this model to help providers to plan and evidence completion within their own processes. It is not presented as a requirement of the national plan. 

Can the delivery routes sustain the number of accepted completions the programme now requires each week? 

Two rates answer that question. The required rate comes from the division above. The achieved rate is the number of accepted completions currently being recorded through the chosen route or combination of routes. Where that route requires a visit, first attempts, revisits and unsuccessful access attempts all draw on the same pool of visit slots. 

Self-install units with spoken setup instructions are already in use and can reduce the number of installations that require a visit. They move the scarce resource from visit slots to dispatch, resident engagement and returns, so the constraint moves rather than disappears. The acceptance requirement, however, does not change. Evidence must still show that the alarm was activated successfully and that its communication was received correctly by the monitoring centre, rather than relying on an installer’s or dispatch record. 

The two rates move independently. A visiting team can hit its visit target every week and still accept fewer units than the required rate demands. The remaining workload then falls more slowly than the plan assumed. The reverse can also apply. A programme may complete fewer visits than planned but remain on track if its first-time acceptance rate is higher than planned. Visits and dispatches measure activity; authorised acceptances reduce the remaining workload. 

A programme can establish its current position using three counts. 

• First, verify how many analogue units remain and record which entries are evidenced rather than assumed.
• Second, calculate the productive weeks available for delivery, testing and acceptance; dividing the verified workload by this window gives the required weekly rate. 
• Third, total the accepted completions currently being achieved across the programme’s delivery route or routes and compare that figure with the required weekly rate. 

None of the figures above describes an individual organisation or plan, and all are provided for illustrative purposes only. The model assumes an even spread of accepted completions across the productive window. Where a programme ramps up delivery, early weeks run below the line and later weeks above it. The required rate is an average to plan against rather than a target for week one. 

The method above is supplier-neutral, as a product decision forms part of the service design, the risk assessment and the acceptance criteria. Where an architecture review identifies a requirement for managed or resilient connectivity, CSL can provide appropriate connectivity for dispersed alarms and grouped schemes, together with supporting communications infrastructure and services.

CSL’s approach to resilience prioritises independence, not redundancy alone. For example, CSL DualCore® uses two roaming SIM profiles routed through separate operator cores, so the two connectivity routes do not share the same operator-core dependency. A failure affecting one operator core therefore does not extend to the second profile through a shared operator core. CSL DualCore® is an architectural approach rather than a single product, and it can be implemented in different ways according to the equipment and service design. 

For instance, in one CSL DualCore® implementation, a telecare alarm unit uses two separate SIMs carrying the two roaming profiles, with connectivity monitoring and switching controlled by the unit’s firmware. In an alternative approach, rSIM® holds the two roaming profiles on a single SIM and places the connectivity monitoring and switching capability within that SIM. This allows compatible equipment to use DualCore® without CSL switching logic being built into the alarm unit’s firmware. 

For a grouped scheme, the CSL router can combine fixed-line broadband with cellular failover or provide cellular resilience through two roaming SIMs. Fixed-line broadband with cellular failover provides diversity between access technologies. Where the router instead uses two roaming SIMs routed through separate operator cores, it provides CSL DualCore® resilience across the cellular connections. The appropriate configuration depends on the service design, the available fixed-line connection and the resilience requirements for the site. 

Depending on the implementation, switching is initiated by the alarm unit, rSIM® or router rather than relying solely on a remote instruction delivered over the affected connection. CSL can provide the cellular paths through private APN services, with an encrypted VPN connection to the monitoring centre. In that configuration, those cellular alarm paths do not rely on the public internet between the CSL connectivity service and the monitoring centre. The service design should define appropriate security, management and performance requirements for every path, rather than treating failover as an uncontrolled or lower-grade emergency connection.  

CSL can help you apply the run-rate model to your verified inventory, productive window and current acceptance rate to show whether the required weekly output fits the capacity available. For more information on the PSTN switch-off, please see: PSTN Switch-Off | Transition seamlessly with CSL’s solutions

Alternatively, contact us for more information:

1. Department of Health and Social Care and Department for Science, Innovation and Technology. Telecare National Action Plan: protecting telecare users through the digital phone switchover, 11 February 2025. [gov.uk] 
2. Ofcom. Protecting access to emergency organisations when there is a power cut at the customer’s premises, guidance published 10 October 2018. [ofcom.org.uk] 
3. TSA. Response to Ofcom’s proposed guidance on protecting access to emergency organisations when there is a power cut at the customer’s premises, 2018. [ofcom.org.uk] 
4. Openreach. Just six months left before the UK’s old phone network is switched off, 31 July 2026. [openreach.com] 
5. BT Business. Your guide to the PSTN switch-off, accessed 31 July 2026. [business.bt.com] 
6. Openreach. Openreach clears major hurdle to PSTN switch-off, 17 September 2025. [openreach.com] 
7. Openreach. Openreach announces price changes to encourage digital adoption of newer, more reliable and better value technology, 12 November 2025. This source describes Openreach’s planned emergency voice-only service for lines remaining after the PSTN deadline. [openreach.com]