TOTSCo migration mistakes are often caused by treating the process as a technical integration rather than an end-to-end operational change. Common risks include choosing the connection model too late, incorrect onboarding data, incomplete testing, poor exception handling, weak monitoring and unclear ownership after go-live. Avoiding these errors can reduce rework, failed messages and unnecessary switching delays.
Moving a switching operation into the TOTSCo ecosystem can appear straightforward: prepare, connect, onboard, test and go live. But each stage touches customer data, workflows, integrations, support and ongoing governance.
TOTSCo migration refers to the process of moving a Communication Provider’s switching operations onto the TOTSCo Hub, either through a direct connection or via a Managed Access Provider (MAP). If you want to understand how TOTSCo supports UK telecom switching, read What Is TOTSCo?
TOTSCo’s Business Switching guidance follows the same broad sequence: get ready, connect, onboard, test and start switching. Providers can connect directly or use a MAP, while Full Management MAP customers onboard through their chosen MAP.
Why TOTSCo Migration needs more than a working connection
A successful connection to the TOTSCo Hub proves that systems can communicate, but it does not necessarily mean a Communication Provider is ready to manage real-world switching operations.
Migration TOTSCo involves much more than establishing connectivity or exchanging messages. Providers need to align their technology, customer data, operational workflows, internal teams, monitoring capabilities and exception-handling processes to support the complete switching journey.
The operational scale makes this distinction particularly important. TOTSCo confirmed in June 2026 that the residential One Touch Switch process had crossed the 3 million completed switches mark. Although residential OTS and business switching remain separate journeys, this milestone shows just how much volume standardized switching infrastructure is now capable of handling.
It also highlights why providers need robust processes around their technical integrations rather than relying solely on a successful connection. Working integration is only the starting point. Once switching activity moves into production, providers must be prepared to handle both expected and unexpected scenarios.
Customer information may be incomplete or inconsistent, services may not match the information held in internal systems, messages may be rejected, or downstream platforms may be temporarily unavailable. In these situations, the ability to identify the problem, understand its impact and resolve it quickly becomes just as important as the underlying connectivity.
What operational readiness should cover
Accurate Customer and Service Data: Switching processes depend on reliable information moving between systems. Customer, service, brand, and identifier data should be accurate and consistent across the platforms involved in the switching journey. Data inconsistencies can create validation issues, failed transactions, and additional manual work for operational teams.
End-to-End Transaction Visibilit: Teams need visibility into what is happening at every stage of a switching request. Simply knowing that a message was sent is not enough. Providers should be able to understand whether the message was received, processed, rejected, delayed, or requires further action. This visibility allows teams to identify bottlenecks and respond before issues significantly affect customers.
Effective Exception Handling: Not every switching request will follow the expected path. Validation failures, service mismatches, rejected messages, system errors, and other exceptions need clearly defined handling processes. Teams should know what action is required, who owns the issue, and when an exception needs to be escalated.
Monitoring and Performance Management: Production readiness also requires ongoing monitoring. Providers should track transaction volumes, processing times, failure rates, exception volumes, and other relevant operational indicators. Monitoring helps teams identify recurring problems and distinguish isolated incidents from wider processes or integration issues.
Clear Ownership and Escalation: Switching involves multiple systems and teams, so unclear ownership can quickly turn a technical issue into an operational delay. Customer support, provisioning, and technical and operations teams should understand their responsibilities and escalation paths. Where a Managed Access Provider is involved, responsibilities between the CP and MAP should also be clearly defined.
Recovery and Business Continuity: Providers should also prepare for situations where systems or integrations become temporarily unavailable. Defined recovery procedures can help teams resume processing, manage affected transactions, and minimize customer disruption. This is particularly important for business customers where switching delays may have a wider operational impact.
Ultimately, TOTSCo migration should be treated as an end-to-end operational readiness exercise rather than simply a technical integration project. The Hub provides the infrastructure for standardized switching, but the reliability of overall experience depends on the processes, people, data, monitoring and support capabilities built around that infrastructure. For Communication Providers, the objective should therefore be simple: not just to connect successfully, but to remain operationally ready when real switching activity begins.
7 common TOTSCo migration
1. Treating TOTSCo Migration as an API-Only Project
The first mistake is assuming migration ends when an API can send and receive a valid message. Switching messages may trigger actions across CRM, provisioning, order management, billing, and support systems. A message can be technically accepted while the downstream process still fails.
💡How to avoid it: Map the end-to-end journey before development begins. For each message or status, define which system handles it, what action follows, what data is stored, who owns exceptions,, and what the customer should be told. That turns migration from a connectivity exercise into an operational switching service.
2. Choosing Direct Connection or a MAP Too Late
TOTSCo allows a provider to connect directly to the Hub or work with a MAP. For a Full Management MAP, TOTSCo says the provider onboards with that MAP and the MAP manages the Hub connection.That choice affects architecture, testing, support and long-term operating effort. Changing it after development begins can create duplicated work.
💡How to avoid it: Decide early who will own Hub connectivity, monitoring, technical failures, testing, future specification changes and day-to-day operation.
3. Misconfiguring Brands, RCPIDs and Onboarding Data
Small onboarding errors can become large migration delays. TOTSCo’s Business Switching User Guide covers account setup, brands, key contacts, billing and reports. Existing residential Hub users can add a business brand through the Account Management Portal rather than start again as a completely new Hub user. Problems arise when legal entities, customer-facing brands, RCPIDs and internal records do not align.
💡How to avoid it: Maintain one controlled onboarding record containing company details, brands, RCPIDs, contacts and the systems using each identifier. Validate it across technical, commercial and operations teams before testing.
4. Testing Only the Happy Path
A successful test transaction is not the same as production readiness. TOTSCo says business switching usually involves three testing stages depending on the connection route, covering simulator, integration and production implementation testing. The bigger risk is testing only clean data and successful outcomes.
💡How to avoid it: Include realistic scenarios such as incomplete customer information, match failures, invalid messages, downstream outages, delivery failures, duplicates and recovery after temporary failures. For every failure, define both the technical response and the operational owner.
5. Handling Hub Validation and Responses Incorrectly
This is one of the most important technical mistakes. TOTSCo’s OTS lessons highlight issues around responding to the Hub, validating messages before responding, rejecting messages and handling delivery failures. It explains that the Hub validates the message envelope, while recipients should avoid unnecessary over-validation before acceptance.
💡How to avoid it: Define response behaviour against the current TOTSCo API and delivery specifications. Teams should distinguish between:
- Business validation failure
- Message delivery failure
- Successful delivery followed by downstream processing failure
Each needs a different response and remediation path.
6. Ignoring Matching Quality and Operational Visibility
A healthy Hub connection does not guarantee a healthy switching journey. Matching depends on accurate customer and service data. Inconsistent records can create failures, manual investigation and customer friction. TOTSCo’s residential lessons learned specifically identify matching performance as an area where CPs and MAPs can improve outcomes.
💡How to avoid it: Track match success, rejection reasons, delivery failures, exceptions, processing time and manual intervention not only uptime. These measures reveal whether the switching service is working, not simply whether the connection is online.
7. Treating Go-Live as the End of Migration
Passing testing and entering production is a milestone, not the finish line. TOTSCo continues to publish technical documentation, bulletins and platform updates. A live service therefore needs clear ownership after launch.
💡How to avoid it: Assign responsibility for monitoring, incidents, credentials or certificates where applicable, regression testing, platform changes and support escalation.
A CP running directly must retain the skills to maintain its integration. A provider using a managed service should be clear about which responsibilities sit with the MAP and which remain with the CP. For a deeper comparison of connection routes, see TOTSCo Hub vs. MESH/CSF guide.
A simple TOTSCo migration readiness check
Before going live, every Communication Provider (CP) should be able to answer five basic questions:
- Who owns the switching process end to end?
- Are brands, RCPIDs and system records fully aligned?
- Have both successful and failure journeys been tested?
- Who monitors matching, messaging and delivery exceptions? 5
- Who owns future TOTSCo changes and updates?
If any of these answers are unclear, the integration may be technically complete but still carry operational risk.
Ofcom’s One Touch Switch experience highlights why these matters. One year after OTS launched, 1.6 million people had used the process, and more than 300 providers were offering it. While business switching has separate requirements, the underlying lesson remains the same: switching needs to work consistently across providers, systems and customer journeys.
TOTSCo readiness is not just about connecting to the Hub. It is about having the people, processes, testing and monitoring in place to operate reliably after go-live.
TOTSCo Migration Checklist
Before moving into live switching, Communication Providers (CPs) should confirm that technical integration is backed by clear operational ownership, monitoring, testing, and recovery processes.
Pre-Go-Live Checklist
- Connection model confirmed: Direct connection or MAP responsibilities are clearly defined, documented, and understood by all relevant teams.
- Brands and RCPIDs validated: Customer-facing brands, RCPIDs, identifiers, and internal system records are accurate and aligned.
- Customer and service data validated: Customer, service, address, and other relevant records have been checked for completeness, accuracy, and consistency across systems.
- End-to-end journeys tested: Successful switching journeys, failures, exceptions, retries, and edge cases have been tested across the complete transaction flow.
- Exception ownership assigned: Teams know who investigates, resolves, and escalates failed or rejected transactions.
- Monitoring and alerting enabled: Teams can track message status, matching outcomes, delivery failures, processing delays, and exceptions in real time.
- Recovery procedures tested: Clear procedures are in place for temporary outages, failed transactions, retries, and interrupted switching journeys.
- Support and escalation model established: Internal teams, operational owners, and any MAP have clearly defined responsibilities and escalation paths.
- Post-go-live ownership assigned: A named owner is responsible for TOTSCo changes, regression testing, issue management, and ongoing platform maintenance.
Where a Full Management MAP Can Reduce Migration Complexity
For some Communication Providers (CPs), the challenge is not simply connected to TOTSCo. It is managing the technical and operational responsibilities that come with running the switch service. A Full Management MAP can help reduce this complexity by managing the Hub connection and taking on agreed technical and operational responsibilities. TOTSCo also distinguishes Full Management MAP onboarding from direct onboarding.The value should therefore go beyond “getting connected.”
The real objective is to help CPs move from a solution that works in testing to a switching service that can be monitored, supported and maintained reliably in live operation.
This can provide:
- Clearer ownership across technical and operational activities
- Lower operational overhead for internal teams
- Reduced dependency on specialist switching infrastructure expertise
- Better ongoing support and monitoring after go-live.
Ultimately, the goal is not just to complete the migration, but to make the switching capability operationally sustainable once it is live.
Warning Signs Your TOTSCo Migration Is Not Ready
Technical progress does not always mean operational readiness. Before go-live, certain unanswered questions can indicate that risks still remain. Consider the migration not fully ready if:
- No single team owns the switching journey end to end.
- Teams are unclear about who handles failed or rejected transactions.
- Exception scenarios have not been tested realistically.
- Monitoring focuses only on system availability rather than transaction outcomes.
- Brands, RCPIDs or service records still require manual reconciliation.
- Recovery procedures have been documented but not tested.
- Responsibilities between the CP and MAP are unclear.
- There is no defined process for managing future TOTSCo changes.
These warning signs do not necessarily mean the integration needs to stop. They indicate where additional preparation may be required before the service moves into live operation.
Final thoughts
TOTSCo migration is not complete the moment a Communication Provider can successfully exchange messages with the Hub. A working connection proves the technology functions it does not prove the switching operation is ready to serve real customers.
Reliable live switching depends on more than connectivity: accurate onboarding data, realistic failure testing, ongoing transaction monitoring, and clearly defined exception ownership. None of this happens by accident once a service goes live it has to be designed in from the start.
The strongest approach treats operational readiness as a first-class requirement from day one, not a final step bolted on after technical integration. The goal is simple: connect successfully, operate reliably, and stay ready to adapt as TOTSCo’s requirements evolve.