Moving to SASE Without Downtime: A Phased Cutover Plan
Moving to SASE Without Downtime: A Phased Cutover Plan
Last updated: 9 July 2026
The question in the room was framed as “weekend or eight weeks.” That was already the wrong question. Nobody in an IT steering meeting should be choosing between a single risky weekend and an arbitrary number of weeks picked because it sounded safe. The actual question is which branch goes first, and why.
Why a single weekend cutover was even on the table
A 32-branch non-banking lender, headquartered in Ahmedabad, runs vehicle and small-business loans across Gujarat, Rajasthan, and pockets of Madhya Pradesh. Head office sits on MPLS to every branch, a Fortinet stack at the data centre, Sophos boxes at the newer branches, and one lonely Cisco ASA that arrived with an acquisition three years ago and nobody had scheduled time to remove. Underwriters working from home connect through a VPN concentrator that was sized for a much smaller remote-work population.
The MPLS renewal notice landed in early 2026 with a 34% price increase and a 90-day window before auto-renewal locked the old rate in for another three years. That deadline is what put “just do it in one weekend” on the table. A consultant had quoted a single cutover window, branch sockets pre-shipped, everything flipped Friday night to Monday morning. It read clean on a slide. It assumed every branch’s broadband would behave the same way at the same time, and none of them ever do.
The branch that almost broke the schedule
My first draft of the plan grouped branches by loan volume, biggest first, because that is where the cost savings show up fastest on a spreadsheet. Three calls later, that ordering fell apart. Two branches in smaller Rajasthan towns, low volume on paper, sat on a single broadband line each with no secondary circuit and a courier-level lead time for a new Cato Socket to physically arrive. Sequencing them early, purely because they were “next” alphabetically in someone’s spreadsheet, would have meant a socket sitting in a courier depot while a branch ran on nothing.
So the order changed. Branches with a second internet circuit or fibre already on site went first, regardless of loan volume. The two single-link towns moved to the back of the queue, with an interim step: a second broadband connection ordered before the Cato Socket, not after. That is a small change on paper and the difference between a rollout that holds and one that produces an angry branch manager on day one.
Moving to SASE without downtime: the phased plan we actually used
Cato’s own migration guidance breaks a rollout into four phases: discovery, a pilot of 30 to 60 days, expansion by site and user group, and optimisation once traffic is actually moving. That is not marketing language, it is the same shape every vendor-neutral migration writeup lands on, because the failure mode it avoids is universal: teams that treat SASE as a hardware swap instead of a policy migration hit outages, and teams that phase the work by identity and geography keep production running.
Discovery took three weeks: every branch’s current circuit type, every application each underwriter touches, and which two systems still authenticate against an on-prem directory that was never going to move on day one. The pilot ran at four branches with dual internet links and low political sensitivity if something wobbled, six weeks, VPN and Cato Client running side by side so nobody lost access if the new path had a bad day. Rollout followed in batches of four to six branches, sequenced by circuit redundancy first and loan volume second, with the legacy MPLS and firewall stack staying live at every branch until two full weeks of clean logs confirmed the cutover.
| Approach | Typical timeline | What happens if one branch has a bad week |
|---|---|---|
| Single weekend, all branches | One weekend, all-or-nothing | Every branch is affected at once; rollback means reverting 32 sites simultaneously |
| Phased by loan volume | 10-14 weeks | High-volume branches move first, but low-connectivity branches can stall the schedule mid-way |
| Phased by circuit redundancy, then volume | 12-16 weeks | One branch’s delay does not touch the others; rollback is a single-site revert to MPLS/VPN |
We have seen this exact sequencing mistake at other Indian mid-market rollouts: a plan built around headcount or revenue, with connectivity treated as a footnote. It is rarely the footnote once the calendar actually starts moving.
What the parallel-running month actually looked like
For about five weeks, every migrated branch had two paths that both worked: the old MPLS circuit and firewall, and the new Cato Socket handling the same traffic. That sounds wasteful, and it is not free, but it is the part that makes the schedule survivable. When a branch manager in Bhilwara called to say the new connection felt slower during the first two days, the answer was a DNS and routing check, not a 2am emergency, because the old path was still sitting there as a fallback the whole time.
Split-brain configuration was the one place attention mattered most. A branch is only fully migrated when every device on it, not just the primary router, points at the new path. Two branches had a spare access point still configured against the old firewall’s guest network weeks after the “official” cutover date, invisible until someone ran a proper device sweep. That sweep is now a checklist item on every future branch, not an afterthought.
The audit trail question, which is what the DPDP stake above is actually about, resolved cleanly once Cato’s console centralised logging across every migrated branch into one place instead of 32 separate firewall logs in 32 separate formats. A compliance reviewer asking which system handled a specific customer’s loan application data during the migration window gets one query, not a branch-by-branch archaeology project. That consistency is the kind of evidence CERT-In expects an organisation to produce quickly if an incident is ever reportable, and it lines up with the access-logging expectations in ISO/IEC 27001.
Sixteen weeks later
All 32 branches sit on Cato now. The Cisco ASA that arrived with the acquisition is finally gone, decommissioned in week eleven once the last application behind it moved to a proper gateway. The MPLS contract was allowed to lapse rather than auto-renew, and the 34% increase never got paid. Matlab, the thing everyone actually remembers from the project is not the platform, achha, it is that nobody in Bhilwara or Sikar noticed the week their branch changed underneath them. That was the actual goal, pakka, not a faster network, a network nobody had to think about.
Key takeaways
- Sequence a phased SASE rollout by connectivity redundancy first, loan volume or headcount second. The smallest branch with the weakest last-mile link is the one that breaks a schedule built around revenue alone.
- Run the legacy stack in parallel until each site clears two weeks of clean logs. Do not schedule a hard decommission date before that evidence exists.
- A 30 to 60 day pilot at low-risk, dual-connectivity sites surfaces the real problems (stale device configs, split-brain routing) before they hit a branch that cannot absorb an outage.
- Centralised logging across every migrated site is what actually answers a DPDP or CERT-In audit question during a migration window, not 32 separate firewall logs.
- Let the MPLS contract lapse on your terms once the new path is proven, instead of negotiating from a position where the auto-renewal clock is the one setting your deadline.
Talk to us about sequencing your branch rollout
Frequently asked questions
Can you really migrate to SASE without any downtime at all?
For planned, phased work, yes. Every migrated site runs the old and new paths in parallel until logs confirm the new one is clean, so a single branch’s bad week never becomes a company-wide outage.
How long should a phased rollout take for a 30-branch company?
Twelve to sixteen weeks is realistic once discovery, a six-week pilot, and staged rollout in batches of four to six branches are accounted for. Rushing this to hit an MPLS renewal date is how the connectivity gaps get missed.
Do we have to keep the old firewalls running during the migration?
Yes, at each branch, until two full weeks of clean logs confirm the new path is handling traffic correctly. Decommissioning on a fixed date instead of on evidence is the most common way these projects create an outage.
What happens to branches with only one internet connection?
They should move later in the sequence, and ideally get a second circuit ordered before the new hardware arrives. A single-link branch with no fallback is the highest-risk site in any rollout, regardless of its size or revenue.
Does a phased migration cost more than a single cutover weekend?
It costs more in project-management hours and a few weeks of running two networks in parallel. It costs far less than an outage across every branch at once, and less than renegotiating an MPLS contract from a position where the deadline is the only thing driving the schedule.
Get my free quote for a branch rollout sequencing review
We have run a version of this planning meeting with several Indian companies now, always circling the same wrong question: weekend or weeks. Cato Networks SASE in India is the platform we sequence these rollouts on, one branch group at a time, with the old network staying alive until the new one has earned its place.
Related reading: what SASE actually means for an Indian business buyer, when to switch from MPLS to SD-WAN, and when not to, why the VPN keeps falling over and what ZTNA fixes, and a Bengaluru SaaS company’s Cato-versus-Fortinet bake-off.
Book a discovery call before your next renewal deadline
Free branch rollout sequencing review, no card and no contract. We have done this for 200+ Indian businesses. Reach us on WhatsApp at +91 91375 93228 during 10 to 7 IST if you would rather just ask a question first.
P.S. Karthik here. I came into that steering meeting with a plan sorted by loan volume, biggest branch first, because that is where a spreadsheet says the savings show up fastest. Two phone calls about a broadband line in a small Rajasthan town changed my mind. Sequence by what could actually go wrong at each site, then let the revenue numbers pick the order within that.
