SharePoint Lists vs Dataverse for Canvas Apps: Pick the Storage, Not the Habit

The first canvas app in most tenants sits on a SharePoint list because every maker already has a site. Six months later the gallery is slow, the lookup column is a 5,000-item trap, and someone asks "should we move this to Dataverse?" The answer is not ideological. It is a storage decision with a migration cost, and most teams make it two years late.

What a list is actually good at

A SharePoint list is a document-adjacent table with a generous UI, attachments, and permissions that follow the site. For a departmental tracker — facilities tickets, a team roster, a content calendar under a few thousand rows — it is the right default. Makers can add columns without a solution publisher. Backup is the site collection. Nobody files a change request to create a table.

The constraints show up as soon as you treat it like a database. Delegation in canvas apps against SharePoint is a short menu: Filter on simple equality, Sort on indexed columns, no real joins. Anything else pulls a page of rows to the device and lies to you with a blue warning you will eventually ignore. Lookup columns are not foreign keys; they are stored strings plus an id, and they break in Filter the moment you nest them. Unique indexes are a premium afterthought. Transactions do not exist — two patches can interleave and you will not know.

If the app is a form over a list the team already lives in, stay. Wrapping SharePoint in Dataverse "for architecture" is how you get two sources of truth and a sync flow that fails on throttling.

What Dataverse buys you

Dataverse is a relational store with security roles, solutions, and an API that the rest of the Power Platform already speaks. Relationships are first-class: many-to-one, many-to-many, cascading delete you can name. Alternate keys give you upserts. Plugins and real-time workflows run next to the write. Canvas delegation against Dataverse is wider — Filter, LookUp, Sort, Search on indexed columns, and you can Filter on related records without stuffing a collection.

The security model is the quiet win. SharePoint item-level permissions become unmaintainable past a few hundred unique ACLs; Dataverse security roles plus team ownership scale to a company. If the data will be used by a model-driven app, a Power Pages portal, or Copilot Studio knowledge, Dataverse is not optional — those products assume it.

The cost is real: Dataverse capacity is licensed and metered. A list that was "free" on an existing site becomes a table that needs an environment, a publisher, and someone who understands solutions. Makers who could add a column at lunch now need a unmanaged layer and a pipeline. That friction is the point if the app is a product; it is sabotage if the app is a picnic signup.

A decision rule that does not require a workshop

Stay on SharePoint when all of these are true:

• Peak working set the gallery needs is well under the 2,000-row practical ceiling (the 500/2,000 delegation limits are not theoretical).
• Relationships are at most one lookup, not a graph.
• Security is "everyone in this site" or a handful of groups.
• There is no second app, flow family, or portal that must share the schema.

Move to Dataverse when any of these are true:

• You are about to build the second or third app on the same entities.
• You need row-level security that is not "break inheritance and hope."
• You are hitting delegation warnings on queries the business actually runs.
• ALM matters: the schema must move Dev → Test → Prod as a solution, not as a list template and a prayer.

Migration without a rewrite

Do not dual-write a list and a table "for a while." Pick a cutover weekend. Create tables with types that match (choice vs choice, datetime vs datetime — SharePoint's "multiple lines" is not Dataverse memo by accident). Use a dataflow or a one-shot cloud flow to copy, then point the canvas data source at the tables and fix the formulas that used ThisItem.'{FilenameWithExtension}' or nested lookups. Keep the list read-only for two sprints as an audit trail, then archive it.

Attachments are the part everyone forgets: list attachments become File or Image columns, or a related Notes table. Plan that before you delete the site.

The habit to break

Makers pick SharePoint because it is nearby, not because they modeled the data. If you are starting a canvas app that will outlive the intern who built it, spend thirty minutes asking "who else will query this?" If the answer is "a flow, a report, and maybe a portal," start in Dataverse. The list is a great filing cabinet. It is a mediocre system of record.