How to manage Dataverse's capacity limits, how to export all your data completely out of Dynamics 365, and how a migration to an open, in-house data layer runs without data loss.
Dynamics 365 brings the Power Platform, Dataverse, and a licensing model that charges per app, per user and per gigabyte, one that after a few years nobody can see through anymore.
Dataverse's capacity limits can be managed with cleanup and archiving, and the best archive destination, a database of your own, is immediately the first step toward in-house management.
Every table is reachable through the Web API, you just need to convert the internal codes into readable values and keep the relationships intact.
A migration to an open, in-house data layer is not a leap into the unknown, with a test migration and a period of running in parallel before anything gets cancelled.
For many companies, Dynamics wasn't a choice made from a comparison, but the logical extension of the Microsoft house. The organization was already running on Outlook, Teams and Office; the CRM from the same vendor felt like the safe route, and the integration with email and calendar did indeed work from day one. An implementation partner set it up, and it worked.
That strength is also the weakness. Dynamics isn't a stand-alone product but a gateway to an ecosystem: Dataverse as the data platform, Power Apps and Power Automate around it, licenses that stack per app and per user, and customizations that only the partner still understands. Every improvement runs through that ecosystem, on its terms and at its rates. What started as the safe choice has, for many SMEs, become an environment nobody internally still oversees.
Dynamics' bill consists of three layers that rarely appear on a single overview.
Sales, Customer Service, Marketing: every app has its own licenses, with base and attach variants per user and add-ons on top of that. The model is so fine-grained that even vendors have specialist advisors for it. In practice that means: every new wish is a new licensing question, and the annual invoice quietly grows along with it.
All Dynamics data lives in Dataverse, and its capacity is capped per tenant: a base amount of roughly ten gigabytes of database capacity, topped up with small allowances per license. Records, attachments and logs all count toward it. Extra capacity is bought per gigabyte per month, at rates that over a year add up to a multiple of what the same storage costs elsewhere. A growing company with an active sales team sees that meter run faster than expected.
An extra field, an adjusted report, a flow that broke after an update: in theory you could do it yourself, in practice it runs through the implementation partner. That's not the partner being unwilling; the platform has simply become too complex to handle on the side. The result is a structural dependency that no invoice ever calls "lock-in", but that's exactly what it is.
Every new wish is a new licensing question, and the annual invoice quietly grows along with it.
No licenses per app and per user, no capacity per gigabyte.
Even if you're staying with Dynamics for now, you don't have to accept the capacity bill as it is. Three strategies, increasing in effect.
Audit logs, workflow history and activities completed long ago take up quiet space. Structural cleanup often frees up a surprising amount of capacity and makes the environment clearer. Do this before anything else: it's also the first step of any good migration.
Files and email attachments are big consumers of the most expensive capacity category. Move them to cheap document storage, keeping only a reference in Dynamics. That saves immediately.
The structural solution: move closed records, old activities and history to a PostgreSQL database of your own, where storage costs next to nothing and everything stays searchable. This is the most interesting strategy, because that archive database is effectively already an in-house data layer. Once you have it, you usually discover quickly that reporting and AI applications run more easily on it than on Dataverse itself. The rest of this whitepaper is the logical next step of exactly this idea.
Your data comes out of Dynamics completely, but not all of it by the same route. Here are the routes.
Nothing on this list is secret or held back: Dataverse cooperates cleanly with export. The difference between a complete migration and a crippled one isn't about access, it's about knowing these routes, converting codes into meaning, and checking the result.
The export is half the work. The other half is the transfer itself, and that's where migrations that looked right on paper go wrong. Five rules that make the difference.
First accounts, then contacts, then opportunities, then activities and attachments. Keep a mapping per record of old GUID to new ID, so every relationship is traceable and every mistake recoverable.
Everything to a test environment. Recount per table: the same number of accounts, contacts and opportunities as in the source. Spot-check the relationships and the odd cases, such as records of former employees.
The best moment to deduplicate and normalize: you're already looking at every table anyway. Document what you deliberately leave behind, so "gone" never means "lost".
The new environment proves itself alongside Dynamics with real reporting, while new records flow in and Outlook and Teams stay connected. Only once the team trusts it do you wind down licenses.
Flows, plugins and customizations aren't exportable. A good share of them existed just to work around Dataverse's data model. Rebuild what your process actually needs and leave the rest out.
Where do you migrate to? And Repeat's answer isn't another package, because then you're just moving your lock-in. The answer is an AI Native Data Layer: an open, central data layer on PostgreSQL, fully in-house, to which all your business software connects.
Your customer data forms the foundation. On top of it, solutions get built that you're used to from Dynamics, but built around your own way of working: pipeline and follow-up, dashboards, AI chat that answers questions about your own customers, agents that take over routine work. And the Microsoft convenience stays: Outlook, Teams and calendar get connected to the data layer, so you keep the house but get the foundation back.
The cost model shifts with it, as the overview in chapter 2 shows. And because the data layer is open and portable, you can always take it with you. Away from us too; that keeps everyone sharp. How that platform fits together is covered in full in the whitepaper on the AI Native Data Layer.
| aspect | dynamics 365 | in-house |
|---|---|---|
| cost | Licenses per app and per user, with attach licenses and add-ons | Low, predictable infrastructure costs, regardless of user count |
| storage | Dataverse capacity per gigabyte per month, with a tight base allowance | Virtually unlimited at regular database costs |
| customizations | Through the Power Platform and the implementation partner | Built around your way of working, changes in days |
| access to your data | Through APIs and export routes within the platform | Direct: it's your database |
| ai on your customer data | Through Copilot licenses and the limits of the platform | Every AI application connects directly to your own data layer |
| ownership | Renting access to your own customer history | Data, environment and history are fully yours |
Europe saw the switching problem and turned it into legislation. The Data Act obliges cloud service providers to make switching practically possible: handing over your data in a common, usable format and not obstructing the switch. From 12 January 2027, no switching costs may be charged for this either.
For anyone on Dynamics, that means: the door will soon legally stand open. But a law doesn't export your data and doesn't build your new environment. Whoever wants to be free to choose in 2027 would do well to get to know their own data now and explore the route. More on this in our article on the Data Act and switching costs.
Every good migration starts with knowing what you have. That's why the first step is always a data scan: we look at your environment together and map out which tables and volumes exist, which flows and customizations are running, and what the quality of the data is. With a test export, we show you what your data looks like in an open data layer.
After that you know exactly where you stand: what needs to come along, what can be cleaned up, and what the migration involves. Even if the conclusion is that staying put is the best choice for now, because that happens too, you'll have a documented picture of your own data. That's never wasted work.
And Repeat helps SMEs bring their data and software in-house, with an AI-native data layer as the foundation. Migrations out of CRM packages such as Dynamics 365 are a logical part of that: the data already exists, it just needs to go back to its owner. One conviction runs through everything: your data and your software should belong to you, not to a vendor.
Book a no-obligation data scan. We'll map out your environment and show you, with a test export, what your data looks like in-house. Honest advice, even when that's "stay put for now".