TL;DR: Providers change CALEA compliance vendors for ordinary business reasons: support that never answers, a vendor that treats compliance as a side offering, a partner lost in an acquisition, or costs that stopped making sense. The switch itself is manageable, but one rule governs the whole project: your obligations never pause. Intercept capability, your System Security and Integrity plan, and your ability to respond to legal demands must all stay live through every day of the transition. The way to achieve that is overlap, not handoff: stand the new provider up, test it, update your filings, and only then wind the old one down.
Why Providers Switch
No one changes compliance vendors for fun. The reasons that actually drive a switch tend to look like this:
- Support has thinned out. The order that arrives after hours reaches a voicemail box, or the one person who understood your setup left the vendor and took the knowledge along.
- Compliance is the vendor's side business. The product gets maintained, but the expertise behind it does not, and you can feel it when you ask a hard question.
- The vendor changed underneath you. An acquisition, a pivot, or an exit from the lawful intercept business can leave your compliance program attached to a company that no longer prioritizes it.
- Your network outgrew the solution. New services, new technologies, or growth into new markets can push past what the current vendor can support.
- The economics stopped working. Renewal pricing, surprise fees, or paying for capability that never gets exercised.
Any one of these is a legitimate reason to look around. What stops many providers is not the reason but the fear: what breaks while we are mid-switch?
The One Rule: Your Obligations Never Pause
Here is the fact that shapes the entire project. CALEA's capability requirements attach to you, the carrier, not to your vendor. The duty to maintain interception capability, to keep your System Security and Integrity plan accurate and on file with the FCC, and to respond to lawful demands does not acknowledge vendor transitions. If a court order arrives the week between providers, "we were switching vendors" is not a response anyone will accept.
That is why the central design principle of a good transition is overlap. The old solution stays operational until the new one is proven, in production, end to end. A gap of even a few days is the one outcome the whole plan exists to prevent.
The Transition, Step by Step
1. Review your current contract before you signal anything. Check the termination terms: notice periods, end-of-term dates, early termination costs, and what the vendor is obligated to do during wind-down. Time your move around those terms rather than discovering them afterward.
2. Vet the new provider against the questions that matter. The vetting for a replacement is the same as for a first provider, with one addition: ask specifically about transitions. How many has the provider run? From which platforms? What does its onboarding look like when there is an incumbent to coordinate with? A genuine specialist will describe a process. A box seller will describe a shipment.
3. Map what the new provider must cover. Every network type you operate, every service that creates an obligation, and the standard each one must be delivered against. A switch is also the natural moment to catch anything your old solution quietly stopped covering as your network evolved, because conformance to the applicable standards is what safe harbor rests on.
4. Stand up the new solution in parallel. Deploy, provision, and integrate while the old solution remains live. Nothing on the old side gets decommissioned yet. This is the overlap that protects you, and it is worth the weeks of double coverage it requires.
5. Test before you rely. A capability that has never been exercised is a guess. Verify provisioning, delivery, and output on the new solution under realistic conditions before any cutover. Your transition plan should treat a successful test, not an installation date, as the milestone that permits cutover.
6. Update your SSI plan and contacts. Your SSI plan on file with the FCC names your points of contact for lawful process, and a vendor change almost always changes them. File the update as part of the cutover, not as a cleanup task afterward, so the agency that reaches out next week reaches the right people. Update your internal runbooks and any law enforcement relationships that route through the old provider at the same time.
7. Cut over, then wind down deliberately. Move live responsibility to the new provider on a planned date, with both vendors aware of the plan. Confirm any in-flight matters are handed off cleanly. Then decommission the old solution, close out access the old vendor held, and get written confirmation of data handling and destruction where that applies.
What a Concrete Switch Looks Like
Picture a regional broadband provider whose compliance vendor was acquired, after which support response times stretched from hours to weeks. It signs with a new provider in March with a contract end date of June 30. April is deployment and integration, run in parallel. May is testing, including verified delivery on each network type. In early June the SSI plan update is filed, contacts are changed, and cutover happens with three weeks of contract left as margin. On July 1 the old contract lapses against a solution that is already retired. At no point in those four months was the provider unable to respond to an order.
That is the shape to aim for: the contract calendar provides the deadline, and the overlap absorbs the risk.
A Quick Self-Check
- Do you know your current contract's notice period and end date today?
- If an order arrived mid-transition, is it unambiguous which provider handles it?
- Is a successful end-to-end test, rather than a date, the condition for your cutover?
- Does your transition plan include the SSI plan update and contact changes, scheduled, with an owner?
If any answer is no, that is the part of the plan to finish before you give notice.
Frequently Asked Questions
How long does switching CALEA providers take? Plan in months, not weeks. Deployment, parallel operation, testing, and filing updates each take real time, and the overlap period is what keeps the switch safe. The exact timeline depends on your network's complexity and your current contract's terms.
Is there a compliance gap while we switch? There should never be one. The entire transition is designed around overlap: the old solution stays live until the new one is deployed, tested, and proven. Your obligations continue uninterrupted, so your coverage must too.
Do we need to tell the FCC we changed providers? Your System Security and Integrity plan on file must stay accurate, and a vendor change typically changes your designated points of contact, so an updated filing is part of a proper transition.
What should we ask a replacement provider that we would not ask a first one? Ask about transitions specifically: how many they have run, from which platforms, and how they coordinate with an incumbent. Experience with the switch itself is what keeps the overlap period short and clean.
Make the Switch Without the Gap
Changing compliance vendors is a project with a known shape: overlap, test, update, cut over. Subsentio, the largest CALEA Trusted Third Party in the United States, has brought providers over from other platforms and runs the transition as a managed project, with the old coverage intact until the new coverage is proven. Talk to us about switching and get a transition plan with no gap in it.
About Subsentio: Subsentio is the largest CALEA Trusted Third Party in the United States, a 100% employee-owned company that helps communications providers meet their law enforcement assistance obligations. It determines CALEA coverage, implements, tests, and operates lawful intercept solutions, supports the lawful intercept component of clients’ System Security and Integrity plans, and reviews legal demands and manages records production for carriers, broadband providers, MVNOs, and VoIP operators of every size.
