POS System Migration and Cutover Plan

Moving the data is the obvious question. The harder one is how to switch: all at once on one night, or gradually, with the old and new systems both live for a while. That choice decides how much can go wrong at the counter and how long it takes to find out. The recommendation below is evaluated against published criteria; no migration was performed for it.

The recommendation for a single store: one night, in the quiet season

For one location, switch in a single overnight cutover. Close the day on the old system, move the final changes, check the new one before opening, and open on it the next morning. Keep the old system untouched and ready until the new one has closed its first full week.

The alternative sounds safer but may not be. Running both registers side by side means some sales land in one system and some in the other. Stock counts drift apart, card batches settle from two places, and the bookkeeper has to stitch two sets of reports into one month. A small team ends up doing double work at the exact moment it is learning a new screen. The one place a parallel run makes sense is the back office: let the new system import a copy of the old sales for a week or two and check that its reports agree, without taking a single real payment.

When to postpone

Pick the date before you pick the features. Cut over in the slowest stretch of your year, and treat the run-up to your busiest season as off limits. A shop that does its year in November and December should not be learning refunds on a new system in late November.

The rule is simple: if the full rehearsal below has not been passed several weeks before peak season, wait until the season is over. A missed launch date is likely cheaper to absorb than a broken checkout during the weeks that pay for the year, when nobody has time to fix it.

Where the answer flips

Several locations. Switch one site first, ideally the one with the strongest manager, and leave the others alone. Move the rest only after the pilot store has operated, closed, and reconciled a full week without help from the implementer. A problem at the pilot stays at one site, and what that store learns becomes the runbook for the others.

The old contract ends before you are ready. If the old provider is switching you off before peak season, postponing is not available. Shrink the launch instead: move sales, payments, refunds, and the daily close, and leave loyalty, online ordering, and other add-ons until after the season.

The rehearsal keeps failing. If the new system cannot pass the rehearsal and your current contract lets you stay, staying is a legitimate outcome. A switch is worth making for a system that works, not for a date already announced to staff.

What is still open on cutover night

The data that causes trouble is not the product list. It is everything that is half finished when the old system stops. Picture a store at closing time on switch night: stock is on a truck between the warehouse and the shop, two online orders are paid but not shipped, a customer has a return pending, gift cards still carry balances, and a promotion is scheduled to start next week.

For each of these, decide in advance which system finishes the job. Will the open orders be fulfilled from the old system, or re-created in the new one with a note pointing back to the original? Who will honor the old gift card balances, and how will staff look them up? Where will a cashier find the original receipt when a customer returns something bought last month? Write the answer down, tell the staff on shift, and keep read-only access to the old system until every one of these items is closed.

Do not import the biggest spreadsheet and call it the truth. Duplicate products, customers who might be two different people, and stock counts nobody can explain should be set aside and fixed by a named person, not loaded and sorted out later.

The rehearsal that earns the go-ahead

Before the real night, do a timed practice run with test records. Load products, prices, customers, opening stock, and staff logins. Ring up a cash sale, a card sale, a declined card, a refund, an exchange, and a promotion. Unplug a device and drop the network for a few minutes and see what staff do. Close the day and ask the bookkeeper to reconcile cash, cards, and refunds from the new system's export alone. Then practice the rollback: how long does it take to get the old system taking sales again, and who makes that call?

Have the backup manager run the rehearsal, not the person who set the system up. If only the implementer can make it work, the store is not ready.

Tax and card settings do not carry over safely

Copying tax rates and categories from the old system moves the old answers, right or wrong, into the new one. A business that sells into several states can use the Streamlined Sales Tax Governing Board's remote-seller registration and FAQ material as a starting point, but each state's current rules still have to be confirmed by the business and its tax adviser before the new settings go live.

Card data needs the same care. New payment hardware does not by itself change who is responsible for protecting card data under PCI DSS. Ask the new provider which tasks stay with you, and check how your validation path is set under PCI Security Standards Council merchant guidance and with your acquiring bank, including for the overlap weeks when both systems still exist. Never put card numbers in migration files, screenshots, or support tickets.

The go or no-go call

Go only when the backup manager has run the rehearsal, the bookkeeper has reconciled a practice day, every open order and gift balance has a written owner, and the rollback has been timed. Anything still broken needs a name next to it and an explicit decision to accept it. After launch, do a stock count or menu check within the first weeks, trace any gaps to their cause, and only then turn off the old system.