Your Business Data Should Outlive Your POS Provider

Picture a group of five restaurants that has been trading for five years. Somewhere in its POS system sit more than nine thousand days of trading across those sites: every Friday rush, every wet August, every menu change and what it did to the margin.

Then the operator decides to change POS provider. There are good reasons to. The new system might have better hardware, fairer pricing, stronger multi-site management or an integration the old one never offered. The menu gets rebuilt, the tills are configured, the staff are trained. On the first morning the new system records every sale perfectly, starting from zero.

Not every migration goes this way. Plenty of providers let you export your history, and some operators keep a login to the old reporting portal for a while. But a folder of CSV files, and a portal you'll eventually lose access to, are not the same as being able to answer, in one place, the question someone in your business asks every week: what should we order for next Friday? Answering it well means looking at last Friday, the same Friday last year, and how that week has shifted over time. If half that history sits in one system and half in another, recorded differently, the answer gets worse, or the question stops being asked.

I believe a hospitality business's history should belong to the business, in a form it can keep using, whichever software is recording it this year. And "what happens to my data if I leave?" should be asked before a POS contract is signed, not after.

How we got here

Databiite started from two directions. My co-founder, Chris, spent around a decade selling POS software into hospitality. He saw onboarding up close: menus rebuilt by hand, reports recreated, staff learning unfamiliar screens in the middle of service, and historical reporting left behind in the old system. He also knew that transaction data has a commercial value of its own, and that the venues producing it rarely see any of it.

I came at it as an engineer. I'd been working with cloud infrastructure and was struck by how cheap it had become to store large amounts of data and analyse it quickly. Things that once needed a dedicated data team and a serious budget could now run for very little. Our hypothesis was simple. If that's true, it should be possible to collect transaction data from many different POS systems, put it into one consistent shape, keep it safe and make it useful, at a cost a single independent site could bear.

That matters because the gap is stark. A large hospitality group has data engineers, analysts and a platform built to answer questions about purchasing, staffing, pricing and expansion. An independent, or a group of five sites, faces the same decisions with a spreadsheet and whatever reports the till provides.

We didn't start with a grand plan to standardise hospitality data. The bigger questions in this essay came out of building integrations one provider at a time and discovering how differently each one describes the same business. That's where my previous career turned out to matter more than I expected.

A lesson from construction

Before I wrote software, I spent about eight years in construction. I started as a BIM researcher with a specialist subcontractor working on nuclear projects, in a role shared with a university. I then became a BIM coordinator at a mechanical design engineering firm, and after that a BIM coordinator, information manager and surveyor at a tier one contractor.

BIM stands for Building Information Modelling. Most people picture 3D models, but the harder and more valuable part is the information: making sure that what's known about a building during design and construction is still usable by the people who run it for the next thirty years.

The UK government pushed this hard. Its 2011 Construction Strategy committed to requiring fully collaborative 3D BIM, with all project and asset information held electronically, by 2016. From April 2016 that became the BIM Level 2 requirement for centrally procured government projects. Standards described how to do it: PAS 1192-2 set out how project information should be managed, and has since been replaced by the international ISO 19650 series. It was a requirement on centrally funded work, not a law for the whole industry. In my experience, though, its influence spread well beyond those projects.

A lot of my work was at the unglamorous end. Picture the facilities manager of a public building who needs to replace a failed light fitting or door closer. They shouldn't have to dig through drawings or ring three contractors to find out what was installed. To make that possible, we sat down with building owners and operators to understand what they needed at handover. Every asset then had to be classified properly, using systems such as Uniclass 2015 and NRM, and described in a consistent structure. Much of that information was handed over through COBie, a structured spreadsheet format designed for exactly this purpose. It also had to be compatible with IFC, an open standard for describing building information that doesn't belong to any one software company.

Early on, it was laborious. We entered data into spreadsheets by hand, wrote scripts to check the formatting, and chased manufacturers for technical details that should have existed but often didn't. The standards told us what shape the information should take. They couldn't make anyone supply it accurately. IFC on its own did not solve interoperability, and anyone who worked with it will tell you the quality of what flowed through it varied enormously.

What changed things was incentives. I remember a meetup where a manufacturer described putting their product models into an online library that designers used, and said their inbound enquiries had risen sharply as a result. If your product arrives in the designer's software complete and correctly described, it's easier to specify than one that doesn't. Sanitaryware manufacturers were among the first I saw take this seriously.

Meanwhile the software improved, designers caught clashes before anything was built, and building owners began to expect structured information as standard. No single factor did it. Together they changed what the industry regarded as normal.

The lesson I took from all this is that interoperability doesn't spread because it's technically elegant. It spreads when it starts to affect who wins work.

Exporting data is not the same as keeping it

Hospitality has its own version of the problem. Different POS systems describe the same events, such as a sale, a refund or a discount, in their own way.

Take a pint of lager. Imagine one system records it as "Lager Pint" in a category called Draught. Another calls it "House Lager (Pint)" under Beer, records a half as a separate product, and logs a staff discount as its own line rather than a lower price. Both records are perfectly valid. Put them side by side, though, and a simple question like "how much lager did we sell this year compared with last?" becomes surprisingly hard to answer.

It helps to separate four things that often get lumped together as "keeping your data":

• Getting it out. Can you extract your transactions from the old system at all, and in how much detail?
• Putting it into a consistent shape. Can records from different systems be arranged in the same structure?
• Making it mean the same thing. Once they share a structure, can you trust that "a pint", "a refund" or "net sales" mean the same thing on both sides of the switch?
• Moving it into the new till. Can your new POS import your history so it appears in its own reports?

These are different capabilities, and a provider can do the first well and none of the others. A shared format doesn't automatically create shared meaning. Two files can have identical columns and still disagree about what's in them.

Here's where Databiite sits today. We connect to a growing number of POS systems, bring in an operator's past trading as well as new sales, and translate it all into one consistent model. If you switch provider, last month's trading from the old system and this month's from the new one sit side by side and can be queried together, so your history carries on. It's free for operators, and you can export everything and leave whenever you like. We don't push that history into your new till; that's a different job. And to be candid, our common model is currently a standardised way of classifying sales for reporting, not a complete description of what every product means. Richer product classification, and formal testing of how well each provider's data maps across, are things we intend to build, not things we've finished.

Why consistent foundations matter

There's a well-known example from another field of what happens when data is organised consistently at scale. In 2009, Fei-Fei Li and her collaborators published ImageNet, a collection of millions of images arranged under a structured hierarchy of concepts drawn from WordNet, a database of English words and their meanings. Its value wasn't only its size. Every image was labelled within the same structure, so researchers anywhere could train systems on the same data and measure them against the same test. The annual ImageNet challenge, which ran from 2010 to 2017, became the standard benchmark for computer vision, and the 2012 entry that showed what deep neural networks could do is widely seen as a turning point for the field.

ImageNet didn't create modern AI on its own. And a restaurant's sales are nothing like public photographs: they're commercially confidential, and they need to be handled with care. But the lesson travels. When every business keeps its data in isolated, incompatible shapes, some questions simply can't be asked. Put that data on a consistent foundation, and it becomes possible to answer questions nobody had in mind when it was collected.

Could portability change how POS is bought?

Construction had a government mandate. Hospitality doesn't, and I don't expect one. If portability is going to matter, operators and their advisers will have to make it matter.

The obvious objection is that POS providers have little reason to make leaving easier. That's true for any one provider looking at its own customers. But every provider is also trying to win customers from somebody else, and a switch that doesn't cost an operator their history is an easier sale. Chris saw that from the sales side. Removing a reason not to switch helps the challenger, and in a competitive market everyone is the challenger somewhere.

We've started thinking about a public directory recording what each provider supports: historical exports, automatic collection, basket-level detail, how completely it maps onto a common model, and whether migration into another system has actually been demonstrated. In time, that could be independently verified. It's an idea, not a product, and whether providers would welcome it is an open question. But in construction, once structured information began to influence which products were specified, manufacturers moved quickly. I'd like to see what happens when a POS provider can win a deal because its data is easy to take with you.

Another fair objection: why not just use an analytics tool? You can, and good ones already connect to several POS systems. If one works for you, use it. The question I'd still ask is whether your history now lives in a form you control and can take with you, or whether it just depends on the analytics vendor instead of the POS vendor. Moving the lock-in isn't the same as removing it.

What becomes possible

Go back to the five-site operator, now weighing up a sixth site and perhaps ten within a few years. Where to open, how each site really compares, what to stock or drop. And the till that suited five sites may not suit ten.

The future I want is one where that operator's trading history stays continuous and comparable through all of it: new sites, new menus, a new POS provider. In time, they should be able to ask questions of it in plain English, including through AI assistants, without hiring a data team. And, with their agreement and proper safeguards, they can see how they compare with similar businesses.

There's one more piece, and I want to be careful with it. Hospitality transaction data has commercial value. Suppliers, brands and investors want to understand what's selling, where and when. Smaller operators rarely share in that value in any direct way. We're building a model where they can.

Here's where it actually stands. Each venue explicitly confirms whether its data can be included in the anonymised, combined layer that data buyers will eventually query. Anonymisation alone doesn't remove every risk. A single venue's trading pattern can be commercially sensitive even with its name stripped off, so we also refuse any query that would draw on too few businesses for any one of them to be picked out. The mechanism for sharing revenue with contributing venues is built and tested, but only on synthetic data. We're growing a founding group of venues to 2,000 locations before any data buyer is allowed to query, so no venue has been paid yet. Whether the returns turn out modest or significant is something we'll learn, not something I can promise. My long-term hope is that, for some operators, it could offset a real share of what they spend on technology.

The question worth asking

If you're choosing a POS provider in the next year or two, add a few questions to the list alongside price and hardware. What happens to my history if I leave? Can I get it out at the level of individual transactions, or only as summaries? Will it still mean the same thing once it's somewhere else? And who else benefits from it while I'm here?

You've spent years building your business. Its history should outlast whichever system happens to be recording it. And perhaps, one day, it could help pay for that system too.