Use a SharePoint list until you hit one of two walls: a row that has to be visible only to the person who owns it, or real relational tables linking several kinds of record together. Hit either and Dataverse pays for its licence fee. Before that point it's the pricier way to build the same thing, and most firms under 20 staff pay for it anyway because Dataverse sounds like the proper choice.
Once the home is chosen, the mechanics of getting there from SQL Server, Access, a list or Excel are on the Power Platform migration hub.
For a 10-person company
Use SharePoint lists at NZ$0 a month extra until you need row-level security or linked tables; Dataverse then costs NZ$324 a month, ten Power Apps Premium licences, which is NZ$3,888 a year. Monthly cost for ten people using one app, on Microsoft's NZ list:
| Home | Ten users, per month | Row limit that matters | When it wins |
|---|---|---|---|
| SharePoint lists | NZ$0 on top of Microsoft 365 | Views throttle past 5,000 items without an indexed filter; a list holds up to 30 million items | Job registers, client lists, simple approvals, one to six tables, no owner-only rows |
| Dataverse for Teams | NZ$0 on top of Microsoft 365 | 2 GB per team, about a million rows, not extendable | An internal tool that lives in Teams and never needs an outside API |
| Dataverse, Power Apps Premium | NZ$324.00 (10 x NZ$32.40, paid yearly) | No 5,000-item view threshold; 12.5 GB database at ten licences, roughly half a million to a million rows per GB | Related tables, money on the records, owner-only rows, audit history |
| Dataverse, pay-as-you-go | USD 100 at most (USD 10 per active user per app), about NZ$170 converted | Same as Dataverse | Seasonal use; needs an Azure subscription and bills only users active that month |
The Teams row is the only free Dataverse; what it includes is in is Dataverse free. The pay-as-you-go row is the one converted figure here, at about 1.72 NZD to the USD; the Premium figure is Microsoft's own NZD list price. A 10-person firm with a job register and a client list should start on SharePoint. A 10-person firm running invoices or hours through the app, or where each person must see only their own rows, should pay the NZ$324. Nothing in between justifies it.
What does a SharePoint list handle well?
Take a job register: job number, client, site address, a status column, who's assigned, a due date, notes, maybe a photo attachment. That covers most of what a trades or professional services firm needs to track work, and it's one of the more common things I get asked to build. It costs nothing extra, because it's already sitting inside the Microsoft 365 licence every seat pays for, and most firms already have that seat: in Kove's observed-signal census, 67% of firms with an identifiable mail platform run Microsoft 365 against 33% on Google Workspace.
A SharePoint list gives you a proper grid with sortable columns, choice fields, people pickers, filtered views, and alerts when something changes. Calculated columns and conditional formatting handle a fair bit of business logic on their own, colouring a job red when it's overdue, flagging a status change, without a line of code. Power Automate can watch the list and fire off reminders or a Teams message when a row changes. A Power Apps canvas app can sit on top for a nicer mobile view, or staff can just work the grid directly in the browser or Teams. All of it runs without Dataverse anywhere in the picture. The list itself does the job of a small database for a business that isn't running thousands of records through it at once.
When does SharePoint reach its limits?
Three things break it, and none of them are about how the list looks.
The first is relational depth. A lookup column can point one list at another, but it stops well short of a real foreign key. There's no cascading logic, no rollup across a many-to-many relationship, no enforced referential integrity between tables. Model something with genuine structure, say jobs that link to several site visits that each link to several materials used, and a SharePoint list starts needing workarounds instead of relationships.
The second is row-level security. SharePoint can break inheritance on an individual item so one person sees only their own row, and for a handful of rows that's fine. Microsoft's own guidance is to keep unique permission scopes under about 5,000 per list, because performance degrades well before the hard cap of 50,000. If every row in a list of any real size needs owner-only visibility, that's a structural mismatch, and no amount of tuning fixes it.
The third is volume. SharePoint Online fixes the list view threshold at 5,000 items per query, and that number can't be raised. A list can technically hold millions of rows, but any view trying to pull more than 5,000 without an indexed filter will throttle or fail outright. It's manageable with the right indexing and filtered views. It's also a growing tax on whoever maintains the list once it's past a few thousand rows, and in practice that point arrives two or three years in, not on day one, which is exactly when it surprises people.
What is the difference in licensing costs?
A SharePoint list costs nothing beyond the Microsoft 365 seat you already pay for. Dataverse doesn't come free with anything. It sits behind a Power Apps Premium licence, which is a new line on the bill rather than a checkbox on an existing one.
Power Apps Premium is NZ$32.40 per user per month on Microsoft's NZ price list, paid yearly, checked September 2026 (USD 20 on the US list). The cheaper per app plan, around USD 5 per user per app, came off general sale on 2 January 2026, but Enterprise Agreement customers can still renew it and CSP resellers got access back in April 2026, so budget on Premium only after you have asked your partner. That single number kills more small-firm Power Platform projects than anything else: for a 12-person firm it is NZ$4,665 a year, every year, on top of the build, and it is the line item nobody mentions until the quote arrives. Microsoft changes Power Platform pricing often enough that it should not be treated as fixed. Check the current rate before you budget, not a number from a blog post, including this one. The full capacity and licence picture, with worked totals, is on Dataverse pricing in NZ. It's a separate purchase from whatever Microsoft 365 tier a firm's already on, which I've gone through in Microsoft 365 licensing for a small firm, since the two get confused more often than they should.
What that spend buys is capability you may never use: relational tables, row-level security, audit logging, business rules enforced at the data layer. For a firm that doesn't need any of the three, the extra licence doesn't make the app faster or nicer to use. It adds a bill for governance nobody asked for, scaled by headcount rather than by the size of the problem. One thing shifts that in 2026: Microsoft is wiring its AI layer to Dataverse specifically, agents, protocol access and Copilot integration, which is worth reading before a long-lived placement call.
| SharePoint list | Dataverse table |
|---|---|
| Included in the Microsoft 365 seat you already pay for | Requires a separate Power Apps Premium licence, priced per user |
| Lookup columns between lists, no enforced relationships | True relational tables, one-to-many and many-to-many |
| Item-level permissions, workable to about 5,000 unique scopes per list | Row-level and field-level security built into the data layer |
| Views throttle past 5,000 items without an indexed filter | No practical view-level ceiling for a small or mid-size firm |
How should you choose based on what you are moving?
| Starting point | Home | Licence per user, per month | Guide |
|---|---|---|---|
| A spreadsheet one or two people edit, no money on it | SharePoint list | $0 | Replacing the spreadsheet that runs your business |
| An Access database with a few tables and forms | SharePoint lists, unless money or eight-plus related tables | $0, or NZ$32.40 | Moving an Access database off the shared drive |
| A SQL Server database behind a bespoke or vendor app | Dataverse for related or financial data; SharePoint if it is really one big table | NZ$32.40, or $0 | Moving a SQL Server database into Microsoft 365 |
| Anything where rows must be visible only to their owner | Dataverse | NZ$32.40 | Dataverse security roles |
| A job register that will pass 20,000 rows within three years | Dataverse, or indexed SharePoint with a plan | NZ$32.40, or $0 | The 5,000 item list limit |
The flows around either home are usually free with Microsoft 365, and the cases where they are not are in what Power Automate actually costs a small NZ business.
Which question decides the right platform?
Ask one thing before anyone chooses a platform on how proper it sounds.
Does more than one person need to see the same table while each person is restricted to their own rows, or does this data genuinely need to relate to another table in a way a lookup column can't express?
Yes to either, and Dataverse is the right call, licence cost included. No to both, and a SharePoint list will do the job for the price you're already paying. I ask this on nearly every Power Platform intro call, because the instinct to reach for Dataverse first is common and looks cheap at the start. What makes it expensive is a licence spend that repeats every month whether anyone touches the extra capability or not.
What happens if you outgrow SharePoint?
Starting on a list isn't a dead end. Power Apps has a built-in import that reads a SharePoint list's schema and creates a matching Dataverse table, mapping columns and lookups automatically, and Power Platform dataflows handle the same job at larger volumes. The app layer usually survives the move too. A canvas app built against a SharePoint list reconnects to a Dataverse table with formula adjustments rather than a rebuild from nothing.
That makes the sensible order of operations: build the SharePoint version first, run it on real jobs, and pay for Dataverse only once you can point at the specific row-security or relational problem it fixes. Paying for the licence upfront on the assumption you'll grow into it usually just means paying twice, once for the seats and again for someone's time working out which parts of Dataverse you needed. I cover the wider licensing picture, including where Copilot Studio and Power Automate fit around this decision, on the Power Platform page. If you already know which side of the line you're on and just need it built, that's a Workflow Review or a build away.
Common questions
Is a SharePoint list good enough for a small business database?
Often, yes. SharePoint lists are included in the Microsoft 365 licence most firms already pay for and handle structured tracking, job registers, asset lists, simple approvals, well below the point where volume or security becomes a problem. Most firms under 20 staff never hit that point.
Does SharePoint support row-level security?
Not as a first-class feature. You can break permission inheritance on individual items so one person sees only their own row, but Microsoft's own guidance is to keep unique permission scopes under about 5,000 per list before performance suffers. It works for a handful of rows, not for owner-only visibility across a large list.
How much does Dataverse cost for a small NZ firm?
Dataverse comes bundled with a Power Apps Premium licence rather than being sold on its own. On Microsoft's NZ price list, checked September 2026, that is NZ$32.40 per user per month, paid yearly (USD 20 on the US list); for 12 users that is NZ$4,665 a year on top of the build. The cheaper per app plan came off general sale on 2 January 2026, but Enterprise Agreement customers can still renew it and Microsoft restored CSP reseller access in April 2026, so ask your partner before you budget on Premium. Microsoft changes Power Platform pricing often, so check the current rate before budgeting.
Which side of the line are you on?
Free 30-minute call. Walk me through what you're tracking and who needs to see what, and I'll say whether it needs Dataverse or just a well-built list.
A mortgage or insurance broker tracking applications through stages is the same question in a different coat: SharePoint or Dataverse for a client pipeline.