Running a discontinued POS: keep, recover, or replace

What "discontinued" actually stopped

Discontinuation is not one event. It is a sequence, and the dates in the sequence matter more than the announcement. Intuit discontinued QuickBooks Desktop Point of Sale on October 3, 2023. Support ended, and the payments and connected services tied to it stopped with it. The registers themselves did not stop. Stores that were running QuickBooks POS on October 2 kept ringing up sales on October 4, on the same machines, with the same software. What they lost was the vendor: no updates, no fixes, no one to call, and no payment path through Intuit.

The same pattern is forming elsewhere. NetSuite announced end of life for its POS and SCIS products with support ending January 31, 2029, which means a fresh wave of merchants is already planning around a known date. Every discontinued POS follows the same shape: the vendor leaves in stages, the software keeps running for a while, and the risk concentrates in the parts that depend on the outside world. Payments, tax rate updates, card integrations, and emailed receipts fail first. The register screen and the local database fail last.

That is why the first question is never "what should we switch to." It is "what exactly stopped, and what still works." A store whose payments now run through a separate terminal and whose reports still print is in a very different position from a store whose payment processing died with the discontinuation. Write down the two lists before deciding anything.

The first week checklist

Do these in order, before any vendor demo and before any replacement decision:

1. Inventory every machine. Every register, every back office PC, every receipt printer and barcode scanner, and which machine holds the main database. Photograph the setup. If only one person knows the layout, that knowledge is now a single point of failure.
2. Back up the back office machine, twice. A full disk image if you can get one, plus a copy of the program folders and the data folder on separate media. A discontinued POS has no vendor restore path, so your backup is the restore path.
3. Export your data while the system still runs. Sales history, inventory, pricing, customers, and open layaways or gift balances. Exports are easy while the program runs and hard or impossible after it stops. Do not wait for a replacement to be chosen; export now, in whatever format the program offers.
4. Secure the installers and license keys. The installer media, the license keys, and any activation records. Reinstalling a discontinued product on a replacement register PC is only possible if you hold these yourself.
5. Map the payment path. How does a card payment travel from the register to the bank today, and which link in that chain depended on the discontinued vendor. If that link is already broken, you have a deadline. If it is not, you have options.
6. List the reports and rules only this system knows. Tax handling, discount rules, loyalty balances, special pricing, and the end of day report format your accountant expects. These are the things a replacement must reproduce, and they are the things most often discovered missing after a switch.

Option 1: keep running it

Keeping a discontinued POS running is a legitimate choice, not a failure to decide. It fits when the registers are stable, payments work through a path that does not depend on the vendor, no tax or reporting change is coming that the software cannot handle, and the store can tolerate the risk of a register PC failure. The cost is low: a spare PC imaged and ready, a second backup routine, and someone local who can swap hardware.

The risks are specific, and they should be named. The register PC will eventually fail, and its replacement will need the installer, the license, and drivers for printers and scanners that modern operating systems may not ship. A tax rate change or a reporting requirement the old software cannot express will force a workaround. And every year, fewer technicians remember the product. Keeping it running is a plan with an expiry date, and the plan should say what that date is: the next payment change, the next tax change, or the next hardware failure, whichever comes first.

Option 2: recover the source

Recovery fits when the system holds something no replacement reproduces: custom pricing rules, reports your accountant relies on, integrations with a back office program, or years of sales data in a format only this program reads well. Recovery rebuilds readable source from the compiled register and back office programs, documents the data the system holds, and verifies the rebuild against the running program. The result is a system you can maintain, fix, and carry into a planned replacement on your own schedule, instead of under pressure.

At Orphanware Recovery, Josiah Wilson directs every engagement and signs off on every result, and the decompilation, reconstruction, and testing pipeline is carried out by AI agents under his direction. The $45 Recon Report is the first step: an honest verdict on whether your programs can be recovered, what they do, and what a full recovery would take. It answers the technical question before you spend on the larger decision. Recovery does not restore vendor support, and it does not fix a broken payment integration on its own. What it does is turn a black box you cannot change into source you can maintain, which changes the other two options from guesses into plans.

Option 3: replace it on a schedule

Replacement fits when payments are already broken, when a tax or reporting change is coming that the old system cannot meet, or when the store is growing past what the old registers can handle. The difference between a good replacement and a disaster is almost entirely timing and data. Choose the replacement while the old system still runs. Export everything before the switch, not during it. Run the new system on one register first, with the old system still live beside it, and cut over on a closed day or a quiet morning, never during a rush.

When vendors demo replacements, ask three questions and write down the answers. First, what happens to your sales history, inventory, and customer balances: imported, converted, or left behind. Second, what the payment path is and who supports it when it breaks. Third, what the exit looks like: how your data comes back out if this vendor discontinues its product too. A vendor that cannot answer the third question clearly is selling you the same problem on a new timeline.

How to choose

Keep running it when payments work, the hardware is stable, and no regulatory change is forcing your hand. Recover the source when the system holds rules, reports, or data that a replacement would lose, and you need time to replace on your terms. Replace on a schedule when payments are broken, a deadline is real, or the store has outgrown the old registers. The combination is common and sensible: recover first to document and preserve what the system knows, then replace with the full picture in hand. That order costs a $45 recon up front and saves a rushed migration later.

The one choice to avoid is the rushed replacement during trading hours, chosen because a register failed on a Saturday and nobody had a backup. That is the failure mode this whole guide exists to prevent. A spare imaged PC, a current data export, and a written list of what the old system knows will turn that Saturday from a crisis into a routine swap, whatever option you ultimately choose.