Dataverse or SharePoint lists?

Use SharePoint lists until you need genuine relationships between records, row-level security, or real volume — then move to Dataverse, with eyes open on licensing. This decision sets your licence cost for years, so it deserves ten minutes of thought rather than a default. For most internal registers at a 50–500 person business, lists are the right answer; for the few apps that genuinely need a database, Dataverse is worth paying for.

What each one actually is

A SharePoint list is a table that lives in a SharePoint site. It has columns, views, version history and permissions inherited from the site, and every Microsoft 365 user who can reach the site can use it. Power Apps and Power Automate both read and write to it with standard connectors, which means no premium licence.

Dataverse is a proper relational database that sits behind the Power Platform. It has tables with defined relationships, security roles that control access down to individual rows, server-side business logic, and native auditing. Using it from a Power App — beyond the limited Dataverse for Teams option — requires a premium Power Apps licence for each user.

The difference is not quality. It is what the data needs to do and who pays for it.

Start with SharePoint lists when

• The data is essentially a register — requests, assets, bookings, incidents
• Relationships are simple lookups
• Volume is in the thousands, not hundreds of thousands
• Everyone who needs access already has Microsoft 365

This covers a surprising majority of internal apps, and costs nothing extra.

Typical examples: a plant and equipment booking app for a construction business, a leave or training request register, an incident log, a compliance expiry tracker, a vehicle allocation list. Each is one main list with a couple of lookups, a few hundred to a few thousand items a year, and access that maps cleanly to who can see the site.

Lists also have a practical advantage that rarely gets mentioned: your own staff can see and fix the data. An operations coordinator can open the list in a browser, sort it, export it to Excel and correct a typo. That matters when the person who built the app is not around.

Move to Dataverse when

• You need genuine relational structure — many-to-many, cascading behaviour, referential integrity
• You need row-level security, where users see only their own records
• You have real volume — the list view threshold stops being a nuisance and starts being a wall
• You need auditing of who changed what, natively
• Business logic must run regardless of which app touches the data

Examples that genuinely need it: a client case management system where workers must only see their own clients, which is common in for-purpose organisations; a project costing app where variations, cost codes, purchase orders and subcontractors all relate to each other; a field inspection app that must work offline on site and sync later; anything where a regulator or funder expects a reliable record of who changed which field and when.

The honest trade

Dataverse is the better platform. It is also a per-user licence for everyone who touches it. For 200 staff, that is a material annual cost — frequently more than the build.

Do the three-year sum before choosing. A SharePoint-list app at around $10,000 with no ongoing licence often beats a Dataverse app at $18,000 plus roughly $70,000 a year in licences, even though the second is architecturally superior.

The licence figure is the one to check. It depends on how many people genuinely use the app, which plan fits — per user, per app, or pay-as-you-go — and what Microsoft charges at the time. Our Power Apps licensing guide walks through the plans; the point here is that the licence line repeats every year, while the build cost does not.

The sum changes sharply when fewer people need the app. If only 15 schedulers and supervisors use a Dataverse app while everyone else just receives emails from it, the licence cost is a fraction of the 200-user case — and Dataverse may well be the better choice. Count users, not staff.

Questions that settle it

Work through these in order. The first "yes" that is a genuine requirement, not a preference, usually decides it.

If you answer "yes" to one of the "lean" questions only, look harder before committing. Sometimes the volume problem can be solved by archiving closed records to a second list each year, and sometimes the offline need is a single form that does not justify a platform change.

The migration question

"Can we start on lists and move later?" Yes, and it is a real project — not a switch. If you can see relational complexity coming within a year, start on Dataverse. If you cannot, start on lists and stop worrying.

What moving involves: recreating the tables and relationships in Dataverse, migrating the data, rewriting the app's data connections and formulas, rebuilding flows against the new tables, and moving every user onto premium licences. The app usually looks the same afterwards, which makes it hard to explain why it cost as much as it did. Budget it as a build, not a configuration change.

The way to keep that option open is to design the lists well from the start: a unique ID on every record, lookups rather than copied text, consistent column names, and no logic buried in calculated columns that nobody documented. Lists built that way migrate cleanly; lists built as one wide spreadsheet do not.

What to do next

Write the one-sentence security rule and the user count for the app you are considering. Those two facts settle most of these decisions on their own. Then do the three-year sum with current pricing. If the answer is still unclear, or you want someone to check the numbers, our Power Apps service page explains how we scope that choice as part of a build — and everything is built in your own tenant, so you own the result either way.

Architecture that bankrupts the licence budget is not good architecture.