Why "clean-sheet" migrations do not work for most multi-site businesses
The fantasy is clean. Pick a date. Cut every site over to the new vendor. Done. It works in a lab. It almost never works in the field.
Three reasons. First, contracts do not line up. A multi-site business with twenty locations probably has carrier agreements expiring across a three-year window, sometimes more. Cutting over before a contract expires means paying early termination fees, which can run into hundreds of thousands of dollars across the estate. Cutting over at the wrong time means running two networks side by side and paying both. Neither is a good outcome.
Second, operational risk compounds. A bad migration at one site is a bad day. A bad migration at fifty sites in the same week is a quarter. Multi-site businesses cannot afford a quarter of degraded operations across the estate. The only way to keep the risk per cutover low is to keep the number of simultaneous cutovers low.
Third, the team that has to absorb the change is the same team running the business. Store openings, renovations, hiring, payroll, and everything else does not stop because IT is doing a migration. A plan that demands the operations team's full attention for a single quarter will not happen the way the plan says it will.
The alternative is a phased migration. Slower, but the one that finishes.
1. Start with a pilot of new sites
The first move is not to migrate an existing site. It is to bring up new ones.
New locations are the cleanest test of the new vendor relationship because there is no service to disrupt. Nothing to roll back to. No customer-facing risk if the install runs long. Both teams (yours and the vendor's) get to run the full process, from order through install, configuration, and support, on sites where the stakes are low.
A typical pilot is two to five sites, chosen to cover the variety of conditions the rest of the estate will encounter. Different regions. Different building types. Different timing constraints. By the end of the pilot, both teams know what the process looks like at scale, what the install playbook is, and where the rough edges are.
This is also where the working relationship is built. Project managers, field technicians, support escalation paths, ticketing integrations. None of that gets tested in an RFP. It gets tested by running real installs together. The ten questions worth asking a provider are the diagnostic before the pilot. The pilot itself is the proof.
Pilots take six weeks to three months. They are not optional. Skipping the pilot to get to scale faster is the single most common reason migrations go sideways at the estate level.
2. Migrate by contract end date, not by region or priority
After the pilot, the easy assumption is to migrate by region. Or by store priority. Or by some other organizing logic that makes sense to operations.
It is the wrong organizing principle. The right one is contract end dates.
Each existing site moves over as its current carrier agreement expires. No early termination fees. No paying for two services at the same location. No revenue at risk because the existing service stays in place until the day the new one goes live.
This means the migration order is set by your existing contracts, not by what is convenient for IT. It means the project runs on the calendar dictated by your prior carrier setup, which may span years. A three-year phased migration is normal for an estate that started with overlapping multi-year agreements. That is not a failure mode. That is the only path that does not cost money or service to walk.
It also means combined volume builds gradually rather than all at once. Some businesses use this as a negotiating lever. As more sites consolidate onto the new vendor, pricing for the next wave often improves. The single-vendor pricing model is built on combined volume, and combined volume increases month by month as the migration runs.
3. Run two networks during the overlap, never after
During a phased migration, there will be a period when some sites are on the new vendor and some are still on the old one. That is expected. The temptation, sometimes, is to keep the old vendor in place at certain sites "for backup" even after the cutover is complete. Or to keep an old contract active because terminating it feels risky.
Resist that temptation. The point of the migration is to consolidate. Half-consolidated is worse than not consolidated, because you carry the operational overhead of both setups without the leverage of either. Cancel the old service the day the new one stabilizes, not three months later.
The exception is during a single cutover, where the old circuit stays live until the new one is confirmed working at that specific site. That is technical overlap of hours or days, not contractual overlap of months. They are different things.
4. Standardize the per-site install
Multi-site migration only works if each site's install is repeatable. Custom anything kills the rhythm.
The standard pattern: pre-staged equipment shipped to each site, pre-configured for that location. A documented install checklist that the field technician works through. A site survey done before commitment so the technician knows what they are walking into. Structured cabling and a uniform equipment mounting standard. Configuration applied through templates, not by hand.
This is what a national rollout service actually does. Frontier dispatches to sites daily across Canada and the US, with depots in both countries holding inventory for replacement and refresh. The same field operations team that handles new builds handles migrations, which means the standardization is built into how the work happens, not bolted on for a specific deal.
Site coordination is also the part that breaks most often when handled by a vendor that is good at selling circuits but not good at logistics. The questions to ask: who schedules the install, who confirms the building access, who validates the cutover at the end, and who calls you when something is off. The right answer is one vendor owning all of it.
5. Plan the rollback before the cutover
Every site cutover has a rollback path. Document it before the cutover, not during.
Rollback is not a backup plan in case the entire migration fails. It is the operational plan for what happens if the cutover at one specific site does not complete cleanly on the scheduled day. The old circuit stays live until the new one is confirmed. The technician has the credentials to restore the old configuration if needed. The store has a number to call that is staffed during the cutover window.
The cutovers that go badly are the ones where nobody planned for the cutover going badly. The cutovers that go well are unremarkable, which is what good operations looks like.
When to do this differently
Three situations break the phased-by-contract-date pattern.
Greenfield estates. If you are building a new network from scratch with no existing carrier setup, the constraints above do not apply. You can roll out as fast as the new vendor can install.
Active vendor disruption. If your current carrier is being acquired, restructured, or has materially degraded service, you may not have the luxury of waiting for contracts to expire. In that case, the migration compresses. Early termination fees may be worth paying to escape a vendor that is no longer serving you. This is the scenario our POTS pillar covers in the context of copper retirement and the vendor-disruption case study covers across an entire estate.
Single-site businesses. The phased-by-contract model is built for estates with multiple overlapping agreements. A single-site business is a different problem and a simpler one.
Where Frontier fits
Frontier has run this playbook across multi-site businesses of every shape. The case studies on our customer stories page describe two of them in detail. One was a Canadian multi-site retailer that consolidated three regional carriers onto one vendor over three years, contract by contract, with no early termination fees and no revenue at risk. Another was a national retailer with thousands of sites that migrated to a single managed relationship coordinated through a custom integration between Frontier and the retailer's internal systems.
Frontier's roll-out service runs nationwide, with depots in Canada and the US holding equipment for installs, replacements, and refreshes. We dispatch to sites daily for installs, restoral, and tech refresh. We handle the break up with your existing vendor and pay your final bill. No finger-pointing between vendors during the transition. No field service charges. When something needs attention, we call you, not the other way around. 0 to 4 hour resolution objective. Canadian-based support. Our own national backbone (AS7311) and our own NOC sit behind the entire operation.
Voice typically moves onto TrueVoice, Frontier's Canadian-hosted cloud PBX, as part of the same migration. Data moves onto Managed SD-WAN across the same architecture. One vendor managing the whole stack means one project, not three.
What to do next
If you are planning a connectivity migration this year and you do not have a current map of your existing contracts and their end dates, that is the first project. The audit takes longer than people expect and is the only thing that lets the rest of the plan work.
If you do have the map and you want to talk through what a phased migration would look like for your estate, let's talk. No formal RFP required for an initial conversation. Walk us through your environment and we will tell you what we would do, where we would fit, and where someone else might be the better choice.
