We all know that you own your data. You own what you do with it. You need it to run your business. You rely on it. Your vendor says it’s yours. Everyone agrees that it belongs to your company. Awesome.
Can you take that data to another provider, start using it, and resume normal operations? What about the business definitions, access policies, reports, and everything else your team has built around it? Or does leaving mean paying to extract your own data, then spending months rebuilding the systems you need to use it?
Ah, now we see the part of the bog where vendor lock-in sucks your feet in. Owning your data and being free to do what you want with it aren't exactly the same thing.
An open data architecture can give you more control over your options. But simply seeing the word open on a vendor's website isn't enough. You need to know what's open, what isn't, and what happens when you want to make a change.
You own your data. So why can't you leave? Vendor lock-in doesn't always start with a bad contract or a provider deliberately making things difficult. Sometimes it develops because a platform works really well.
Your team builds reports using the vendor's tools. They create data definitions, set access permissions, connect applications, and develop processes around the platform. Over time, more of your business depends on those decisions.
Then something changes. Could be the pricing no longer works for you, or another provider has capabilities your business needs. Maybe your company wants to bring in a different AI platform.
Whatever the reason, the decision is made. You need to move.
That's when you find out which parts of your data environment can come with you and which parts have to be rebuilt.
|
Where lock-in develops |
What happens when you try to leave |
|
Data and storage |
Your files may need conversion, copying, or a paid transfer before another system can use them. |
|
Metadata and governance |
Business definitions, classifications, permissions, and other information may not move cleanly with the data. |
|
Reports and applications |
Queries, transformations, and integrations built around vendor-specific features may need to be rewritten. |
|
Contracts and operations |
Transfer charges, limited transition access, or unclear exit terms can complicate the move. |
Not every provider creates all these problems. And no architecture can guarantee that changing platforms will be effortless.
The point I’m trying to drive home is:
A collection of tables without the definitions, policies, and processes that make them useful may leave your team with a substantial rebuild project. You have the data, but you haven't brought the working environment with you.
What does an open data architecture actually change? An open data architecture is designed to reduce your dependence on any one provider. Instead of making every part of your data environment rely on one company's technology, it uses formats and interfaces that compatible systems can work with.
That doesn't mean every tool is interchangeable or that moving between platforms becomes a one-click operation. It means you have more options when something needs to change.
Start with the data itself. Open file and table formats let different systems work with data according to published specifications rather than a format controlled by a single vendor.
Apache Iceberg is one example. It defines how tables and their metadata are organized so compatible processing engines can work with them. If you change query engines, you may be able to keep using the existing tables instead of converting the entire dataset into a different format.
That's a substantial advantage. But Iceberg support alone doesn't answer every question about portability. Different systems can support different features, and the format doesn't automagically bring along every report, business definition, or access policy you've created.
Look at where the data lives and how systems find it. When storage and processing are separate, you may be able to change the engine running your queries without moving the underlying files. A new engine still needs permission to access the storage and a compatible way to find and interpret the tables.
That's where the catalog comes in.
https://iceberg.apache.org/spec
A catalog tells systems what tables exist and where to find their metadata. Iceberg has a published REST Catalog API that provides a common interface for compatible engines and catalogs. But a standard interface doesn't guarantee that every vendor-specific catalog feature or business definition will transfer unchanged.
And let’s not forget governance. Your data isn't much use if moving it means losing track of which fields contain sensitive information, who is allowed to access them, or how the data has been transformed.
Those rules and records need to be part of the exit discussion. Even if a policy can be exported, you'll still need to establish how the replacement platform will enforce it.
Open architecture reduces dependencies. It doesn't make the work surrounding your data vanish.
Before you sign, find out what happens when you leave. Most companies evaluate a platform based on what it can do for them today. Does it have the features they need? Will it work with their existing systems? What will it cost?
Those are reasonable questions. But there's another one worth asking before you commit: What happens if we decide this isn't the right platform for us anymore?
Don't settle for “You own your data” or “We support open formats.” Neither answer tells you enough about what leaving will involve.
Ask the provider to walk you through the exit process. Better yet, ask whether they can demonstrate that a compatible system can use a representative set of your data outside their platform.
If I were running your project, there are four areas I'd want covered:
1. The data. What formats are the files actually stored in? Can another compatible system read them directly, or does the vendor have to create an export first? Where will the data be stored, and what will it cost to move it?
2. The information surrounding the data. Can you take your schemas, business definitions, classifications, and catalog information? Will another system be able to make use of them, or will your team have to recreate them?
3. The work your team has built. What happens to transformations, reports, access policies, and audit history? Which parts can be exported, and which will need to be rewritten or reimplemented?
4. The exit itself. How long will you retain access after termination? What transition support is available? Are transfer charges and delivery formats documented? What happens if the migration takes longer than expected?
And if the provider says another system can use your data, you can always ask to see it work. A small test before you're committed can tell you more than a long list of supported technologies.
You don't have to plan a full migration on day one. You do want to understand what a future migration would involve while you still have choices.
We’re really talking about data independence without running everything yourself. And there is an obvious question here: if you want to avoid depending on a vendor, do you have to build and operate the entire data platform yourself?
No. Yep, that answer is no. The decision to use a managed service and the decision to retain control of your data are separate questions.
A managed provider can take responsibility for operating the platform without making your data dependent on a proprietary format or leaving you without a workable exit.
Spitfyre’s approach focuses on data independence. Our architecture is designed to avoid dependence on proprietary data formats or closed technology layers. Our portability promise covers the data itself, metadata, agreed governance artifacts and transformation logic, and structured audit history. It also calls for an exit plan that everyone agrees with before production use.
In other words, the exit isn't supposed to be a conversation you have for the first time when you've already decided to leave. That way lay madness.
This matters a hell of a lot more as companies bring AI models and agents into their data environments. You need to control which data those systems can access and retain the records needed to understand what happened. Changing an AI tool shouldn't mean giving up control of the data behind it.
Spitfyre's Data Independence principles use governed access for approved AI models and agents. They track access, queries, exports, approvals, and policy actions. The goal is to keep the data corralled while giving the organization choices about the tools it uses.
Of course, no provider can promise that every report, integration, or application you've built will work unchanged somewhere else. That's why the details of the portability agreement matter.
So before choosing a data platform, don't just ask who owns the data. Ask what you can take with you, what will still work when you get there, and what leaving will actually involve. You should be choosing a provider because you want to stay, not because leaving has become too difficult.