How to Migrate Critical Networks Without Downtime
Key Takeaways
Introduction
Every network reaches a point where it has to be replaced. Whether the reason be aging equipment, a jump from 10-gig to 25-gig capacity, or a consolidation after a merger, for most organizations, that means scheduling a maintenance window and accepting a few hours of downtime. But some organizations can't accept any. A Level 1 trauma center doesn't get to tell the ER that the network will be back at 1 a.m.
That's the problem Mitch Martinez, Executive Vice President at Derive Technologies, set out to unpack in our conversation. The core question, in his words: "How do you replace the network underneath an organization that can't afford a single minute of downtime?"
The answer, he's quick to note, is straightforward: but it isn't simple.
A Network Is a Road, Not a Wire
Mitch's first reframe is conceptual. A network isn't the point; it's the transport layer. "You don't build a network for the sake of building a network," he said. "You build a network for the sake of the applications that are running on it." Voice, email, EHR access, imaging, those applications are the reason the network exists, and they're what actually has to stay up.
He describes the network itself as an electronic road, with turns, exit ramps, and endpoints. Replacing it without downtime isn't a matter of swapping a wire. It's building an entirely new road alongside the old one, connecting the two, and moving traffic across without anyone noticing the switch.
Resiliency Means Duplication of Everything
The foundation of a zero-downtime cutover is resiliency, and resiliency, at its most fundamental, means building two of everything: two routes, two entrances, two exits. Organizations that genuinely can't go dark build this redundancy in from the start; duplicated routers, duplicated communication lines, and separate power and physical paths, so a single failure never takes down the whole system.
For dedicated infrastructure, it's relatively clean to stand up a parallel line on a separate route with separate power. But redundancy must exist at both ends. A resilient path between two endpoints means nothing if the endpoints themselves aren't resilient.
Automated Failover and the Role of BGP
Duplication only prevents downtime if the switch between paths is instant. That's what automated failover does: when a line or a router fails, the system senses it and shifts traffic to the next one without human intervention.
On the wide-area side, Mitch points to Border Gateway Protocol (BGP), a standard Cisco introduced roughly 25 years ago that made automated sensing and failover between routers and lines a reliable, standardized practice. It's how the resilient parts of the public internet stay up when individual paths go down, and it's the same principle Derive applies when standing up a new network that can't tolerate an outage.
WAN vs. LAN: Why It's Not Just Distance
A common misconception is that the difference between a local-area network and a wide-area network is geographic. The real distinction is subnets. Devices on the same subnet are on a LAN and communicate without leaving the router. The moment traffic has to move between subnets (say from Derive's office out to a cloud application), it needs routing, and it's crossing the WAN. Geography influences it, but the subnet is what actually defines the boundary, and that boundary determines where and how you build resiliency.
Resiliency Inside the Building
The same duplication logic applies inside the walls. On each floor of a building, an IDF (intermediate distribution frame) closet holds the switching. For true resiliency, those closets run dual switches with twice the port count needed — so if one switch fails, the other already has capacity for every device. Fiber and router paths out of those closets are duplicated too.
But cost is always something that needs to be taken into account. Not every scenario justifies full active-active redundancy. For an internal access point, you wouldn't run a second line out of a second access point — you’d place a nearby backup access point that traffic can be rerouted to if needed. And where an organization can tolerate a few minutes of interruption, an active-passive setup (a standby switch waiting to take over) is the "poor man's version" that costs far less than fully automated failover. The right level of redundancy is a business decision, not a technical default.
The Cutover Isn't Done Until the Application Layer Is
A resilient network still leaves a gap if the applications at the end of it aren't equally resilient. Derive addresses this at the storage and server layer: replicating storage to a secondary unit in real time so that if the primary fails, the data is already live on the backup and using VMware to automatically fail virtual machines over to a second set of servers holding an exact copy of the application state.
This is where synchronous vs. asynchronous replication matters. Synchronous replication means the secondary site, even a thousand miles away, holds the exact same data as the primary within milliseconds. That's what guarantees application access survives a cutover, not just network connectivity.
Mitch is clear about the priority order, though: the communication network is the single biggest point of failure, because it ties into every application at once. Lose one application and you lose one application. Lose the network and you lose access to everything. Organizations invest in network resiliency first, then extend it to the application layer based on how critical each application is.
The Non-Negotiable: A Fail-Back Plan
If there's one point Mitch returns to hardest, it's this: "When you're doing a cutover, you have one shot to do it right. And if you don't do it right, you better have a fail-back plan."
He frames it as moving from State A (the current, working environment) to State B (the new one). If the cutover to B fails and there's no tested plan to return to A, the team is scrambling to reconstruct the last known good state under maximum pressure, exactly what a zero-downtime environment can't afford. On critical engagements, he notes, "before we ever step on the field to do the cutover, there's a published fail-back plan."
We’ve seen real world examples of why this matters. During a firewall cutover, the new firewalls were being installed to support SAML, a modern authentication protocol the old environment didn't handle. But the new firewalls didn't support an older protocol that one legacy application still depended on. The cutover failed on that single application, and because a fail-back plan existed, the team was able to return to the working state cleanly.
Where Healthcare Raises the Stakes
For healthcare organizations, resiliency is often a regulatory requirement, and the consequences of failure are measured in patient outcomes. Mitch points specifically to Level 1 trauma centers, which typically carry more resiliency regulation than other facilities. These are the last-resort acute-care facilities during a natural disaster or a crisis like COVID, where there's a risk of people dying if they're not running.
Examples like these extend beyond the network. Considering additional redundancy like power redundancy, backup generators on the roof or next door, is foundational, because as Mitch puts it, if you have no power, resilient switches don't matter.
Power or network, the goal across all of it is singular: keep the point of care up, so patients are never compromised.
The Takeaway for IT Buyers
The Bottom Line
The technology of a zero-downtime cutover is well understood. What separates a calm cutover from a chaotic one is the work that happens before anyone touches the equipment. In Mitch's words: "The key to doing this without having an outage is discovery and planning. And the planning must include a fail-back."
Thorough discovery surfaces the one legacy application nobody remembered. Thorough planning builds the parallel road and the tested failover to cross it. And a published fail-back plan means that even if something unexpected happens, the network never goes dark. That discipline, not the hardware, is what de-risks a cutover, and it's where Derive's experience does the most work.
About Derive Technologies
Derive Technologies is a Minority Business Enterprise-certified IT solutions provider and systems integrator with over 25 years of experience serving healthcare, government, financial services, and enterprise clients across the New York metro area. Derive holds NYS OGS and GSA contract vehicles and has supported critical infrastructure deployments for many prominent enterprise organizations.