When a restaurant or retail brand acquires a portfolio of locations, the technology conversation tends to focus on what’s coming in — new POS systems, updated network gear, refreshed back-office infrastructure. What gets far less attention is what’s already there, what condition it’s in, and whether anyone actually knows what it is.
That gap is where deployments quietly fall apart.
We encountered it firsthand on a large-scale technology migration involving over 200 critical food service locations across 22 airports. The operator had acquired these sites from another company — inheriting not just the physical spaces but the network infrastructure those spaces ran on. And here’s the part that changes everything: they had very limited visibility into that infrastructure before the cutover began – only the network hardware models & quantities; but none of the actual network topologies and VLAN structure…and none of the physical infrastructure. The prior operator’s network configurations, port maps, and device documentation didn’t transfer with the acquisition. The switches were in place. The cables were in place. But what was connected where, and how it was segmented, existed nowhere that the new owner could access.
This isn’t unusual in acquisitions. It’s unfortunately the norm. And it creates a fundamentally different deployment challenge than the one most IT planning frameworks are built for.
Why Standard Cutover Methodology Doesn’t Apply Here
The conventional approach to a network switch cutover is well-established, and for good reason. You survey the network in advance. You map every device to every port. You document VLANs, patch configurations, and IP assignments. You build the new switch configuration before the cutover window opens, and provide comprehensive instructions for the deployment teams. On the night of the cutover, you execute a plan that was developed over weeks or months of preparation, with as few unknowns as possible.
That approach works when you have access to the network you’re replacing.
In an acquisition scenario, you often don’t. The prior operator may have managed infrastructure informally, with institutional knowledge sitting in someone’s head rather than in documentation. Or the network access credentials didn’t transfer. Or the management systems are locked to the previous owner’s domain. Or simply nobody thought to capture it before the deal closed. The reasons vary, but the outcome is the same: your deployment team arrives at the cutover window with a new switch, an existing patch panel, and a rack full of cables connected to devices nobody has catalogued.
Telling a field team to “plan better” in this situation isn’t wrong exactly. It’s just advice that doesn’t connect to the actual constraint. The constraint isn’t a planning failure. It’s a structural reality of how acquisitions work. These are the kinds of issues that tend to surface during real-world deployments—where execution, not planning, becomes the limiting factor, as we’ve discussed in other scenarios involving multi-location rollouts.
What the Constraint Demands
When you cannot pre-map the existing network, you need a methodology that doesn’t depend on pre-mapping. The approach we advise in that scenario, and have since refined across multiple deployments, is built on a single organizing principle: get the critical systems up first, then sort everything else out – before re-opening – from a position of stability rather than crisis.
In a restaurant environment, there’s a clear hierarchy of what has to function. POS terminals, payment devices, and kitchen display systems are non-negotiable. Without them, the restaurant cannot operate. Everything else, back-office workstations, cameras, administrative systems, digital signage, matters, but the business can manage briefly without them if it comes to that.
That hierarchy becomes the foundation of the cutover process.
Rather than attempting port-by-port replication of a configuration nobody can fully see, the field team connects everything through the patch panel on a one-for-one basis; port one to port one, port two to port two; into a switch pre-staged on the POS VLAN. Because all devices land on that VLAN at plug-in, the critical systems come up immediately, regardless of which physical port they’re on. The restaurant’s operational capability is restored before the remaining segmentation work begins.
Once the on-site team confirms that POS, KDS, and payment terminals are live, a network engineer takes over. Working from a cloud management console, that engineer can see every connected device, identified by MAC address, hostname, and device type, and push each one onto its correct VLAN from the back end. The segmentation that would have required hours of on-site pre-mapping gets handled remotely, methodically, after the critical systems are already up and running. Now the business can confidently and securely re-open!
On the PCI Question
When we shared a version of this approach on LinkedIn, a number of enterprise network engineers raised an immediate concern: doesn’t putting POS and non-POS devices on the same VLAN, even temporarily, create a PCI compliance problem?
It’s a fair question, and it deserves a direct answer.
PCI compliance governs how cardholder data is handled during live transaction processing. During a cutover window, the restaurant is offline. There are no live transactions. No cardholder data is flowing through the network while the physical work is happening. The compliance requirement is that the environment is properly segmented before the store opens and begins processing payments, and that’s exactly what the remote segmentation step achieves. By the time the doors open, every device is on its correct VLAN, and the network is operating in full compliance.
The critics raising PCI concerns were, in most cases, thinking about this approach applied to a live production network, which would absolutely be a problem. Applied during a scheduled offline window, with proper segmentation completed before the store reopens, it isn’t. Context is critical here.
What Network Engineers Can Actually See
A related concern from the LinkedIn discussion was whether remote VLAN segmentation is genuinely practical or whether it just pushes the uncertainty problem to a different team.
Modern network management platforms make it more workable than most people realize. When a device connects to a switch, it broadcasts its MAC address and, in most cases, a readable hostname or device identifier. A camera announces itself as a camera. A KDS terminal shows its model and serial. POS workstations, access points, and back-office computers all have identifiable signatures that appear immediately in the management console. More sophisticated platforms build a live topology map automatically showing which device is on which port, which switches are linked, and how the entire network is structured without any manual input.
The edge cases are real. Some devices, certain Apple hardware configurations, for example, randomize their MAC addresses for privacy reasons, making remote identification harder. For those, a quick unplug-and-observe process resolves it: the field tech unplugs the unknown device and the remote engineer notes which identifier disappears from the console. It’s a targeted exception, not a systemic problem.
The 3D-printed switch faceplate technique that came up in the LinkedIn comments is also genuinely useful in this context, and worth mentioning. Some experienced field teams use a printed replica of the switch face to physically stage cables port-by-port before the old switch is removed — so they know exactly where everything was plugged in before they start pulling cables. It’s low-tech, fast, and doesn’t require network access. When combined with the network segmentation approach, it gives the field team a physical reference without creating a dependency on documentation that may not exist.
Where This Applies — and Where It Doesn’t
This methodology is designed for a specific set of conditions. It is not a universal recommendation, and it would be the wrong approach in many common scenarios.
If you have pre-cutover access to the existing network, meaning you can survey it, map device locations, document VLANs, and pre-configure the replacement hardware, you should do that. The result will be a faster, more controlled cutover with fewer unknowns. The planning-first approach is the right approach when the conditions for it exist.
This methodology is for when those conditions don’t exist: when you’ve inherited a network you cannot see, when documentation was never created or didn’t transfer, when the cutover window is all you have and discovery has to happen within it. Those conditions are common in acquisitions. They’re also common in situations where a smaller operator never built formal network documentation. It’s not uncommon for a new IT director to inherit a chain of 25 locations where the previous IT manager held everything in their head, for example, and is no longer reachable.
If you’re managing a technology refresh across locations you’ve owned and operated for years, with your own documentation and network access intact, the standard methodology applies. If you’re managing technology transitions across locations you’ve recently acquired or locations where documentation simply doesn’t exist, this approach offers a way to get critical systems operational within a constrained window while the network engineers handle segmentation cleanly from the back end.
The Broader Acquisition IT Problem
The network cutover is just one facet of a larger challenge that acquisition-driven growth creates for IT teams.
When a brand acquires locations, whether it’s a food service operator taking over airport concessions, a retail chain absorbing a regional competitor, or a franchise group adding new units, the technology inherited at those sites is almost always in an unknown state. Some of it may be current and well-documented. Some of it may be end-of-life equipment running configurations nobody has reviewed in years. Rarely is any of it documented to the standard the acquiring organization would have built themselves.
The pressure to get those locations operational, to convert them to the new operator’s systems, reopen them under the new brand, and start generating revenue, doesn’t leave much time for the kind of methodical network documentation that would make every cutover clean and predictable. The deployment team is working against the clock, in environments they’ve never been in before, with infrastructure they’re seeing for the first time.
What that environment demands isn’t just technical skill. It’s adaptability — the ability to read what’s in front of you, make sound decisions with incomplete information, and keep critical systems moving without waiting for perfect conditions that may never arrive.
That’s a different capability than executing a pre-planned cutover against a configuration you built yourself. It’s harder to describe on paper, and it rarely gets written about. But for IT decision-makers managing growth through acquisition, it may be the most valuable thing a deployment partner can bring to the table.
What to Look for in a Deployment Partner for Acquisition Scenarios
If your growth strategy includes acquisitions or if you’ve inherited locations with unknown infrastructure, the questions you ask a deployment partner should reflect that reality.
Ask whether they’ve worked in environments where pre-cutover network access wasn’t available, and how they handled it. A partner who has only executed against pre-configured plans will struggle when the plan can’t be built.
Ask how they handle discovery when they encounter something unexpected on-site. In acquisition deployments, surprises are not exceptions, they’re part of the job. The answer should describe a practiced methodology, not improvisation.
Ask how they coordinate between field teams doing physical work and remote engineers handling configuration. In the approach described here, that handoff is the hinge point. A field team that can reliably confirm “critical systems are up”, and a remote team that can segment from that baseline quickly is what makes the process work.
And ask what “done” looks like before the store opens. Not “done with the physical work.” Done, meaning every device is on its correct VLAN, critical systems have been confirmed operational, and the network is in a compliant and stable state before the first transaction of the day.
The standard methodology works when standard conditions apply. Acquisitions rarely offer standard conditions. Make sure your partner has worked in the messy version.
If you’re about to embark on an acquisition and are looking for road-tested service providers, Worldlink has helped several organizations evolve through their acquisitions. Contact us now to schedule a conversation about your project.