Short answer: you migrate one location at a time, sequenced by risk rather than size, with each site's cutover landing in its own slow week. A 20-location group should plan 14 to 16 weeks end to end — roughly two weeks of build, then one site per week with a two-site overlap. Nobody closes. The locations that go dark are the ones that tried to switch everything on the same Friday.
Why "Big Bang" Is The Wrong Instinct
Every group that has done this once arrives at the same conclusion, usually the hard way. The instinct is to cut over everything at once and get the pain done in a single weekend. The reality is that a POS migration is not one project — it is your menu, your modifiers, your staff training, your network, your payment processing, your accounting integration and your hardware, all changing at the same moment, in a building full of guests.
Do that in one site and you have a rough Saturday. Do it in twelve and you have no working fallback anywhere in the company.
Operators say this plainly the moment you ask. An eight-location Colorado group, mapping out their own sequence: "I would probably try to do one at a time just for training purposes. So I'm not trying to train all of them at the same time." That is the whole argument in one sentence. Training capacity, not software, is what caps how fast you can move.
How Do You Choose Which Location Goes First?
Most groups pick their smallest or newest site, on the theory that it is the least risky. That is the wrong variable. Pick for learning value, and specifically for a site that has three properties:
- A representative menu. If your pilot has 40 items and your flagship has 300 with heavy modifiers, you learn almost nothing transferable. You want the site whose menu structure most resembles the group average.
- A strong general manager who is staying. The pilot GM becomes your internal trainer for sites two through twenty. If that person leaves in month three, you pay for the pilot twice.
- Enough volume to surface real problems. A quiet Tuesday-only site will not expose the queue behaviour, the printer routing or the split-check edge cases that break at 300 covers.
A four-location family entertainment group running 41 terminals put it differently — they chose by season rather than by size, and they chose the site whose failure mattered least at that moment: "we would change over the country store first." Same logic. The pilot is a rehearsal, and you want a rehearsal with real stakes but survivable consequences.
The Constraint Most Groups Discover Too Late
Every multi-unit business has a calendar it does not control. Seasonal venues have a season. Campus-adjacent sites have a term. Resorts have a shoulder. Stadium and event venues have a schedule published a year out. And new locations have an opening date that is already on a lease.
The same four-location operator was explicit about it: "Probably we don't want to switch in the middle of the season… Better to do it at the end of the season than the beginning of the season and have startup problems or a delayed opening."
That is worth restating as a rule. Cut over at the end of a busy period, not the beginning. At the end, your staff are at peak competence, your menu is stable, and a bad week costs you a slow week. At the beginning, you have new seasonal hires learning a new system while volume climbs, and any delay compounds into your highest-revenue months.
There is a second version of this constraint that catches growing groups. A brewery group going from two units to five described their real deadline: "I'd need to get that done before we reopen our new location slated for mid September. So we'd be bringing in that GM and that chef by mid to late August. We'd want to be training them on this system."
The new site is not a location you migrate. It is a location you open on the new system — and that means the incumbent has to be gone from the rest of the group first, or you are running two platforms and training people on both.
What Do You Do When Every Location's Contract Ends On A Different Date?
This is the least glamorous part of a migration and the one that most often sets the actual timeline. Groups that grew by acquisition, or that signed each site as it opened, almost never have a single renewal date. A three-brewpub group with roughly $8 million in annual card volume hit it mid-evaluation: "I'm not sure where we're at contract wise as far as, like, if there's an early termination fee at that point."
Before you build a single menu, get four facts for every location:
- Contract end date
- Auto-renewal terms and the notice window — this is the one that bites, and it is often 60 or 90 days
- Early termination fee, and whether it is a flat amount or the remaining term
- Whether hardware is owned, leased, or financed, and what happens to it on exit
Then build your sequence around it. Sites whose notice windows are closing go earlier. Sites with expensive early-termination exposure go last, or wait for natural expiry while the rest of the group moves. A migration schedule that ignores contract dates is a schedule that hands your incumbent a windfall.
What Does A Parallel Run Actually Look Like?
"Run both systems in parallel" sounds prudent and is mostly a myth. You cannot take the same order on two platforms at once. What you can genuinely parallel is narrower, and worth being precise about:
- You can keep the old system live and idle for one week after cutover, as a documented fallback with a named decision-maker who can call it.
- You can run reporting in parallel for a full period, reconciling the new system's numbers against the old one's for the same days.
- You cannot split service across both systems in one venue. Your tabs, your check numbers and your cash drawer all live in one place or neither.
- You cannot keep the old payment processing running alongside the new. Cards route one way.
Give the fallback a hard expiry — one week is usually enough — because an open-ended fallback becomes a reason not to fix the real problem.
The Hidden Two Weeks: Menu And Modifiers
Groups consistently underestimate this and it is the single most common cause of a slipped go-live. Your menu is not a list of items. It is items, modifiers, modifier groups, forced and optional selections, pricing by daypart, pricing by location, tax categories, printer and prep-station routing, and inventory mapping.
For a group, there is an additional decision that has to be made before any of it is built: what is set centrally and what is set locally? Menu hierarchy — national, regional, local — is one of the few architectural choices you cannot retrofit cheaply.
Do not import your existing structure uncritically. One club operator, looking at a decade of accumulated configuration, said what a lot of people think: "All the modifiers were kind of put in there in weird categories. It was totally set up wrong. And I don't want this to be set up like that was because it was never done right in the first place." A migration is the cheapest opportunity you will ever get to fix that. Budget for it deliberately rather than discovering it in week three.
How Much Training Does Each Site Actually Need?
Training is the binding constraint on migration speed, which is why the eight-location operator quoted at the top sequenced around it rather than around anything technical.
A workable pattern for a full-service site:
- GM and chef: two weeks before that site's cutover, hands-on
- Shift leads and key servers: one week before, in a build environment with the real menu loaded
- Full staff: two to three days before, in short sessions rather than one long one
- Go-live support: on-site for the first two full services, not just the first hour
The single highest-leverage move is training the pilot GM deeply enough that they can train site two. By site four or five you should have an internal bench and be buying far less vendor training time.
A Worked 20-Location, 16-Week Sequence
The shape below assumes a group of twenty full-service sites with a mixed menu, staggered contracts and no site closing at any point.
| Weeks | What happens | Sites live |
|---|---|---|
| 1–2 | Contract audit, network survey, menu architecture decisions, hardware ordered | 0 |
| 3–4 | Menu and modifier build; integrations configured; pilot GM trained | 0 |
| 5 | Pilot site cutover; on-site support for two full services; fallback held one week | 1 |
| 6 | Pilot review; fix the configuration problems the pilot surfaced; no new sites | 1 |
| 7–9 | Sites 2–4, one per week; pilot GM co-trains | 4 |
| 10–13 | Sites 5–12, two per week; internal trainers lead | 12 |
| 14–15 | Sites 13–19, remaining contract-constrained sites | 19 |
| 16 | Final site; decommission old system; close out hardware returns | 20 |
Week 6 is the one groups try to cut, and it is the one that pays for itself. The pilot exists to generate a defect list. If you start site two before you have fixed what the pilot found, you replicate every configuration mistake nineteen more times.
What About The Location Whose IT Will Not Budge?
Somewhere in a group of any size there is a site with an opinion about the network. Sometimes it is a landlord's managed IT. Sometimes it is a franchise brand standard. Sometimes it is one long-tenured person who set it up and does not want it touched.
This is a real and recurring blocker — in one deployment, a client's IT team asked to keep their existing POS vendor's IP addressing scheme in place specifically to avoid reconfiguring everything downstream of it. That is not an unreasonable request, and the answer is usually to accommodate it rather than fight it. What you cannot accommodate is a guest network your operations traffic shares.
Settle three things per site during the week-one survey, not during the cutover week:
- Is there a separate operations SSID, or does POS share the guest network?
- Who owns the router and who has admin credentials?
- What is the actual upload speed, measured at the busiest hour rather than at 9am?
What You Should Have Before You Sign Anything
The migration plan is a procurement input, not a post-signature exercise. Before you commit to a platform, you want the answers to the questions that determine whether the plan above is even possible: what data you can export when you eventually leave, how the vendor's support escalates when a site goes down mid-service, and what the contract lets them do to your rate in year three.
Groups that ask those questions during evaluation run calmer migrations than groups that discover the answers in month eight. One two-unit-going-on-five operator described inheriting the alternative — a group that had migrated a decade and a half of sales history into a platform that could not hold it cleanly, and was "still kind of ironing things out" two years later.
A migration done properly is boring. That is the goal.
GoTab works with multi-unit groups and large-format operators on exactly this sequence — including the parts that are about contracts and calendars rather than software. See how GoTab handles multi-unit brand control and local flexibility, or read more about GoTab for enterprise operators.
