MPLS is rarely replaced by a single technical decision. In established site networks, routing, Internet breakout, security, name resolution, voice services, provider contracts and operating processes are interrelated. If you only replace the pipe, you shift risks. Those who make the dependencies visible first, on the other hand, can modernize site by location.
The goal is not to "shut down MPLS at all costs". The goal is a traceable access path that makes applications accessible according to identity, location, device and risk – with less reliance on central backhauls.
1. Divide locations into resilient classes
Migration planning does not start with the largest branch, but with recurring location patterns. Typical classes are:
- small offices with standard SaaS and few local services,
- Stores with cash registers, printers or agentless devices,
- Production and logistics sites with OT-related dependencies,
- larger hubs with local infrastructure,
- temporary locations and pop-up areas,
- Locations with regulatory or particularly high availability requirements.
For each class, applications, user numbers, availability target, current lines, local security components and necessary exceptions are recorded. This creates a rollout logic instead of a collection of individual special projects.
2. Understand traffic routes before the target architecture
The crucial question is: Which traffic actually has to go where?
Internet and SaaS traffic, private applications, DNS, authentication, management access, printing and voice services, and non-user-bound systems are to be examined. This also includes supposedly small things such as IP allowlisting, fixed source addresses or hard-coded targets.
Zscaler Branch Connector can route site traffic to ZIA and ZPA and is centrally managed through the Zscaler portal. However, which topology and forwarding logic is suitable depends on the specific location profile. Product function therefore does not replace architecture testing.
3. Define the target image per application
Not every data stream needs the same path. SaaS and Internet can be managed directly via a controlled security service. Private applications need a defined ZPA path. Agentless devices need a different mapping than managed user devices. For remaining legacy dependencies, a transition path may be necessary at times.
For each relevant application path, the following should be determined:
- professional and technical owner,
- desired target path,
- Identity and device context,
- security checks,
- Availability requirement,
- Test case and fallback option,
- Date for the dismantling of the old path.
This prevents "temporary" exceptions from remaining permanently part of the architecture.
Micro-segmentation as an added value of branch transformation
In many classic site architectures, micro-segmentation is to be achieved via additional VLANs, firewall zones or access lists. The goal is correct: a device should not automatically reach all other systems in the site network. However, the approach is often not implemented to the desired granularity because each new segment expands routing, rule maintenance, documentation and troubleshooting.
Zscaler describes an architecture for Branch Connector that enables east-west segmentation and can limit lateral movement. The fundamental difference is that access is geared to the required applications and destinations, not to the blanket accessibility of an entire network.
Additional granularity is created when devices or sources are treated as individual host addresses in the site design. A single IPv4 address corresponds to a '/32' prefix. For example, instead of considering an entire '/24' as a common policy unit, a '/32' source can be assigned to a narrowly defined target relationship. Micro-segmentation does not necessarily become a separate infrastructure project, but can be implemented as an architectural gain of branch modernization.
This is not an automatism and not a blanket "free function". The following are required:
- Clear and robust device-to-IP mapping,
- a controlled DHCP or addressing concept,
- defined target applications, ports and protocols,
- suitable ZIA, ZPA and branch policies,
- a conscious handling of DNS, updates and shared infrastructure,
- negative tests for unauthorized cross-communication,
- Monitoring, owner and review date for exceptions.
Whether devices in the specific Zscaler branch design are modeled as '/32' by default or deliberately must be checked against platform status, address assignment and target architecture. The reliable claim is therefore: Branch Connector creates the technical basis for finer east-west segmentation; a host-accurate '/32' policy model can turn this into true micro-segmentation in the site.
4. Pilot with a representative location
The most convenient location is rarely the best pilot. A location that contains typical applications and at least one real difficulty, but remains controllable, is suitable.
The pilot not only checks accessibility. It also measures:
- What to do in the event of a failure of an access route,
- Time to fault localization,
- Transparency in monitoring,
- Dealing with unmanaged devices,
- Application performance,
- Helpdesk and escalation processes,
- Repeatability of the configuration.
Zscaler documents both configuration steps and monitoring views for Branch Connector. This information is a technical basis; Acceptance criteria and business handover remain project-specific tasks.
5. Parallel operation with a clear exit rule
Limited parallel operation can reduce risks. But he needs a clear exit rule: Which tests must be passed? Which application is still allowed to run over the old path? Who decides on the shutdown? When is an exception re-evaluated?
Without these rules, there are double costs and unclear responsibilities. With them, parallel operation becomes a controlled migration instrument.
6. Don't confuse costs with provider prices
A robust business case separates current and future cost blocks. This includes lines, on-premises appliances, licenses, operations, disruptions, rollout, and one-time migration. Quotation and license prices must be derived from current, customer-specific documents.
The SourcingBlox Calculator for MPLS and Zero Trust Branch therefore uses only changeable assumptions. It does not provide a price assertion, but makes visible which inputs determine one's own profitability analysis.
7. Standardize operation before rollout
Before a larger wave, there must be roles, monitoring, fault acceptance, escalation, change process and documentation. A technical solution is only scalable if another location can be included and operated according to the same pattern.
SourcingBlox combines discovery, site classification, Zscaler architecture, pilot, and business handover. The result is not a blanket shutdown promise, but a prioritized migration sequence with comprehensible decisions.
A concrete example: the branch with three types of traffic
Let's take a branch with office workstations, POS systems and building technology. Today, almost everything runs via MPLS to the data center. In the target image, the paths are considered separately.
Employees' browser and SaaS traffic can be routed via local internet access and ZIA. Access to private applications follows a defined ZPA path. The cash register and building technology will have their own, narrowly defined communication relationships. DNS, time synchronization, updates and central management systems are explicitly included.
The migration does not occur as a common switching moment. First, the new connectivity is set up and monitored. After that, selected traffic classes change with documented testing and fallback route. Only when the representative business processes have been approved can the old path be omitted.
This pattern makes two things visible: First, "the location" is not a single connection. Second, the benefits come from the combination of more direct access, clearer segmentation, and repeatable operation – not just a cheaper line.
What documents should be available before a decision is made
A reliable decision-making status consists of at least:
- Site inventory with classes and priorities,
- Application and data flow matrix,
- Target topology per site class,
- documented legacy dependencies,
- Pilot design with acceptance and fallback criteria,
- rollout waves and change windows,
- Operational and escalation model,
- Cost model with source and date of each acceptance.
The computer is only one component. He can show which variables are economically decisive. It cannot judge whether a production system needs a fixed source address, whether a carrier is achieving the required availability or whether an application is working correctly in the target path.
Measuring points after the first rollout wave
After the first wave, architectural and economic assumptions were to be reviewed. Relevant measurement points include rollout duration per site, number of unplanned exceptions, fault volume, time to diagnosis, application quality and legacy components that have actually been omitted.
Deviations are not proof of a failed concept. They provide the data to improve location classes, templates, and operations before the next wave.