The item file can move. Closed tickets usually cannot. POS sales history when switching stays with the old vendor unless you export it before you cut over, and a ticket file is not an item file. The old processor keeps its own records. Download statements before you close that account. The catalog and pricing are what we rebuild on the new register. Last year’s fifths, voids, and split tenders stay in the old login for as long as that vendor keeps them.
What sales history actually is on a retail POS
Sales history on a retail POS is the closed tickets, not the shelf. Each ticket is a snapshot of one sale: which SKUs rang, which tenders paid, which cashier was signed in, and when the drawer closed. A liquor store ticket might show a fifth, a mixer, cash plus a card, and a void a manager had to approve. That record lives in the old vendor’s database, usually behind the same login you use for weekly reports.
Owners fold four things into one word. The SKU catalog. Closed tickets. Tender totals. Time-clock punches. They are stored as separate files. One of them rebuilds a counter. The others are an archive.
The catalog is the living list. Barcode, description, pack size, the twelve bottles that come out of a case, department, price. Tickets are the past. Tender reports are the cash, card, EBT, and house-charge columns your accountant ties to the bank. Time-clock records are who was on the floor, not what sold.
A daily flash is a summary of those tickets. It is not the tickets themselves. If you only print the flash and never export the detail, you have a stack of paper and no file you can search later.
A card sale on that ticket is a tender line, not a card dump. Card data is handled under the processor PCI program. What you want from history is the amount, the batch, and the time.
Cloud POS systems keep this in the vendor’s login. Once that login dies, so does the easy view. Some vendors let you keep a read-only portal. Some do not. Pull the files while you still pay for the seat.
What usually exports and what stays behind
The item library and pricing are what usually export. Historical transactions stay with the old processor. A store that asks for everything often gets a spreadsheet of SKUs and no ticket-level file.
While the account is still open, pull these if the back office will still run them.
- Export the item file with barcodes, prices, departments, and pack sizes.
- Save end-of-day flashes, tender recaps, and tax summaries as PDFs or CSVs.
- Download processor statements and batch reports from the merchant portal.
- Pull time-clock punches and cashier lists if that screen still exports.
The clickable ticket is what stays behind. The screen where you open sale 14,882 and see two packs of cigarettes, the void, and the split tender. Many vendors will not dump that table. When they do, the columns rarely map into a new register. The new system has its own ticket IDs. It will not replay last March as if those sales happened on the new hardware.
Loyalty points and gift card balances sit in a third bucket. They are not sales history. They do not move because you exported a catalog. If you run either program, settle those balances with the old vendor before you cancel.
Keep two copies of every file you do get. One on a drive you hold. One in a folder you control. Date the folder. Do not leave the only copy inside the old cloud.
The catalog export is its own job. We wrote the steps for exporting a POS item file when switching. Do that work before you give notice if you can. Support is warmer while you still pay the bill.
Tickets, tenders, and the item file are three different files
A ticket file is every closed sale, line by line. A tender file is how those sales were paid. An item file is what you sell tomorrow. Mixing them is how stores think history did not convert when the catalog actually did.
The item file is the one we rebuild. Barcode, name, size, department, cost if the old system held it, retail, case-break rules. That file answers whether the cashier can scan this fifth. It does not answer what you sold on a holiday weekend.
Tender totals are what you use to close the day. Cash in the drawer. Cards batched. EBT on SNAP-eligible items with split tender. Store credit. Lottery is its own terminal, so those sales never lived in the register the way a six-pack does. You reconcile lottery against the state’s machine, not against POS history. Tobacco scan data is a sales-detail file in the format the program asks for. Whether a given POS version can send it is checked during setup. Past scan files, if you still need them, come from the old system.
Closed tickets are the audit trail. A return six months later. A card dispute. A partner who wants last winter’s mix. Those tickets live where they were written. The old processor keeps its own records. Download statements before you close the account. Print or export the reports your accountant actually files.
Time-clock is a fourth file people forget until payroll week. Punches, roles, who could void. The new register gets new logins. Old punch history stays in the old back office for as long as that vendor keeps it.
If a vendor offers one full backup, open it before you celebrate. Count the sheets. If you see items and prices but no ticket IDs, you have a catalog, not a history.
How a store still closes the books during the cutover
You close the books the same way you close a Thursday, with a clean cut. Ring the last sale on the old register. Batch the cards. Count the drawer. Print the tender recap and the Z tape. Save those files with the date. Then the new register takes the next sale.
The new system will not show yesterday’s tickets. That is expected. Your accountant still has the old flashes, the processor statements, and the bank deposits. Sales history for the old period lives in that packet, not in the new dashboard.
Stores that stay open through the change treat it as two books, not one broken book. Morning on the old lane, afternoon on the new one. Or one counter live on the new hardware while the old login stays up for reports. We walk that cutover in switching POS systems without closing. The hours stay yours. The history stays split by date.
Do not cancel the old login the night you go live. You still need it for a return on a ticket the new register never saw, for a dispute, and for the last statements. Keep the seat until every PDF and CSV you asked for sits outside that portal.
On the merchant accounts we board, deposits land in the merchant’s bank the next business day. Batching at the end of the day is what starts that clock, so a late batch on cutover day pushes the deposit, not the sale. Close the batch the way you always have.
A dispute still needs the old ticket. If that sale rang on the old register, the record is in the old cloud or in the files you saved.
What we rebuild on the new register, and what we cannot
We rebuild the catalog. We cannot replay old tickets inside the new register.
That is the job, said plainly. We take an item export if the old system will give one. We fill gaps from invoices and a shelf walk. We map departments, barcodes, case breaks, and prices onto the new file. We set EBT eligibility and split tender on the demo for stores that take SNAP, which is a USDA program. We set age checks for liquor and convenience. We do not load last year’s tickets into the new reporting dashboard and pretend they rang on the new hardware.
Old tickets often remain in the old login for as long as that vendor keeps them. Log in, run the report, export what they still offer. We cannot promise that every vendor will export ticket-level history. Some will give a date-range CSV. Some will give monthly PDFs. Some will give the catalog and nothing else.
The new analytics dashboard reports from the first sale forward, per location. That is a clean book. Compare it to the old book by date. Do not hope the charts stitch together.
If you need a number from last winter, you go to the archive you saved, or to the old portal if it is still up. You do not go to the new register.
We set stores up across the US by phone, video, and shipped, pre-configured hardware. The cutover file set is the same conversation in every store: what exported, what we rebuild, what stays in the old cloud. A liquor aisle and a gas c-store run the same split. Read how a switch is scoped on switching POS systems and the steps on how it works.
Hardware is a separate question from history. The terminal on the counter can stay or go. The tickets do not live in the plastic. They live in the vendor’s records. If you are asking about the gear itself, we covered that in keeping POS hardware when switching.
Frequently asked questions
Does sales history move to the new POS?
No. Sales history does not migrate. The old processor keeps its own records. Download statements and the reports you still need before you close the old account. The item library and pricing are what we rebuild.
Can I export POS sales history before I cancel?
Pull every report the back office will still run while you are a paying customer. Item file, tender recaps, tax summaries, and ticket detail if the vendor offers it. Save copies outside that login. Not every vendor will export closed tickets.
Where do old POS tickets live after the switch?
They stay in the old vendor’s cloud for as long as that vendor keeps the login and the files. The new register starts a new ticket book on go-live. Keep the old portal available until you have the archive in your own folders.