TOTSCo switching and legacy number porting are not replacements for one another. TOTSCo coordinates the broader provider-switching journey matching customers, exchanging switching information, and aligning gaining and losing providers. Legacy number porting transfers a customer’s existing telephone number when the voice service moves between networks. In many fixed-voice switching scenarios, both processes must run in parallel. UK Communication Providers need to align switching dates, define ownership, and test combined scenarios to avoid service disruption and number-transfer failures.
What Is Legacy Number Porting?
Number porting allows a customer to keep an existing telephone number when changing communications provider or network. The basic objective is straightforward: the customer changes service provider, but the telephone number stays with them. Behind that apparently simple customer experience sits an established set of industry processes used to coordinate the transfer of the number between the relevant providers and networks. In a traditional porting journey, the focus is on validating the number being ported, coordinating the losing and gaining networks, scheduling the port, transferring routing responsibility, and maintaining continuity of the customer’s number throughout the process.
The important point is that number porting does not, by itself, manage the entire provider switch. It solves the number-retention part of the journey, nothing more and nothing less. That distinction matters even more now that switch journeys are being standardized across different networks and technologies.
When Do TOTSCo and Number Porting Need to Work Together?
Consider a straightforward example: a customer has broadband and a fixed telephone service with Provider A. They have decided to move both services to Provider B and want to keep the existing telephone number. The switch may involve two related processes running in parallel.
First, the wider switching journey is coordinated between the gaining and losing providers through the relevant TOTSCo-supported process. At the same time, the telephone number may need to be ported between voice networks.
If those activities are not coordinated correctly, problems can occur across every stage of the customer journey. The old voice service may stop before the port completes. The new service may become active without the expected number. The port date may not align with the switching date, leaving the customer in a gap between the two processes. Customers may experience avoidable downtime that damages trust and generates complaints. And operational teams may need to intervene manually to resolve failures that should never have reached production in the first place. This is why alignment between switching and porting is not optional. TOTSCo’s own guidance highlights the need for the two processes to work consistently and reliably together and the operational consequences when they do not.
TOTSCo vs Legacy Number Porting Process
Where Legacy Number Porting Still Matters
The word legacy can be misleading. It does not mean number porting is obsolete. Traditional porting processes still perform an essential function whenever a customer wants to retain a number and that number must move between voice networks. What has changed is the wider context around the port. In older switching models, number porting could form a large part of the operational switching process itself. In a modern TOTSCo-supported journey, porting becomes one component inside a broader, coordinated switch.
The provider therefore needs to think about the full picture switching messages, customer matching, service activation, number-port scheduling, cessation timing, and exception handling as a single connected operational sequence rather than a series of independent tasks. Each of these elements affects others. A delay in number-port scheduling affects cessation of timing. A failure in customer matching affects service activation. An unhandled exception affects the entire journey.
Rather than treating the port as an isolated transaction which is how legacy porting was historically managed, modern CPs must treat it as one coordinated step inside a larger operational journey. The port does not stand alone. It succeeds or fails alongside everything around it.
What UK Communication Providers Need to Prepare For
The practical challenge is coordination, and it is more complex than it first appears.
A CP may have different internal systems or teams responsible for switching and number porting. In some cases, the organizations involved in each process may also differ; the team managing TOTSCo switching messages may have no visibility into the porting workflow, and the team managing ports may have no visibility into switching timelines. That structural separation is where most coordination failures begin. Poor coordination between switching and porting is one of the most common TOTSCo migration mistakes CPs make and one of the most expensive to fix after go-live, because by the time the gap surfaces, real customers are already affected. The providers who handle this well do not treat switching and porting as two separate workstreams that happen to run at the same time. They treat them as one coordinated operational journey with shared ownership, shared timelines, and shared monitoring. Getting there requires deliberate preparation across four areas before going-live, not after it.
1. Align Switching and Porting Dates
The port should not happen in isolation from the wider customer switch, and yet this is one of the most common points of failure in combined switching and porting journeys.
The timing of activation, cessation, and number transfer needs to be coordinated precisely and agreed between all relevant teams before any switching message is sent. A port that completes before the new service is active leaves the customer without a working service; they have lost the old one and the new one is not yet ready. A new service that is activated before the port completes leaves the customer with a working service but without the number, they expected to keep which generates complaints, manual intervention, and in some cases a second operational journey to resolve. Both outcomes are entirely avoidable with proper date alignment. The key is not just agreeing with the dates, it is making sure the agreement is visible to every team involved in both processes, and that any change to one date triggers an immediate review of the other.
2. Define Ownership
Ownership is where coordination most commonly breaks down not because teams are unwilling to take responsibility, but because nobody agreed with the boundaries clearly enough before go-live.
Every part of the combined switching and porting journey needs a named owner, the switching journey itself, the port request, failed matching, failed porting, customer communication at each stage, and escalation paths when things go wrong. Each of these areas can fall into a gap between teams if ownership is not defined explicitly. The switching team assumes the porting team owns customer communication during the port window. The porting team assumes the switching team owns escalation when the port fails. Neither team acts nor the customer waits.
Without clear ownership, exceptions bounce between operational teams for longer than they should, resolution times extend, and customers experience exactly the kind of switching failure that Ofcom’s One Touch Switching framework is designed to prevent. A responsibility matrix agreed before implementation mapping every task to a named team or individual prevents the confusion that surfaces during an incident when there is no time to negotiate ownership.
3. Test Combined Scenarios
Testing is the area where most CPs take the most shortcuts and where those shortcuts have the most visible consequences in production.
Testing should not cover switching and porting independently only. Providers should also test scenarios where both happen together because it is the interaction between the two processes that produce the failures that isolated testing never catches. A successful switching message followed by a failed port is a different kind of failure from a failed switching message alone. A port that completes on schedule but against a switching journey that has been delayed produces a different operational problem from either event in isolation.
The scenarios that matter most are the ones that cross the boundary between the two processes a successful switch and port running together, a switching delay with the port on schedule, a port delay with the switch on schedule, a failed number validation mid-journey, a customer cancellation after the switching message has been sent but before the port completes, and service activation problems that affect the port window. Testing each process in isolation gives you confidence that each works independently. Testing them together gives you confidence that the combined journey works under the real-world conditions your customers will experience.
4. Monitor Exceptions
A completed switching message does not necessarily mean the number port has completed successfully, and this is the monitoring gap that catches the most CPs off guard after go-live.
Operational monitoring should cover both sides of the journey simultaneously and in a way that allows teams to correlate switching status with porting status in real time. Teams need visibility into switching message status and port completion status at the same time not in two separate operational views that nobody is actively correlating, and not through a process where one team discovers a porting failure by receiving a complaint that the other team escalated two days after the event.
The monitoring approach should be defined before go-live and agreed between all teams involved in both processes. It should specify what triggers an alert, who receives it, what the response time expectation is, and how the two operational views are brought together into a single picture of the combined journey. Exceptions that are caught early are resolved quickly. Exceptions that are discovered through customer complaints are resolved slowly and more expensively.
TOTSCo and Number Porting Process
Why This Difference Matters More Today
The move to gaining-provider-led switching has changed customer expectations permanently.
Ofcom’s General Conditions of Entitlement introduced One Touch Switch so residential landline and broadband customers can contact only the new provider when switching, including when moving between different networks. That makes the customer journey simpler on the surface. But behind the scenes, provider coordination becomes significantly more important.
Where number retention is involved, the customer should not need to understand which part of the process is TOTSCo and which part is porting. They simply expect the switch to work on time, with the right number, and without service interruption.
For Communication Providers, that means technical processes that were once treated separately need to be operationally aligned. The providers who treat switching and porting as one coordinated journey are the ones delivering the customer experience Ofcom’s framework is designed to achieve. The providers who treat them as separate transactions are the ones generating the complaints and exceptions that consume operational resources and attract regulatory attention.
TOTSCo vs Legacy Number Porting: The Practical Takeaway Porting
The easiest way to understand the difference between TOTSCo vs legacy number porting is this:
TOTSCo manages the switching conversation.
Number porting manages the number transfer.
That distinction sounds simple. In practice it is the source of most of the operational problems that UK Communication Providers encounter when running combined switching and porting journeys because the two processes look similar on the surface, involve overlapping teams and timelines, and affect the same customer at the same time. Assuming they are the same thing, or that one replaces the other, is where the gaps begin. A switch may need only one of those processes, or it may require both. A broadband-only switch with no retention requirement may complete entirely through TOTSCo-supported switching with no porting involvement at all. A fixed-voice switch where the customer wants to keep their existing number will almost certainly require both processes to run in parallel, coordinated against a shared timeline, with clear ownership across every stage of the journey.
The key is not to replace one with the other. It is not to assume that because TOTSCo is in place, number porting takes care of itself. And it is not to treat number porting as a legacy concern that modern switching infrastructure has made irrelevant. Both processes are live, both are required in the right scenarios, and both must be managed with the same operational rigor. What that looks like in practice is a switching operation where dates are aligned before any message is sent, ownership is defined before any exception occurs, combined scenarios are tested before go-live exposes them in production, and monitoring covers both the switching message and the port completion simultaneously, in a single operational view that gives teams the full picture rather than half of it.
The providers who get this right do not think about TOTSCo and number porting as two separate workstreams that happen to affect the same customer. Before selecting a platform, understanding the questions to ask any switching provider will help identify whether a provider has built their operation to handle both processes as one coordinated journey.
Conclusion
The distinction between TOTSCo vs legacy number porting matters because the two processes serve different purposes and misunderstanding that difference creates operational and compliance risks for UK Communication Providers.
Number porting remains responsible for transferring a customer’s telephone number when a network change requires it. TOTSCo-supported switching coordinates the broader customer journey between gaining and losing providers. For UK Communication Providers, the challenge is therefore not choosing between TOTSCo and number porting; it is making sure switching, porting, activation and customer communication work together as one reliable journey. The providers who get this right are the ones who plan for both processes from the start aligning dates, defining ownership, testing combined scenarios, and monitoring exceptions across the full journey. The providers who treat them as separate operational concerns are the ones who discover the gaps at the worst possible moment.