Dataverse Consulting: Architecture, Licensing & Migration
Dataverse is the best data platform most Power Platform teams aren't using — and the most expensive mistake some teams didn't need to make. Both statements are true, which is why "should we use Dataverse?" deserves a better answer than a feature list.
Here's ours, in plain terms: what Dataverse actually is, when it's the right call, when it isn't, what the licensing really means, and how to get there from Access, SQL, or the SharePoint lists you've outgrown.
What Dataverse actually is
With SharePoint lists or a homegrown SQL database, your app carries the burden of enforcing security and integrity. With Dataverse, the platform carries it.
Dataverse is the managed data platform under the Power Platform and Dynamics 365. Not a database you administer — a data service you consume: tables with real data types, relationships, and business rules; row-level and column-level security tied to Microsoft Entra; auditing, offline support, and a proper API. Model-driven Power Apps require it. Copilot and agent scenarios increasingly assume it, because its security model is exactly the "grounding" that safe AI needs.
The mental shift matters: with SharePoint lists or a homegrown SQL database, your app carries the burden of enforcing security and integrity. With Dataverse, the platform carries it. That's what you're paying for — and why paying for it only makes sense when you need it.
When Dataverse is the right call
- The data is relational and the relationships matter. Orders and line items, cases and contacts, assets and inspections. Lists make you fake relationships; Dataverse makes them real and enforces them.
- Security is row-level or role-based. "Managers see their region's records" is a configuration in Dataverse and a fragile workaround everywhere else.
- More than one app or process touches the same records. Dataverse gives you one governed source of truth instead of three drifting copies.
- You need audit trails, business rules, or offline use. Built in, not bolted on.
- Agents will ground on this data. An agent inherits the security model of its source. Dataverse gives it one worth inheriting — this is the Ground rung of our Grounded Agent Ladder.
When NOT to use Dataverse
An honest Dataverse page needs this section, so here it is.
- A simple tracker with a handful of columns and light security. A SharePoint list is free with the licenses you own and does the job. Don't buy premium licensing to store a lunch-order sign-up.
- Document-centric work. Files, metadata, co-authoring, and retention belong in SharePoint. Dataverse references documents; it shouldn't replace the document platform.
- Heavy analytical or warehouse workloads. Dataverse is an operational store. Reporting marts and large-scale analytics belong in SQL or Fabric, with Power BI on top.
- An existing SQL application that's working. "Migrate to Dataverse" is not a default. Sometimes the right architecture is SQL staying put behind a connector or virtual tables.
- Budget reality. If premium licensing genuinely doesn't fit the value of the workload, forcing it breeds resentment and shadow workarounds. We'd rather design the best standard-license solution than the wrong premium one.
If we look at your scenario and Dataverse isn't warranted, that's what you'll hear. Advice you can trust in one direction has to be trustworthy in the other.
Licensing in plain English
Nobody loves this topic, so here's the shape of it, minus the jargon.
- Standard Power Platform licensing (what comes with Microsoft 365) covers apps and flows on standard connectors — SharePoint, Excel, Outlook. Dataverse is not included in that tier, beyond limited use inside Teams.
- Premium licensing unlocks Dataverse and premium connectors. It comes in two shapes: per-user (a person uses any number of apps) and per-app (a person uses one app). Which is cheaper depends entirely on how many apps each person touches — this is the calculation most teams skip and later regret.
- Capacity is metered. Dataverse storage comes in database, file, and log buckets with a tenant baseline; growth beyond it is purchasable. Architecture choices — what you store, what you archive, where documents live — directly drive this line item, which is one more reason documents belong in SharePoint.
- Dynamics 365 licenses include Dataverse. If you already own Dynamics, some of your Dataverse cost may be sunk — worth checking before buying anything.
We'll model your actual scenario in real numbers during an engagement. What we won't do is quote generic prices here that Microsoft may change, or pretend licensing is simpler than it is. And our recommendations are never driven by license quotas — the answer isn't shaped by what it sells.
Getting there: migration paths
From Microsoft Access.
The classic. Aging Access databases running real processes on someone's desktop. The path: rationalize the schema (Access apps accumulate decades of cruft), map to Dataverse tables and relationships, rebuild forms and reports as a model-driven Power App and Power BI, and migrate data with validation runs before cutover. The redesign is the value — a straight lift-and-shift of a messy schema just relocates the mess.
From SQL Server.
Two options. Full migration to Dataverse when the app layer is being rebuilt anyway and the platform benefits pay for the move. Or coexistence — SQL stays authoritative, surfaced through connectors or virtual tables — when the database serves other systems or the migration cost outweighs the benefit. We recommend per workload, not per ideology.
From SharePoint lists.
The most common and the gentlest: schema redesign from list columns to proper tables and relationships, security model design (this is usually the big upgrade), data migration with cleansing, and repointing or rebuilding the apps and flows on top. Often done in stages, workload by workload.
From Excel.
Less a migration than a rescue. The spreadsheet becomes the requirements document; the discipline is deciding what the data model should have been all along.
How we deliver
Dataverse work follows the IMP0WER GRID: Gauge the current estate and its data sources, Route the target architecture — tables, security roles, environment strategy, integration pattern — then Install against the Ø Standard (named owners, no personal credentials, a Dev/Test/Prod path, documentation a stranger could operate from) and Distribute with monitoring and support. Architecture decisions get written down with their reasoning, so the next architect isn't guessing.
A founder leads every engagement, extended by the IMP0WER delivery team. We've been building on Microsoft data platforms since 2008; Dataverse decisions are foundational, and we treat them that way.
Frequently asked questions
Is Dataverse a database?
Functionally yes, formally it's a managed data service: tables, relationships, and business logic without servers to patch or backups to script. You give up low-level control; you gain a security and governance model no team builds this completely on its own.
Is Dataverse for Teams enough for us?
Sometimes. It's a useful limited tier — Dataverse capabilities scoped inside a team, without premium licenses. Its ceilings (capacity, features, sharing scope) are real, so treat it as a proving ground: pilot there, promote to full Dataverse when a solution earns it.
Can Power BI report on Dataverse?
Yes, cleanly — and for heavier analytics, Dataverse integrates with Fabric so you can analyze data without hammering the operational store. Operational data in Dataverse, analytics in the lakehouse, Power BI on top is the pattern.
How disruptive is a migration from lists or Access?
The workhorse answer: build and validate alongside the old system, migrate data in rehearsed runs, cut over when parallel results match. Disruption concentrates in the data-cleansing phase — which surfaces problems you already had, now visible.
Do we need Dataverse for Copilot and agents?
Not universally — agents ground on SharePoint content too. But when an agent needs structured business data with per-row security, Dataverse is the natural grounding source, and several Copilot Studio patterns assume it.
What does it cost to get this wrong?
Rebuilding. Estates that chose lists for relational workloads — or bought premium licensing they didn't need — end up paying twice. A short architecture engagement before you commit is the cheap insurance.