Retiring QuickBooks Desktop Point of Sale Without Losing Your Sales History

QuickBooks Desktop Point of Sale is retired; this playbook exports your items, customers, and sales history and keeps your linked company file balanced.

Intuit has retired QuickBooks Desktop Point of Sale, and the connected services around it have been wound down. Registers may still ring for a while, but a failed workstation or a damaged database now has little behind it. Our engineers treat the exit as a migration with three moving parts: the point of sale database, the replacement system, and the QuickBooks Desktop company file that has absorbed daily financial exchanges for years. This playbook sequences all three.

Freeze and back up both systems first

Start by bringing the two systems into agreement. Run a final financial exchange so every sale, payment, and receiving voucher has posted to QuickBooks. Then run Verify and Rebuild on the company file. If it fails either pass, stop and repair the damage before migrating; see our QuickBooks Verify and Rebuild repair service for that work.

Press F2 in QuickBooks and record the customer, transaction, and target counts as your baseline. Make a portable backup of the company file. Copy the entire point of sale database folder from the server, and keep the installer plus license details for the version you run. A fresh machine can be hard to activate now that the vendor's validation services are winding down, so preserve everything needed to open the archive later.

Export the database while it is still whole

Export in three passes: items, customers, and sales history. The item list report covers item numbers, alternate lookups, UPC codes, descriptions, quantities, average costs, and price levels. The customer list covers contacts, balances, and notes. Send both to a spreadsheet and keep the raw exports untouched; do all cleanup on copies.

Sales history is the slow pass. Receipt-level detail has to be exported in date batches, typically a month or a quarter at a time. Capture payment method, tax, discounts, and cost of goods on each receipt where the report offers them. Decide early how far back you truly need receipts in the new system; closed years can live in a spreadsheet archive instead.

Know what the built-in exports miss. Matrix items come out flattened, receiving vouchers are thin, and per-register breakdowns can need separate reports. History for returns and warranty lookup matters most; one year of receipts is a sensible target, with older history left in the archive.

Map the data to the replacement system

Mapping is where these migrations succeed or fail. Choose one unique key per item, usually the UPC or the alternate lookup, and enforce it in the target before import. Sizes and colors become variants or separate SKUs; pick one convention and record it. Average cost may not survive the round trip cleanly, so carry both cost and quantity for every item.

Dedupe customers by phone number and email before import, or the replacement system will split one shopper into three records. Map each old payment type to a tender button in the new system so daily totals still break down the same way. Where the new product asks for a valuation method, decide between average and standard cost, then stay with it.

Set the cutover date and run the final exchange

Pick a quiet date, close the register normally, and run one last exchange. Open QuickBooks and confirm the final day posted: sales receipts created, card payments sitting in undeposited funds, sales tax payable matching the last summary from the point of sale. Reconcile the deposit so cash and card clearings agree with the bank.

Only then uncouple. Remove the point of sale entry from QuickBooks integrated applications so the file never attempts a half-finished exchange again. Mark the date; it is the boundary between old and new, and every later reconciliation refers to it.

Go live and keep the company file balanced

Load the mapped items with their quantities and costs, then compare total inventory value at cost against the inventory asset account on the cutover date. They should agree to the cent. If they differ, fix the mapping before the first live sale, not after a month of trading.

From day one, sales will arrive in QuickBooks as a daily summary or a journal entry, depending on the product. Map its accounts to the existing chart of accounts rather than letting it invent new ones. Then give the first month-end a close reading: our month-end close and reconciliation notes cover the accounts that typically go wrong after a migration.

Rollback points worth marking in advance

There are three clean places to back out. The first is before the final exchange; the store can trade on the old system a few more days if mapping slips. The second is before you remove the integrated applications link. The third is before the live import; test the load in a sandbox company in the replacement system first.

After real sales post in the new system, stop re-importing, or you will double history. Keep the old database untouched for at least one full season of lookups. It is the only fallback for old receipts, and nothing in the new system will recreate them.

The clean outcome

When the migration is done, the replacement system runs the register. Item counts agree between the old export, the new system, and the inventory asset account. Bank and card clearing accounts reconcile through the cutover without adjustment. Sales tax payable matches the last reports from the retired product. The old database still opens in archive mode on one retained workstation, and nothing about the store depends on a product the vendor no longer sells.