The problem
How to replace an MPLS network in phases is a routing and operations problem, not a shopping problem. MPLS gave you any-to-any paths, predictable latency and one vendor to call. It also backhauls cloud and SaaS traffic to a hub, makes changes slow, and ties you to circuit terms that outlive the need. The goal is not to hate MPLS. The goal is to remove it without losing the properties your business depends on.
The hard part is the hidden dependency list. A site may look simple until you find a voice gateway with a static route, a firewall rule tied to a /24 that overlaps another region, a warehouse scanner that only talks to one IP, or a DNS forwarder that lives in the old hub. You also have circuit notice periods, diversity claims and equipment return rules. Miss one and a clean cutover turns into a long night.
A phased replacement keeps two paths alive while you move traffic. That costs more during the overlap and asks for discipline. It is still cheaper than a big bang cutover that fails at the busiest site. Treat the old MPLS as a fallback path until each site and each critical flow has passed its own soak period.
What a good solution looks like
The target is a WAN you can change one site at a time. Most companies end with internet underlay at branches plus private connections where latency, bandwidth or compliance demand it. On top sits an encrypted overlay, with routing policy and security policy managed centrally. Cloud traffic enters through a cloud on-ramp or a private interconnect, and local internet breakout handles SaaS. Keep the design boring: documented site profiles, clear default routes and a named owner for routing.
A good solution has per-site profiles: small office, warehouse, call center, plant, data center. Each profile fixes the circuit type, router model, power and out-of-band access, firewall placement, voice handling and failover behavior. Do not design every site as a special case. If a site needs a special case, write it down and give it a sunset date.
Routing should be simple enough to debug at 2 a.m. Use a dynamic routing protocol between sites where you have many paths. Use static routes for small sites with one uplink. Set route preferences so the new path wins when healthy and the MPLS path takes over when it is not. Keep NAT and firewall state in mind: failover that changes the source address can break sessions even when packets flow.
Security belongs in the design from the start. Remote staff and contractors should reach applications through identity-aware access, not flat network access. Site-to-site traffic should be segmented by function rather than by VLAN alone. Logs from every edge should land in one place with the path label, so you can tell whether a problem is the internet circuit, the overlay or the application.
How to build it
Start with a circuit and application inventory. List every site, circuit ID, contract end date, notice period, router and firewall, IP range, voice circuit and static route. Then map the top ten business flows by site: ERP, file shares, voice, video, badge system, factory control and cloud apps. Pick a pilot site that is real but not revenue critical. A back office or a small warehouse beats headquarters for the first move.
Build the new edge and overlay at the pilot. Keep the MPLS circuit connected. Bring up the new path, then move one flow at a time with route preference and firewall rules. Test failover by shutting the new path and by shutting the old one. Measure latency, jitter, packet loss and voice quality. Write a rollback card that any on-call engineer can follow. Run the pilot for two weeks of normal business, including month end if that changes traffic.
Move sites in waves grouped by region, profile and circuit provider. Pre-stage hardware, test from the local LAN, and schedule the cutover with the site lead. At cutover, change the route preference, not the whole design. Leave MPLS in place as a lower-preference path. Keep the old router powered and reachable through out-of-band access. After a soak period with no tickets tied to the new path, remove the old route and schedule circuit turn-down.
Cloud and data center links need their own order. Move default routes and central egress after branch waves prove the overlay. Then handle the unglamorous end: cancel circuits in writing before the notice deadline, return equipment, remove old BGP peers and firewall rules, and audit the final bills. Update the network diagram and the runbook the same week. A decommissioned circuit that still bills is a process failure, not a technical one.
Risks and how to manage them
The main risk is not a dead link. It is a partial failure that looks like an application problem. Asymmetric routing, MTU limits on tunnels, DNS timeouts and firewall state can make a new path pass ping but fail logins. Test real transactions, not reachability alone. Set MTU and TCP MSS explicitly on tunnel interfaces, and check that voice and video survive failover.
Contract and circuit risk is easy to ignore. Carriers install late, diversity claims can be weaker than they look, and notice periods can auto-renew. Track every circuit in a spreadsheet with owner, end date, notice date and early termination terms. Order new circuits early, but do not cancel MPLS until the new path has carried production traffic through a full billing cycle.
Operational risk comes from unclear ownership. If routing, firewall and voice are handled by different teams, someone must own the cutover plan and the rollback decision. Use a change freeze around critical business periods. Keep out-of-band access at every site, because a failed cutover may take out the very link you need to fix it. Brief the help desk so they can ask the right question when a user calls.
Define rollback triggers before the first cutover: a failed acceptance test, a voice outage, a key application that cannot complete a transaction, or a security control that cannot be enforced. Rollback should be a route change, not a rebuild. If rollback takes hours, the design is too complicated for the phase you are in.
How to measure success
Measure each wave against acceptance criteria you wrote before the pilot. Count sites cut over, flows moved, fallback events and tickets opened in the first two weeks after each cutover. Track voice quality, latency, jitter and packet loss per path. Track change lead time for a new site or a new firewall rule. A shared sheet with a weekly review is enough at the start.
Measure the old network too. How many MPLS circuits remain, what is the notice date for each, and what traffic still depends on the old hub? A site is not migrated while its backup or voice path still relies on MPLS. Add a simple test to the runbook that proves the new path works with the old circuit disconnected.
After the last wave, run a closure review. Confirm that circuits are canceled, equipment is returned, routes are removed, monitoring alerts point at the new paths and the disaster recovery plan names the new underlays. Update the asset inventory and the contract calendar. Then watch the first month of steady state for surprise tickets and path flaps.
If you need a second opinion on the design before committing to a wave plan, the Expert architecture session from Cloudverg is $450 one-time and gives you 90 minutes with a senior architect plus a written summary. It is one option among others; a good systems integrator or your own network team can do the same work.
Frequently asked questions
How long does replacing MPLS take?
It depends on circuit lead times and how many sites you have. A pilot and first wave can run in a few weeks if hardware is ready. The full replacement often follows your contract notice dates, because canceling early can cost more than running both paths for a while.
Can MPLS and the new network run at the same time?
Yes, and they should during the transition. Keep MPLS as a lower-preference path, move one flow at a time, and remove it only after a soak period. This dual-run period is where you catch routing, DNS and voice problems without taking the site down.
Which sites should move first?
Start with a real but low-risk site that uses the same applications as the rest of the company. Avoid headquarters and your busiest call center for the pilot. Pick a site where staff can tolerate a short maintenance window and where you can get hands on the equipment.