library · field guide

What if your software vendor disappears?

Companies get acquired, pivot to a new market, or quietly switch off the servers. It happens to good software and bad. The question worth asking before you commit years of your business to a system is not whether the vendor might vanish. It is whether, if they did, you could walk away with everything that matters intact.

the real question

The day the promise breaks.

Every vendor will tell you they're here to stay. None of them can promise it. So the test of a system is what you are left holding on the day the promise breaks.

the quiet trap

Lock-in is rarely a clause. It's a shape.

Nobody signs up for vendor lock-in. It is not a line in the contract you missed; it accretes quietly, in the shape of how the software stores what you give it. Five years in, your catalogue, your customers, your stock history, your invoices and your passports all live inside one company's system — and the question of whether you could ever get them back out was never asked, because everything was working.

Then something changes. The vendor is acquired and the product is "sunset". The pricing triples. The roadmap veers somewhere you don't need to go. Suddenly the only thing that matters is the one thing you never checked: can you leave, and what comes with you when you do?

For most business software the honest answer is "not easily". Data sits in a shape only the vendor's app understands; export is a screenshot or a PDF; the real records, the structured machine-readable ones, never leave the building. That is lock-in. No malicious clause, just a door that only opens inward. The remedy is to ask, before you commit, the questions you'd otherwise only ask in a crisis.

One container, or a slice of everyone's.

whose data is it

One container, or a slice of everyone's.

There are two ways a system can hold your records. Pooled, with every customer commingled inside one shared database and separated only by a column that says which rows are yours. Or apart, with each business running in its own isolated database. The difference is invisible while everything works, and decisive the day you want to leave.

When your records are pooled with everyone else's, "getting my data out" means asking the vendor to carve your slice out of a shared tangle, on their terms, in their timeframe, at whatever fidelity they choose. When your data sits in a database that is yours alone, the same request has a concrete answer: there is one defined thing to hand over. Ownership starts with not sharing the container.

Data that comes out in formats you already trust.

a door that opens out

Data that comes out in formats you already trust.

Ownership only means something if the data can leave in a form you can actually use. A good system lets the working records come out as ordinary, portable files: aging reports, pricing, stock and transaction histories streaming to Excel spreadsheets that open anywhere, with no special software and no vendor blessing required. The test is whether you get the real, machine-readable record, or a picture of it.

And where the law defines a format, a good system emits that legal standard rather than a private one. Invoices issued as structured electronic invoices to the national standard (in Italy, FatturaPA, transmitted through an accredited intermediary); plant passports carrying the EPPO-coded species identity the whole trade recognises. These are formats the industry already reads.

one place to leave from

You can only leave cleanly from one front door.

When your data is scattered across a dozen tools, there is no single thing to take with you. The first condition of a clean exit is having one source of truth to exit from.

The hardest businesses to move are rarely the ones tied to a single stubborn vendor. They are the ones whose information is smeared across a spreadsheet here, a webshop there, a till that doesn't talk to the office, and three apps that each hold a fragment of the truth. There is no "leaving" that, because there was never one place to leave from. Continuity quietly failed long before any vendor disappeared.

The remedy is the opposite shape: a system that stays the single source of truth, with satellite tools (a point-of-sale, a customer portal, a help library) each handling one slice of work and syncing back to the core. When your catalogue, stock, customers and money live in one place, there is one place to back up and one place to take with you.

Standards are an exit you don't have to negotiate.

portability by standard

Standards are an exit you don't have to negotiate.

The most durable form of data ownership is a standard. When your invoices are valid FatturaPA documents and your plant passports carry the internationally agreed EPPO code for each species, your most important records are written in a language that exists independently of any one supplier. Another system, an inspector, an accountant, a tax authority: all of them can read those records without asking the vendor's permission.

That is the difference between data you can see and data you own. A proprietary format ties the usefulness of your records to the survival of the company that made it. A standard outlives the vendor.

The questions to ask before you sign.

due diligence

The questions to ask before you sign.

You assess continuity the same way you'd assess any risk you can't eliminate: by asking the awkward questions while everyone is still friendly. Ask a prospective vendor plainly: Is my data in its own database or pooled with everyone else's? Can I export the full record, not just a report, and in what format? Do you use open or legal standards where they exist? If we parted ways tomorrow, what exactly would I be able to take, and how?

A vendor confident in their answer will give you a straight one. A vague reply, "you won't want to leave", is itself the answer. None of these questions are hostile; they are the same prudence you'd apply to a key supplier or a lease. The best time to ask them is before you have five years of your business inside the system, not after.

atlas core

How Atlas Core handles data ownership and vendor continuity

Everything above is vendor-neutral. For readers who want the concrete version, here is how Atlas Core is built against exactly these risks:

  • Single-tenant Instance: every nursery runs in its own separate database, never commingled with other businesses, so on the day you'd want to leave there is one concrete thing to hand over rather than a slice to untangle from a shared pool.
  • Structured exports in formats you already trust: aging reports, pricing, stock and transaction histories stream out as ordinary Excel spreadsheets that open anywhere: the real machine-readable records, not a PDF or a screenshot.
  • Records written in standards that outlive any vendor: invoices are issued as compliant FatturaPA electronic invoices through an accredited intermediary, and plant passports carry the internationally recognised EPPO species code — readable by any inspector, accountant, tax authority or successor system.
  • One source of truth you can pick up and carry: catalogue, stock, customers and money live in the Atlas Core, while companion apps (point-of-sale, customer portal, help library) each handle one slice and sync back.
  • Continuity by design, not by promise: because ownership is architectural, a vendor's fate stops being your business's fate.

Read further

See what owning your data actually looks like.

A field guide is one thing; seeing it in practice is another. Talk to us about exports that open anywhere, standards-based invoices and passports, and one source of truth you can always take with you.