The supplier says “the whole menu can migrate.” On cutover night, accents in soup names turn into question marks, and about twenty combo sub-items go missing. The floor is still serving. Nobody can say which records must enter the new system, which only go to archive, and which must stay open in the old one.
Before you cut, fix the scope. Then match counts and identifiers on a sample from this shop. Until that sample exists, do not write “we can migrate” into the cutover plan.
Write the scope first, then talk about a cutover date
Do not start by picking a date. First list what this shop still needs: items, prices, tax settings, tables, users, permissions, tickets, logs, and any other files you still look up.
Each row gets only three destinations: move into the new system; archive only; or keep accessible in the old system. Write source format, target format, clean-up rules, what will not move, roughly how long manual backfill takes, and who does it.
Scene one: accounts want Monday’s look-up of Friday’s split check. If the new system only took the current menu, three years of tickets went into a “later” archive, and the old system was stopped that night — that check is gone. Lock it on the scope sheet early: move those tickets, archive only, or keep the old system searchable for a while.
Scene two: the bar has two soups with the same name, different codes and tax rates. Migrating names without identifiers still “looks migrated” in a sample. You check counts and identifiers, not whether the screen looks familiar.
What cannot migrate must not be waved off as “we’ll see later.” Write the backfill load. The people who will run the real cutover must see this sheet.
If the sample does not match, the plan is incomplete
Ask the vendor under evaluation for a trial export. Clear a sample in this shop and import it into a non-production environment. Do not use fake dishes from a demo library.
Check at least: fields line up; Hungarian accents and special characters survive; dates, identifiers and amounts match the source; history stays readable after import. Match totals once, then spot-check a few rows against the source. If one is off, note which class failed — do not close with “close enough.”
Scene: the old system has 412 items; after import, 389. The missing ones are combo children and discontinued dishes that can still be refunded. If you miss that in the sample, you only learn after cutover that refunds cannot find the original item.
The people who will run the real cutover must join this drill. If only the office clicks import once, the shift on the window will not know how. In the drill already name who exports, who cleans, who imports, who calls the counts.
The six words “we can migrate” are not a plan until sample counts and identifiers both check out.
In the cutover window: what you check, who green-lights go-live
Only after scope and sample pass do you write the window. Write when data entry stops, when backup runs, and when the window starts and ends. How new tickets inside the window are handled — pause opening tables, handwrite then backfill, or another method this shop can actually run — write it down; do not negotiate it live.
Name who may approve go-live, who checks day one, who owns the first day-end. Every migration step lands on a named role. Inside the window, the vendor’s contact must be reachable.
Ask again before the cut: items that failed in the sample — do they block go-live, or are they written down with a backfill deadline. With no signature, do not treat the window as fixed.
Related short answers
- Can “migration is possible” go into the go-live plan without a sample run?
- Related steps: Limited pilot first: scope, dates, rollback · How to roll back: triggers, decision maker, cut-back steps
- What must a limited POS pilot spell out—and which three end conclusions are allowed?
- What rollback items must be written before go-live—who decides, how long does the old system stay?