Who this is for
Chains on a back-office POSMicrosoft RMS, NCR CounterPoint, QuickBooks Desktop POS, pcAmerica, Retail Pro, and systems like them.
Pre-production status: the core read-only flow is lab-proven only on simulated data. Production adapters are not live today for any named legacy POS, and this page is an adapter-planning overview, not a connection promise.
Overview · Legacy & on-premise POS · start here
Legacy and on-premise POS: what it is, and why cloud tools can't read it
If your point-of-sale runs on a computer in the back office and keeps its data in a database on your own network, most cloud tools cannot see a single number in it. This page explains what a legacy or on-premise POS is, names the common systems that fit, and shows plainly why the platforms skip them. It then documents the read-only design StoreRounds intends to test through approved pilots, not a connection available today.
Written for the owner, not the engineer. No decision on this page needs a developer. If your POS is fully cloud-based instead, you want the cloud connection guide, and the first section below tells you how to tell which one you have.
What it answers
Why the platforms skip youAnd what a safe read-only pilot would need to prove before touching real data.
Where it goes next
Pilot planning, not setupApply first. Do not create credentials or install software until an adapter is approved.
Running example throughout: a fictional two-store chain, Aurora Beauty Supply (Riverside and Eastgate). Every number and store shown is made up for the example. Your screen shows your real stores.
First, the plain definition
What counts as a legacy or on-premise POS?
On-premise means the software and its data live on hardware you own, inside your store, usually a back-office PC or a small server in the stockroom. The registers up front talk to that machine over your local network. Nothing about the day's sales has to leave the building for the POS to keep working, which is exactly why it keeps ringing sales when the internet drops.
Legacy usually means an older system that still runs the store well but no longer gets much attention from the company that made it, and sometimes none at all. The two overlap heavily. Most legacy retail POS is on-premise, and most on-premise POS in a small chain is now a few years old. If either word describes your system, this page is about you.
On-premise or server-based
This page. The on-prem SQL guide connects it.
- Your sales data sits in a database on a computer in your store, commonly SQL Server or MySQL.
- Registers connect over your local network, not the open internet.
- You sign in to the software on that machine, not to a website.
- Backups are a file on a drive or a network drive, not an account in the cloud.
- Reports usually open on one specific computer in the store.
Cloud-based
A different guide. It uses a sign-in, not a database user.
- Your data lives on the vendor's servers, reached through a website or app.
- You sign in at a web address from any phone or laptop.
- The vendor exposes a public API, so other services can connect once you allow it.
- Examples in wide use: Square, Shopify POS, Clover, Toast, Lightspeed cloud editions.
- If this is you, use the cloud connection guide instead.
A ten-second test
Not sure which one you have? Two quick checks settle it. If your sales reports only open on one particular computer in the store, and the POS keeps ringing sales when the internet is down, it is almost certainly on-premise. If you run reports by signing in to a website from your phone and the registers stop when the internet does, it is cloud.
Naming names, fairly
Which POS systems store their data in an on-premise SQL database?
Here are common systems whose on-premise or server-based versions keep their data in a local SQL database. This is not a knock on any of them. Several ran reliable stores for a decade or more, and a few still do. The only thing that matters for connecting is where the data sits, because that is what decides how it can be read.
| POS system | Database engine | Vendor status | StoreRounds production status |
|---|---|---|---|
| Microsoft Dynamics RMS / Store Operations | Microsoft SQL Server | Discontinued. New sales ended around 2016, support ended in 2021. | Not generally available |
| NCR CounterPoint (CounterPoint SQL) | Microsoft SQL Server | Active. On-premise deployments are common. | Not generally available |
| QuickBooks Desktop Point of Sale | On-premise database† | Discontinued by Intuit on October 3, 2023. Still runs on your own. | Not generally available† |
| pcAmerica Cash Register Express (CRE) | Microsoft SQL Server (local) | Server-based. Widely installed in small retail. | Not generally available |
| Retail Pro | Oracle, SQL Server, or MySQL‡ | Active. On-premise editions in wide use. | Not generally available‡ |
| Many regional and older systems | SQL Server or MySQL | Varies. | Not generally available |
† QuickBooks Desktop POS keeps its data on the store machine, but not in SQL Server or MySQL. ‡ Retail Pro can run on Oracle, SQL Server, or MySQL depending on edition and version. These engine facts help scope a pilot; they do not establish StoreRounds support. StoreRounds has no generally available production adapter for any named system in this table.
The through-line
Whatever the brand on the box, the pattern is the same: a database on a computer in your store, holding the sales your registers wrote to it. Microsoft SQL Server or MySQL / MariaDB can be candidates for a read-only pilot, but the engine alone does not make an adapter production-ready. StoreRounds must inspect the schema, agree the exact scope, and prove read-back on the real system before claiming support.
Sources for the system facts above: Microsoft Dynamics RMS end of life and its SQL Server storage, Retail Realm and nChannel; NCR CounterPoint on Microsoft SQL Server, One Step Retail Solutions; QuickBooks Desktop Point of Sale discontinuation, Intuit; pcAmerica Cash Register Express local SQL database, International Point of Sale; Retail Pro database options, RIS / Retail Pro Prism. Vendor names and marks belong to their owners and are used here to describe the systems, not to imply any endorsement.
The honest reason
Why can't cloud platforms and analytics tools reach an on-premise POS?
Because the data has no public address. Everything else follows from that one fact. Here is the proposed pilot pattern: a cloud tool has nowhere to send its request, while a local read-only connector could read from inside the network and send only outward. StoreRounds has not generally released this adapter.
Three plain reasons, in the order they bite:
- There is no public address to connect to. The database sits on a computer inside your own network, behind your router and firewall, with a private address like 10.0.0.20. Nothing on the public internet points to it, on purpose. A cloud service has nowhere to send its request.
- There is no sign-in to grant. Cloud tools connect by having you sign in to your POS and approve access through the vendor's public API. A legacy on-premise POS ships no such API, and several of these systems are no longer supported, so no new way to connect is coming from the maker.
- "Connect your POS" almost always means a cloud POS. When a new analytics or store-ops tool offers to connect your POS, it means connect your cloud POS account. If your POS is a program on a back-office PC, there is no account to hand it, so the tool quietly skips you.
Fair to the platforms
This is not a criticism of the cloud platforms. A cloud POS is a fine answer for a new store, and its open API is a genuine strength that many good tools build on. The point is narrower, and it is about architecture, not quality: a service that only speaks to other cloud services has no path to a database sitting in your back office.
That is the exact store the market tends to leave behind when it ships another "connect your POS" feature. It is also the case StoreRounds intends to prove first, one approved adapter and real-store read-back at a time.
The obvious question
Isn't the simplest answer to switch to a cloud POS?
Sometimes, yes, and we will say so plainly. If your hardware is failing or your vendor has gone dark and unsupported, moving to a modern cloud POS can be the right call, and no software should talk you out of a move that is genuinely better for the store.
But for many chains it is a real project, not a quick fix. You retrain every cashier, move or abandon years of sales history, rebuild whatever integrations you have, and take on the risk of a rough first week across every location at once. Plenty of stores run on a system that still works fine and simply want to see their numbers each morning without replacing the register floor first. A StoreRounds pilot would test whether a read-only path can serve that need before any migration decision. Portability across a future migration remains a product goal, not a proven production promise.
What reads it instead
How would a StoreRounds on-premise pilot connect?
The proposed design uses a small connector on an approved always-on machine inside the store network. It would sign in as a narrowly scoped read-only user, read only the tables approved for that pilot, aggregate the agreed daily totals, and send them outward over TLS. No named production build is generally available today.
Two controls would carry the trust: local database access over the store's own network, and an outbound-only connection with no new inbound rule. An approved pilot must prove those controls through grants, network observation, logs, and read-back before the store relies on a Morning Flash.
Receipts from minute one
The detailed guide
Review the proposed SQL Server or MySQL pilot path
A pre-production planning walkthrough for the grants, connector review, store matching, and read-back evidence an approved pilot would need. Do not run it as a live install guide.
An approved pilot would begin with one closed day of test or agreed store data and a comparison against the store's own Z-report. A connection may be called Verified only after that independent read-back reconciles. This gate has not been passed for every named POS on this page.
For your IT person
If a technician or managed-services provider needs to review the proposal, hand them the pre-production connector security template. It lists the controls and evidence an approved pilot build must satisfy; it is not proof that a production connector already does so.
Quick answers
Frequently asked questions
My POS is not on your list. Is it still on-premise?
Very likely, if its data lives in a database on a computer in your store and the system keeps working when the internet is down. That architecture can make it a candidate for a pilot, but StoreRounds cannot infer support from the database engine alone. Apply with the POS name and version so the schema and safe access path can be assessed before any credentials are created.
Do I have to move off my current POS to use StoreRounds?
Not necessarily. The proposed pilot path is meant to test read-only access to the POS you already run. Whether that path is feasible and safe depends on the exact product, version, database, and schema; no named production adapter is guaranteed today.
What if some stores are cloud and some are on-premise?
That is common, especially after an acquisition or a slow rollout. A unified morning view is the intended product direction, but StoreRounds has not generally released a universal mixed-POS adapter layer. Each cloud and on-premise source must be assessed and proven separately in an approved pilot.
Is it safe to let it read my database?
A safe pilot would require a read-only user scoped to named tables, explicit write denial, no inbound port, and direct IT verification. Those are design requirements, not a blanket security claim about an available connector. Review the pre-production security template and the actual pilot build before approval.
Which database engines does the connector read?
None is generally available as a named production adapter today. SQL Server and MySQL or MariaDB are candidates for the proposed pilot design, but the exact POS schema and safe access path still have to be inspected and proven. Oracle and QuickBooks Desktop Point of Sale require different work and are not promised.
Is my legacy POS a security risk on its own?
An unsupported system that no longer gets patches is worth reviewing with your IT person regardless of StoreRounds, and moving to a supported POS may be the right long-term call. A proposed outbound-only, read-only connector is not automatically safe; IT must inspect the actual pilot build, destination, grants, logs, retention, and revoke path before it touches real store data.
Founding pilot applications
Apply before creating any connection
You can read this guide without an account. If the legacy-POS problem fits your chain, apply for the founding pilot. StoreRounds will first assess the exact POS, version, schema, and safe adapter path. Applications do not open an account, subscription, setup screen, or production connector.
A portal account does not unlock a legacy POS adapter. Do not install software or create credentials until StoreRounds confirms an approved pilot.
Apply for the founding pilot Review the pilot planning guide