Many organisations believe they own their data because they can export a CSV file. It is only when they try to switch systems that they discover the relationships, history, and business logic are still locked inside the vendor. Data ownership is not about having a copy of records. It is about controlling the structure that makes those records meaningful.
Owning your data means controlling the structure, not just holding a copy. A CSV export gives you the records but not the relationships between them: which member attended which event, which payment belonged to which dues period, which conversation led to which case. It is the connective tissue that is expensive to rebuild, and it often ties an organisation to a supplier long after the software itself could have been replaced. The test is concrete: can you read the data model, run your own queries against it, and take the relationships with you. If you can, a system change is a project. If you cannot, it is a reconstruction. The trade-off is real, because an open platform requires more design work up front than a finished proprietary solution.
What happens when you try to leave
When an organisation attempts to move member data out of an older system, they often discover that event history, payment history and communication are no longer connected. The data exists, but the relationships between them are gone. Rebuilding those relationships in a new system can cost more than the original implementation. That is the real lock-in.
The lock-in is not in the software
Vendor lock-in is often discussed as a software problem. But in practice, most organisations can replace software. What they cannot easily replace is the data structures, relationships, and institutional knowledge built up around that system over years. When your member records, case histories, financial transactions, and communication logs all live in a proprietary data model, the cost of leaving is not the licence fee for a new system. It is the cost of extracting, transforming, and migrating years of operational data.
We have seen organisations where membership history, payment data and event participation were stored in separate proprietary tables with no documented relationships. The export itself took hours. Reconstructing the data model took months. Some organisations spend more on data migration than on the entire new system implementation, simply because the old vendor stored data in a format designed to be easy to write into but difficult to extract from.
The vendor scenario nobody plans for
Consider what happens when your current vendor is acquired by a larger company that decides to sunset your product. Or when the vendor pivots to a different market and stops investing in the features you depend on. Or when the annual licence renewal arrives with an increase you have little room to negotiate, because the supplier knows how much work leaving would be.
These are not hypothetical scenarios. They happen regularly in the Nordic software market, particularly in the niche of association and membership management systems. Small vendors get acquired, products are merged, and the organisations that built their operations around those products find themselves negotiating from a position of weakness.
The question is not whether this will happen to your organisation. The question is whether you will be prepared when it does.
Open data models versus closed ones
The practical difference between an open data model and a proprietary one is not about ideology. It is about operational freedom. With an open data platform, your data lives in a structure you can inspect, query, extend, and export at any time. You can build reports on it with Power BI, connect it to other systems through standard APIs, and if you ever need to move, the data model itself is documented and accessible.
With a proprietary system, the vendor controls the data model. You may be able to export a flat file, but the relationships between records (the connections that make data meaningful) are often lost. A CSV of member names is not the same as a relational model that connects members to their cases, events, fees, and communication history. This is also where the question of which system should actually be the master register belongs.
The difference in one table
The operational freedom can be made concrete like this:
| Property | Open data model | Vendor-managed data model |
|---|---|---|
| Inspection | You can see how the data is structured; the model is documented and accessible | The vendor controls the structure; visibility stops at the export formats |
| Querying | Direct queries and reports, for example with Power BI against the platform | Limited to the reports and extracts the vendor offers |
| Extension | New entities and fields can be added without waiting for the vendor's roadmap | Changes go through the vendor and are shared across customers or priced as add-ons |
| Export | Full export with relationships intact, at any time, through standard APIs | Often flat files where the links between members, cases, events and payments are lost |
| Exit cost | Mainly migration and training cost; the data model comes along | Rebuilding lost relationships can cost more than the original implementation |
| Stewardship responsibility | Yours, internally or through a partner; you set the roadmap and pay for it | The vendor's; faster to start, but the roadmap and priorities are theirs |
Self-service analytics require data you own
Control over your own data is no longer just about migration. It is also about analysis, automation and AI. Microsoft Fabric and modern analytics platforms make it increasingly possible for organisations to build their own insights without depending on standard reports from the vendor. But self-service analytics only works when you have access to the underlying data in a structure you understand and control.
When your data sits in a proprietary system, the vendor decides what reports are available, what data can be exported, and what analysis is possible. When your data sits in an open model, your own team, or a partner working on your behalf, can ask any question the data can answer. That is a fundamentally different capability.
Transparency requirements make this urgent
For public sector organisations and membership bodies subject to accountability requirements, data ownership is not just a technical preference. It is a governance necessity. When auditors, boards, or members ask questions about how decisions were made, what data was used, and who had access to what, the organisation needs to be able to answer from its own systems, not by submitting a support ticket to a vendor.
Data governance (who owns what, who can access what, and how changes are tracked) becomes manageable when you control the data model. It becomes far harder when the model is undocumented and maintained by a third party.
The honest tradeoff
Choosing open data models is not without cost. Proprietary systems often deliver faster initial implementation because the vendor has made all the architectural decisions for you. An open platform requires more upfront design work: you need to define your data model, decide on naming conventions, and build the integrations yourself or with a partner. That tradeoff belongs early in a system evaluation, not after the contract is signed.
The question is whether you want to pay that cost now, when you have options, or later, when you do not. Organisations that invest in data ownership early find that each subsequent system decision becomes easier, because the data foundation stays, even when the tools on top change.
AI makes data ownership more important than ever
Many organisations are now discovering that they do not actually have access to the data their AI initiatives need. Proprietary data models limit what can be analysed, connected and used for predictions. Open data foundations make the organisation not just migration-ready, but AI-ready. Without accessible, structured data, even the best analytical models have nothing meaningful to work with.
Systems come and go. Vendors get acquired, products are phased out, and technology stacks change. Your data is the only thing that must survive all of these shifts. Organisations that understand this early build greater operational freedom, better analytical capacity, and lower strategic risk over time.
Frequently asked questions about data and system ownership
What is the difference between owning the data and owning the system?
Legally the organisation normally owns its own data regardless of supplier. What varies is technical control: whether you can read, change and move the data in a form usable outside the system, and whether you control the data model it sits in. The contract decides ownership, the architecture decides room to act.
What happens in practice when we want to change supplier?
The test is not whether you get an export file, but what the file contains. Does member history, consents, roles and activity come along, or only today's member list? Are the relationships between records preserved? This is where lock-in actually sits, rarely in the software licence.
What does an open data model mean concretely?
That the structure is documented and accessible, that you can connect your own tools to the data without going through the supplier for every request, and that export gives more than a flat table. The opposite is a model you cannot inspect, where every new integration becomes an order.
Why does AI make this question more pressing?
Because AI value follows data access. Models meant to say something useful about member engagement need history across dues, participation and communication. If that data sits scattered in systems you cannot connect to, AI becomes a demonstration rather than something used in operations.
Most organisations know what their systems cost. Fewer know what it would cost to leave them.
We work with organisations to assess where their data lives, who controls it, and what it would take to move. The goal is not to replace everything at once, but to understand your position and make deliberate choices.
Map your data ownershipSources
- Microsoft Learn: Use the Microsoft Dataverse Web API
- Datatilsynet: The right to data portability
- Microsoft Learn: Link your Dataverse environment to Microsoft Fabric
- Microsoft Learn: What is Microsoft Dataverse?
Sources retrieved and checked 30 August 2026.