Your SASE Architecture Is Live. Your MPLS Contracts Are Still Billing.
When I was Head of Telecommunications at Simon Property Group, we ran an MPLS network that touched every property in the portfolio. The architecture made sense for the time: predictable performance, contractual SLAs, a known vendor footprint. The invoices reflected that — and so did the multi-year terms.
When the industry began moving toward SD-WAN and then SASE, the architectural conversations were the right ones. Distributed enforcement, cloud-aware routing, modern security, smaller appliances at every site, simpler operations. Engineers building smarter networks. What was almost never on the agenda — and what I now see as one of the most preventable categories of unauthorized charges in the enterprise — was the parallel project nobody had assigned to anyone: shutting down the carrier contracts the new architecture was replacing.
Two architectures live in your environment during a SASE migration. One is being built. One is supposed to be retired. The first has a project plan, a steering committee, and a budget. The second often has nothing, because the operational team has already moved on. The carrier has not.
Why this gap is structural, not careless
I want to be direct about something. The reason MPLS circuits keep billing after traffic moves to SASE is not that enterprise IT teams are sloppy. It is that the work of cutting a carrier contract is structurally different from the work of building a new network — and most organizations do not staff for both at the same time.
Architecture migration is engineering. SD-WAN appliances at sites. SSE policy in the cloud. Identity integration. Telemetry. The team executing that work is rightly focused on outcomes the business will see — application performance, security posture, time to provision a new site.
Decommissioning a carrier contract is commercial and operational discipline. It involves reading the original master service agreement, understanding the disconnect notification requirements, generating the trigger, validating the carrier acknowledged it, watching the next three invoices to confirm the line item came off, and disputing it through the contractual window if it did not. That work has no engineering glamour. It does not appear on a steering-committee dashboard. And in most organizations I have seen, it has no assigned owner.
The carrier sees this clearly. They are not malicious about it. But they are also not going to volunteer that you are paying for a circuit that has carried near-zero traffic for six months. Your contract requires you to ask. If nobody on your side asks, the bill continues to arrive at full contract rate, on time, every cycle.
What is actually happening on the invoice
The pattern looks the same across the multi-site enterprises we work with. Traffic shifts to the SASE underlay over a few weeks. The MPLS circuit’s utilization drops to near zero. The bill keeps arriving at the original rate. Auto-renewal language ticks toward another twelve, twenty-four, or thirty-six months. At some point — usually when somebody finally looks at the invoice — a “just in case” backup justification gets created retroactively to keep the circuit alive. The original reason for the contract is gone. The line item is not.
I have seen this at every multi-site enterprise we have engaged with. It is not an exception. It is the default outcome of a SASE migration plan that does not have a paired decommission workstream.
Four places this fails
There are four specific operational gaps that turn an MPLS-to-SASE migration into a recurring billing exposure. Any one of them is enough to keep a circuit billing for years past its useful life.
The first is the assumption that traffic moving off a circuit is the same thing as a disconnect order. It is not. A routing change is a network event. A disconnection is a contractual event. They have to be triggered separately. The carrier’s billing system does not watch your traffic — it watches its own contract record.
The second is that the decommission is not anyone’s project line item. The SD-WAN deployment plan has owners for site activation, hardware shipping, policy configuration. The MPLS exit plan, in most organizations I have seen, does not exist as a document. There is no equivalent owner for “circuit X scheduled for retirement on date Y, billing-confirmed by date Z.”
The third is auto-renewal. MPLS contracts signed three to five years ago commonly contain auto-renewal language with notice windows ranging from sixty to one hundred eighty days before the term end. While the engineering team is busy with the new architecture, the renewal calendar continues running. A circuit you intended to retire in March 2026 can lock you in through 2029 if the notice window passed in December 2025 and nobody triggered it.
The fourth is the difference between disconnect requested and disconnect billing-confirmed. A disconnect is not complete when the ticket is filed. It is not complete when the carrier acknowledges receipt. It is complete when the next invoice no longer contains the charge — and when any final-invoice items, including proration and any contractual termination charges, match the terms of the original agreement. Many organizations declare victory at step one and never validate step three.
What the proof looks like
In a thirty-one-month engagement with a multi-brand retail portfolio operating across hundreds of locations, BearGuard — Bearstone’s governance process — identified between $1.85 million and $2.1 million in unauthorized charges across two carriers. Eighty-seven percent of that was credited back to the client. The portfolio’s approved telecom budget dropped 16.9 percent from FY24 to FY25 — not because services were cut, but because charges that should never have appeared on the invoice were systematically removed.
A meaningful share of that exposure had the same operational signature as the SASE-to-MPLS gap: services the business no longer consumed, on architectures or locations the business had moved past, continuing to bill because nobody on the buyer’s side had triggered the contractual close.
The fix is operational, not heroic
A SASE migration plan needs a paired carrier-contract exit workstream. Not as an afterthought. Not as a cleanup phase at the end. As a required, parallel project with the same level of ownership as the architecture work itself.
In practical terms, that means a few specific things. Every circuit being replaced needs a contractual trigger date — the date by which the disconnect notice must be filed to align with the carrier’s notice window and the architecture cutover. Every trigger date needs a single named owner accountable for filing the notice and confirming the carrier acknowledged it. Every disconnect needs a billing-confirmed close-out, which is a line-by-line check of the invoice for the three cycles following the requested disconnect date. Any charge that appears post-disconnect needs to be disputed inside the contractual dispute window, which is often shorter than people assume.
This is not complicated work. It is systematic work. The reason it does not happen in most organizations is not that nobody can do it — it is that nobody owns it.
If your organization is in the middle of a SASE migration, or finished one in the last twelve to twenty-four months, the question to ask is not whether you have unauthorized MPLS charges still billing. The question is who, today, is accountable for confirming you do not.
