DEV Community: Balu Premkumar

Power Automate limits: runs, actions, throttling

Balu Premkumar — Wed, 30 Sep 2026 06:14:27 +0000

A single Power Automate flow tops out at 500 actions in its definition, as at 22 September 2026, and Concurrency Control, off by default, can raise or cap concurrent runs anywhere from 1 to 100. On top of both sits a daily Power Platform request allocation set by the flow owner's licence, from 6,000 to 250,000 a day. None of the three is where most small-firm flows actually run into trouble.

Three limits, one flow

Limit	Value	Notes
Actions per flow definition	500	Use child flows for more; editor gets sluggish well before the cap
Concurrent runs, Concurrency Control off	Unlimited	The default state for a new flow's trigger
Concurrent runs, Concurrency Control on	1 to 100 (default 25)	Once turned on it can't be turned off without recreating the trigger
Apply to each, array items	5,000 (Low profile) / 100,000 (others)	Filter first if the source array is large
Run duration	30 days	Pending steps like approvals time out after this
Power Platform requests, per licence, per day	6,000 to 250,000	Depends on the flow owner's plan

A flow's daily request allowance comes from whichever performance profile its owner's licence maps to, Low, Medium, High or Unlimited Extended, and a flow shared between people still runs on the owner's limits, not the person who triggers it. If the original owner leaves the tenant, the flow drops to the lowest, Low, profile automatically.

What it means for a firm under 20 staff

Very few small-firm flows come close to 500 actions or the 100-run concurrency ceiling; a job notification flow with a handful of conditions and a Teams message might use a dozen actions. The limit that actually catches a small firm is the Apply to each array cap of 5,000 items on a free or Microsoft 365-included licence, which shows up the first time someone builds a flow that loops over every row in a growing SharePoint list or Excel table rather than filtering first. The flow runs fine in testing on a short list and then silently stops partway through once the source data crosses the threshold, the same quiet-failure pattern that SharePoint's own list limits produce in a canvas app.

The other place a small tenant meets a wall is turning on Concurrency Control without testing it first. It's meant to stop two triggers processing the same record at once, a real problem worth solving, but the default degree of parallelism of 25 concurrent runs, and the fact the setting can't be switched off again without rebuilding the trigger, has caught more than one maker who turned it on to fix a race condition and then wondered why runs started queueing.

The workaround

For the action-count ceiling, split logic into child flows once a single flow starts feeling unwieldy in the designer, well before 500 becomes the actual blocker. For the array-processing cap, filter or query the source down to the rows that matter before the Apply to each loop runs, rather than looping over the whole table and discarding most of it inside the loop; that also keeps the flow well clear of the daily request allowance, since every loop iteration burns its own request. For the daily allocation itself, moving a heavy flow's ownership to a user with a Power Automate Premium or Process licence lifts the ceiling from 6,000 to 40,000 or 250,000 a day without touching the flow's logic at all.

Common questions

How many actions can a single Power Automate flow have? 500 actions per flow definition is the documented limit, and Microsoft warns that flows can feel sluggish to edit well before that, in the Power Automate designer. A flow that needs more logic than that is usually a sign it should be split into child flows rather than pushed further.

How many flow runs can happen at the same time? Unlimited, by default, because Concurrency Control ships turned off. Turning it on caps concurrent runs to a number from 1 to 100, defaulting to 25, and that switch cannot be turned off again without deleting and re-adding the trigger, so it's worth testing before flipping it on a live flow.

How many Power Platform requests does a flow's licence allow per day? 6,000 a day for a free or Microsoft 365-included user, 40,000 for a Power Automate Premium or per-user plan, and 250,000 for a flow carrying a Process or per-flow licence. A flow inherits the performance profile of whoever owns it, so moving ownership to a better-licensed user can lift the ceiling without touching the flow itself.

Why would a flow need a Power Automate Process licence? A Process or per-flow licence raises a flow's daily Power Platform request allowance to 250,000, well above the 6,000 a free or Microsoft 365-included user gets or the 40,000 a Premium per-user plan gives. Moving a heavy flow's ownership to a user carrying that licence lifts the ceiling without changing the flow's own logic.

First published at https://kove.nz/insights/power-automate-limits-and-throttling

SharePoint lists are not a database, until they are

Balu Premkumar — Wed, 30 Sep 2026 06:13:50 +0000

A SharePoint list can hold 30 million items and still feel broken at 3,000, or sit at 3,000 rows for years without a single problem. The 5,000-item list view threshold everyone quotes is the cheapest limit to fix: add an index and a filtered view sails past it. What stops a list working as a database is lookups, concurrency, delegation and reporting, and none of them throw an error until the damage is done. They show up about eighteen months in.

Limit	What it means in practice
List view threshold	5,000 items per query without an indexed filter, effectively no ceiling with one
Indexed columns per list	20, with SharePoint adding some automatically as a list grows
Lookup-type columns per view	12, and Person/Group and Managed Metadata columns count toward it too
Absolute list size	Around 30 million items, though it slows well before that point
Power Apps non-delegable record limit	500 by default, adjustable up to 2,000
Power Automate Get items, paginated	Up to 100,000, but still needs an indexed column for any filter past 5,000

What the list view threshold does

The threshold blocks a query the moment it can't lean on an index, which is a different event from a list passing 5,000 rows. Filter a view by an indexed column, and as long as the filtered result comes back under 5,000 items, the query runs fine no matter how big the underlying list is. SharePoint Online now adds indexes automatically as a list grows, and a maker can add up to 20 manually. What still fails is an unfiltered "all items" view, or sorting and grouping on a column that isn't indexed, since neither can be pushed down to an index the way a filter can.

There's a separate, harder ceiling further out: a SharePoint list technically holds up to around 30 million items before you hit an absolute wall, and even that doesn't throw a clean error so much as get progressively slower to work with. Microsoft has no plans to raise the 5,000-item threshold itself, because it exists to protect a shared, multi-tenant environment. Building around it with indexes is the normal way of working.

Where SharePoint holds up better than its reputation

A job register, an asset list, a quote log, a simple approval queue: these are the things people build on SharePoint constantly, and for good reason. It's included in the Microsoft 365 seat a firm already pays for, gives sortable views, choice fields, people pickers and alerts out of the box, and Power Automate can watch it and fire off a reminder or a Teams message without anyone writing code. For a firm under 50 staff running a few thousand rows through a list, that's a solid, low-maintenance setup that will hold for years.

The built-in conflict handling is better than its reputation too. Two people editing the same item through the standard list form get a proper save conflict warning, not a silent overwrite, and version history makes recovering from a bad edit a few clicks, not a support ticket. Most of the dismissiveness aimed at SharePoint lists online is aimed at the SharePoint of a decade ago rather than the indexed, threshold-aware version most firms run today.

The ceilings that get you

None of the following show up when a list is small. All of them show up once it's doing real work.

Lookups and relationships

A single view can carry at most 12 lookup-type columns, and that cap includes Person/Group and Managed Metadata columns, plus the built-in Created By and Modified By fields. A list with a handful of people-picker columns and a couple of lookups to other lists blows past that limit faster than most people expect. SharePoint does have a real referential integrity feature, enforce relationship behaviour, letting a lookup column cascade or restrict a delete, but it needs an indexed, single-value lookup column and Manage Lists permission to turn on, caps cascade delete at 1,000 items per operation, and can't be enabled at all once the parent list has already passed the view threshold. The one feature meant to protect data integrity switches itself off exactly when a list is large enough to need it.

Concurrency

The built-in save-conflict warning only covers a person typing into the native list form. Writes from a flow, a Power App, or an API call have no equivalent lock, so two automated processes updating the same item close together can silently overwrite each other rather than queue, wait or error. A job register touched by a handful of people a few times a day is fine. Put several automated writers on the same rows and you have a race condition waiting for the wrong afternoon.

Delegation, the one that bites

This is the limit that catches people out, because nothing fails loudly. Power Apps only pushes some functions down to SharePoint to run server-side, that's delegation. Anything it can't push down gets pulled back and processed locally instead, capped at 500 records by default and 2,000 at the outside if a maker raises it. Common non-delegable culprits against SharePoint include the Search() function, several nested Or() conditions across mixed column types, and sorting on certain computed or multi-value columns. The app still runs, the screen still looks fine, it's just quietly working off a slice of the list once that list grows past the cap, with nothing louder than a small warning icon most people learn to ignore.

Power Automate has the same mechanism under a different name. The Get items action defaults to a small batch, but pagination can be enabled to retrieve up to 100,000 items across batches, still depending on an indexed column for any OData filter once the list passes 5,000 items. Filter on a column that isn't indexed and the flow gets refused at the same threshold that blocks a view.

Reporting

Power BI's SharePoint list connectors inherit the same ceilings rather than sidestepping them. A report built against an unfiltered "all items" query slows down or times out as the list grows, and there's no native join across two lists the way a relational data source handles it. It's workable with the newer connector, indexed OData filters, or landing data into a proper reporting table on a schedule instead of live-querying the list every refresh, but each of those is a deliberate engineering decision someone has to make and maintain.

Patterns that buy you another year

Hitting one of these is not a reason to rebuild tomorrow. A few habits keep a list working well past the point where the threshold would otherwise start biting.

Archive instead of accumulating. Move closed or old rows into a separate archive list on a schedule so the working list stays small and every index stays useful.
Index the columns you filter or sort by, ahead of time. Waiting for the threshold error to tell you which column needs an index is the expensive way to find out.
Route writes through one flow rather than several people, apps or scripts writing to the list directly, so there's a single place handling updates instead of processes racing each other.
Make the default view a filtered, indexed one rather than "All items", so nobody triggers the threshold by accident just opening the list.
Land data for reporting instead of live-querying it. A scheduled flow that copies rows into a purpose-built reporting table beats pointing Power BI straight at the list on every refresh.

Where Dataverse stops being optional

Watch what starts breaking, not the row count. Once relationship behaviour won't turn on because the list already ran past the view threshold, once a Power Apps screen is serving incomplete results from a non-delegable query no one flagged, or once two systems are racing to write the same item with no lock between them, the engineering time spent working around the platform starts costing more than moving the data would. That's the point where Dataverse pays for itself. SharePoint didn't get worse; the job outgrew what a list was designed to do.

Common questions

Does the SharePoint list view threshold apply to every query? No. The threshold only blocks a query that can't use an index. Filter a view on an indexed column and return fewer than 5,000 matching items and the query runs past the raw item count fine. SharePoint Online adds indexed columns automatically as a list grows, and a maker can add up to 20 manually. What still fails: sorting or grouping on a column that isn't indexed, or an unfiltered "all items" view on a large list.

What is the real limit before a SharePoint list needs Dataverse? The raw item count is rarely the trigger. The more common ones are a Power Apps screen quietly returning incomplete results because a query wasn't delegable and got capped at 500 or 2,000 records, a lookup relationship that won't enforce cascade or restrict delete because the list already passed the view threshold, or two systems writing to the same item with no lock between them. Any of those is a stronger signal than the number of rows.

Can Power Automate read more than 5,000 items from a SharePoint list? Yes, with pagination turned on in the Get items action, which can retrieve up to 100,000 items across batches. That still depends on an indexed column for any filter once the list is over 5,000 items. An OData filter on a non-indexed column gets refused at exactly the same threshold that blocks a view.

First published at https://kove.nz/insights/sharepoint-list-limits

Dataverse pricing in NZ, for a small business

Balu Premkumar — Wed, 30 Sep 2026 06:13:09 +0000

Dataverse is not a line item. It arrives inside a Power Apps or Power Automate licence, brings its own capacity, and only becomes a separate bill when you outgrow that. Here is the whole picture in NZD for a NZ firm with under 20 staff, from Microsoft's NZ price list. Prices checked September 2026.

The short version: Dataverse costs NZ$32.40 per user per month before GST, because that is the Power Apps Premium licence it comes with. The first licence gives the tenant 10 GB of database space, each licence adds 250 MB, and most firms under 50 staff never fill it. If you do, extra database capacity is NZ$64.70 per GB per month. The number that matters is the per-user one: for 12 people it is NZ$4,665 a year, which is why the SharePoint-or-Dataverse question comes before any of this.

The licence that includes it

Licence	NZD per user per month, before GST, paid yearly	Gives you
Power Apps Premium	NZ$32.40	Build and run any number of apps on Dataverse, premium connectors, the gateway; 250 MB database and 2 GB file capacity accrued per licence
Power Apps Premium at 2,000+ seats	NZ$19.40	Same, for a tier no small firm will reach
Power Automate Premium	NZ$24.30	Flows against Dataverse and premium connectors for a user who does not open an app; 250 MB database and 2 GB file accrued
Power Automate Process	NZ$242.70 per flow or bot per month	A flow with no human owner; 50 MB database and 200 MB file accrued
Dataverse for Teams	$0 inside Microsoft 365 with Teams	2 GB per team, about a million rows, apps that live inside Teams only
Dataverse database capacity add-on	NZ$64.70 per GB per month	Only when the accrued capacity runs out

Source: Microsoft's NZ pricing pages for Power Apps and Power Automate, September 2026. A client-facing site on top of Dataverse is a separate per-site subscription (Power Pages). The pay-as-you-go alternative (USD 10 per active user per app per month, billed through Azure) is cheaper than Premium for anyone who uses one app, at about NZ$17 a month, and Premium wins from two apps. The per app plan came off general sale on 2 January 2026 and is back only through some CSP partners, so budget on Premium unless your partner says otherwise.

The capacity you already have

Capacity is pooled at the tenant, not per environment, and it comes in three kinds that do not trade against each other.

Capacity	Tenant default (first subscription)	Per Premium user licence	What lives there
Database	10 GB	+250 MB	Rows, columns, relationships, metadata. The one that matters
File	20 GB	+2 GB	Attachments, images, files in file columns
Log	2 GB	+0	Audit history and plug-in traces

Worked examples. A 5-person firm on Premium: 11.25 GB database, 30 GB file. A 12-person firm: 13 GB database, 44 GB file. A 20-person firm: 15 GB database, 60 GB file. Creating a second environment (a dev copy, which you should have) needs at least 1 GB free, and every environment's system tables take a few hundred megabytes before you add a row.

What 1 GB holds

Microsoft does not publish a rows-per-gigabyte figure because it depends on the columns. A working rule: a plain row with a few dozen text, number, date and lookup columns is one to two kilobytes, so 1 GB is roughly half a million to a million rows of a job register, client list or asset table. A 10-year-old Access database migrated in full is usually under 1 GB. Rows rarely fill it. What does: audit history left on for every column (that is log capacity, but it fills), multiline text columns holding pasted emails, and system tables in environments nobody uses. Attachments go to file capacity, which is four times bigger and cheaper to extend.

The five limits that actually bite a small firm

The per-user licence, not the storage. NZ$32.40 a month per person who opens the app. Design around SharePoint lists where the data allows it.
API requests per user per day. A Premium user gets 40,000 Power Platform requests a day; a Microsoft 365-only user gets 6,000. A flow that loops over a big list in the wrong way can hit that by lunchtime. Microsoft's own advice is to filter at the source.
Delegation in canvas apps. Formulas Dataverse cannot delegate stop at 500 rows, or 2,000 with the setting raised. The data is all there; the app just stops looking. Test with the real row count.
Text at 4,000 characters for a Text column, about a million for Multiline. The pasted-email column from the old system needs the latter.
Dataverse for Teams at 2 GB and one million rows per team, with no premium connectors and fewer column types. Fine to start; plan the upgrade path before the register hits it.

Three scenarios, priced

Firm	Licences	Capacity	Per year, before GST
6 people, job register and quotes on Dataverse, everyone uses the app	6 x Power Apps Premium	11.5 GB database, plenty	NZ$2,333
12 people, 4 use the app daily, 8 only get emails from flows	4 x Power Apps Premium, flows owned by one of the four	11 GB database	NZ$1,555
20 people, model-driven app for everyone, five years of history with attachments	20 x Power Apps Premium	15 GB database, 60 GB file; attachments in file capacity	NZ$7,776

The second row is the one people miss: the licence follows the person who opens the app or owns the flow, not the headcount. Eight staff who only receive an approval email or a Teams message from a flow need nothing beyond Microsoft 365.

Common questions

Can I buy Dataverse without Power Apps? No. Dataverse is included with Power Apps, Power Automate, Copilot Studio and Dynamics 365 licences, and with Microsoft 365 as Dataverse for Teams. There is no standalone Dataverse SKU. The capacity add-on extends storage for a tenant that already has one of those licences.

Does a Dynamics 365 licence cover custom Dataverse tables? Within limits. Dynamics 365 licences include Dataverse use rights and let you extend the Dynamics app with custom tables in the same environment. A standalone Power App on its own tables, outside the Dynamics app, needs Power Apps Premium. If you already pay for Dynamics, ask before buying Premium.

What happens when I run out of capacity? Existing apps keep working. What stops is creating, copying or restoring environments until you free space or buy the add-on. Deleting an unused environment, trimming audit logs and moving attachments to file columns usually recovers more than a firm this size ever needs to buy.

Is there a cheaper way for occasional users? Pay-as-you-go through an Azure subscription bills USD 10 per person per app in the months they open it, about NZ$17, so for a single app it is cheaper than the NZ$32.40 licence even for daily users. Premium wins when someone uses two or more apps, or when you want the bill fixed in NZD.

Method

Licence prices are Microsoft's NZ list prices from microsoft.com/en-nz, ex GST, paid yearly. Capacity figures are from Microsoft Learn's Power Platform licensing FAQ and the Dataverse capacity documentation. Rows-per-gigabyte is a working estimate and labelled as one.

First published at https://kove.nz/dataverse-pricing-nz

Moving a SQL Server database into Microsoft 365

Balu Premkumar — Tue, 22 Sep 2026 00:46:26 +0000

For NZ firms with 5 to 20 staff: which parts of a SQL Server system move to SharePoint or Dataverse, what has to be rebuilt, and the NZD licence and build cost.

The short version: for a 5 to 20 person NZ firm, the data in a SQL Server database moves into SharePoint lists or Dataverse tables, the logic around it (stored procedures, triggers, the Access or web front end) gets rebuilt in Power Apps and Power Automate, and the whole job usually lands between $8,000 and $18,000 over three to eight weeks. The licence decision matters more than the build: SharePoint runs on the Microsoft 365 seats you already pay for, Dataverse costs NZ$32.40 per user per month on top.

The mechanics per source, the eight SQL Server gotchas and the data-type map are on the Power Platform migration hub.

Who this is for

You have a SQL Server database somewhere in the building. It might be behind an old Access front end, a bespoke .NET app someone built in 2014, or a piece of industry software the vendor stopped supporting, and if it is SQL Server 2016 it has been unpatched since 14 July 2026. The server it lives on is out of warranty, or the person who looked after it has left, or the Windows Server 2012 R2 underneath it loses its last security updates on 13 October 2026. And you already pay for Microsoft 365, so the obvious question is whether the whole thing can just live there.

This guide answers that for firms with 5 to 20 staff, and up to about 50. It is not written for a 300-seat company with a data team; the big Microsoft consultancies write plenty for those, and will not usually quote the small version. Nobody writes the small-firm version, which is why a question like "can we move our SQL database to 365" gets you enterprise answers.

If the instance is Express and the data file is near 10 GB, the migration has a deadline of its own: SQL Server Express hit the 10 GB limit.

What Microsoft 365 actually has instead of SQL Server

There is no SQL Server inside Microsoft 365. Your data has three possible homes, and the choice sets both the cost and the ceiling of the project.

Home	What it is	Licence per user	Right when
SharePoint lists	Tables inside the SharePoint you already have. Columns, lookups, views, item-level permissions.	Included in Microsoft 365 Business Basic, Standard or Premium	Simple tables, under about 20,000 rows each, no money or audit trail riding on it
Dataverse	Microsoft's relational database for the Power Platform. Real relationships, row-level security, auditing, business rules.	Power Apps Premium, NZ$32.40 a month before GST, paid yearly	Related tables, financial records, more than two or three people editing, anything you would call "the system"
Keep SQL Server, add a gateway	The database stays on your server. Power Apps and Power Automate reach it through Microsoft's on-premises data gateway.	Power Apps Premium, NZ$32.40, because the SQL Server connector is premium	The server is supported and staying, and the real problem is the front end, not the database

One number decides more of these projects than any other: Power Apps Premium is NZ$32.40 per user per month on Microsoft's NZ price list, before GST. For 12 users that is NZ$4,665 a year, every year, on top of the build. If the same job fits in SharePoint lists, that line disappears. That is why the first hour of any migration I scope goes on the data, not the app.

What transfers cleanly

Tables and rows. Text, numbers, dates, yes/no, currency all map to SharePoint or Dataverse column types. Row counts in the tens of thousands are fine in either; hundreds of thousands means Dataverse.
Foreign keys. Become lookup columns in SharePoint or real relationships in Dataverse. Dataverse enforces them, SharePoint does not, so orphaned rows are possible in SharePoint unless the app prevents them.
Identity columns. Dataverse gives every row a GUID and can add an autonumber column that continues your existing job or invoice numbering. SharePoint has an ID column you do not control.
Files and images. Attachments move to a SharePoint document library or Dataverse file columns. Blobs stored inside SQL come out during the migration and go into files, which is usually an improvement.
Users and permissions. Map to Microsoft 365 accounts and groups, which most firms find tidier than the SQL logins they had.

What breaks and has to be rebuilt

Stored procedures and triggers. Neither SharePoint nor Dataverse runs T-SQL. Each one becomes a Power Automate flow, a Dataverse business rule, or logic inside the app. In most small-firm systems there are fewer than ten that matter, and half of them exist only to work around something the old front end could not do.
Views and reports. SQL views become Dataverse views or Power BI reports. Any report that joined six tables and ran overnight becomes a Power BI report instead, and that is a separate Power BI licence question I cover in Power BI vs Excel.
The front end. Access forms, a Windows app, a classic ASP page: none of it moves. It is rebuilt as a Power App, and this is where the hours go. The good news is the rebuilt version runs on phones and does not need the server.
Precision and types. Dataverse floating-point columns keep five decimal places; decimals keep ten. varchar(max) columns become multiline text with a length cap. Unique indexes do not migrate automatically and must be recreated as alternate keys. A migration validator catches these, but somebody still has to decide what to do with the rows that fail.
Integrations. Anything that talked to the SQL database directly (a label printer, a Xero sync, an ODBC link from Excel) has to be re-pointed. List them before you start; they are the thing people forget.

SharePoint or Dataverse: decide on the data, not the app

Answer these five questions about the biggest table in the database. Three or more "yes" answers means Dataverse.

Does it have more than about 20,000 rows, or will it within three years?
Is money on it: invoices, payments, payroll hours, anything an accountant reconciles?
Do more than three people edit it on the same day?
Does it relate to three or more other tables that also matter?
Would you need to prove who changed what and when?

If the answer is mostly no, SharePoint lists are the right home and the project costs less on both the build and the licence. If the answers are mostly yes, budget the NZ$32.40 a user and get the relational database; trying to fake relationships in SharePoint is how small firms end up with a second migration two years later. The longer version of this decision, with the licensing maths, is in SharePoint or Dataverse: how to choose, and the specific ceilings that bite in SharePoint are in the 5,000 item list limit.

Dataverse or SQL Server: the honest comparison

People ask this as if it were a technology contest. For a firm under 50 staff it is a cost-of-ownership question, and the two answers are closer than either camp admits.

Keep SQL Server (upgraded, or in Azure)	Dataverse
What you pay Microsoft	SQL Server licence (Express is free to 10 GB per database) plus a supported Windows Server, or an Azure SQL bill from tens of dollars a month; plus NZ$32.40 per app user anyway, because the SQL connector is premium
Who patches and backs it up	You, or whoever you pay to
Stored procedures, triggers, jobs	Keep working as they are
Reporting	Any SQL tool, Power BI direct
Security	Database roles you design
Integrations that speak SQL	Keep working
Right when	Heavy logic in the database, a vendor product that needs SQL, reporting people who write T-SQL, or a server that is staying regardless

The row that decides it is the third. If the value of the system is in the stored procedures, keep SQL Server and put the app on it through the gateway. If the value is in the data and the forms, Dataverse removes a server from your life for the same per-user licence you would pay anyway. The migration hub has the load method and the eight gotchas.

The cloud version of keeping SQL Server, with the same logic and no server to own, is Azure SQL; Dataverse or Azure SQL for a small NZ business is that comparison.

Keep SQL Server and add a gateway: how it actually works

The on-premises data gateway is a small Windows service installed on a machine inside your network that can reach the SQL Server. It makes outbound connections only; nothing inbound is opened. Power Apps and Power Automate talk to Microsoft's cloud, the cloud talks to the gateway, the gateway talks to SQL Server and returns the rows. Install it in standard mode (personal mode is for Power BI only), on a machine that stays on, and give the connection a SQL login with the least rights the app needs. Three things go wrong: the gateway machine gets switched off at night and the morning app fails; the SQL login expires; and a canvas app formula that SQL cannot delegate stops at 500 rows. All three are known before go-live if anyone tests with the real row count. Licensing is simple and unavoidable: SQL Server is a premium connector and the gateway needs a premium licence, so every user of the app is on Power Apps Premium at NZ$32.40 a month.

When you should not migrate at all

Three cases where I tell people to leave SQL Server alone. First, the database is under a vendor product that is still supported and updated: migrating it breaks the product, and the vendor probably has a hosted version. Second, the server is fine and the only complaint is the front end: put a Power App on top through the gateway and spend the money on the app. Third, the whole thing is under about 500 rows and one person uses it: export it to a SharePoint list or even an Excel table in Teams and stop. A migration project on that is a waste of your money, and Power Platform is sometimes the wrong answer for bigger reasons too.

What it costs in NZ

Cost line	SharePoint route	Dataverse route
Licences, per user per month	$0 on top of Microsoft 365	NZ$32.40 + GST (Power Apps Premium)
Storage	Inside your SharePoint quota	10 GB tenant default plus 250 MB per Premium licence; add-on NZ$64.70 per GB a month if you outgrow it
Data migration	Included in the build: export, clean, map, load, reconcile row counts against the source
Rebuilding the front end and logic	$4,000 to $10,000	$8,000 to $18,000
Time	Two to five weeks	Three to eight weeks
Ongoing	No server, no patching, no backup job. Microsoft's backups and updates, and your Microsoft 365 admin.

Those build ranges are my fixed-price bands for firms under 20 staff, from the services page, and they include the migration itself. A firm with a 4,000-row job register, one Access front end and a Xero sync sits at the bottom of the SharePoint column. A firm with nine related tables, invoices and three years of history sits in the middle of the Dataverse column. The one thing that pushes a job past the top of the range is undocumented logic no one can explain, which is why the scoping starts with a free call, not a quote.

How the migration actually runs

Inventory. Every table, row count, stored procedure, view, and everything that connects to the database from outside. One afternoon, and it usually reveals two unused tables.
Decide the home. SharePoint, Dataverse, or gateway, using the five questions above. This is also when the licence cost gets a real number against your real headcount.
Build the target and map the types. Lists or tables, relationships, autonumbers, the columns that need renaming because nobody remembers what "fld_x2" meant.
Trial load. Power Platform dataflows pull straight from SQL Server, through the gateway if it is on-premises, into Dataverse or SharePoint. The first load always finds bad dates and orphaned rows. Fix them at the source.
Rebuild the front end and logic. The Power App and the flows, tested by the two people who use the old system most.
Cut over. Freeze the old system on a Friday, final load, reconcile row counts and totals, go live Monday. Keep the old server switched off but intact for 60 days.
Hand over. Source, credentials, a written map of what lives where, and a session with whoever will own it. No retainer needed to keep it running.

Common questions

Can I move a SQL Server database straight into Microsoft 365?
Not as-is. Microsoft 365 has no SQL Server inside it. The tables and rows move into SharePoint lists or Dataverse tables; the stored procedures, triggers, views and any Access or web front end get rebuilt as Power Apps, Power Automate flows and Dataverse business rules. Or the database stays where it is and Power Apps reaches it through a gateway.

What does it cost to move a small SQL Server system into Microsoft 365 in NZ?
Licences first: SharePoint lists run on the Microsoft 365 seats you already pay for; Dataverse or a live SQL Server connection needs Power Apps Premium at NZ$32.40 a user a month before GST. The build for a 5 to 20 person firm typically lands between $8,000 and $18,000, over three to eight weeks.

Should a 10-person business choose SharePoint or Dataverse for old SQL data?
SharePoint if the data is under roughly 20,000 rows per table, has simple lookups and no money or audit trail riding on it. Dataverse if there are real relationships, more than a handful of related tables, financial records, or you need row-level security. Under 500 rows and one user, a SharePoint list beats a project.

Can we keep SQL Server and just put a Power App on top?
Yes. The on-premises data gateway connects Power Apps and Power Automate to a SQL Server on your own network with no inbound ports. Every user of that app needs Power Apps Premium because the SQL Server connector is premium, and the server still has to be patched and backed up, so it suits firms that already have a supported server and just need a better front end.

Where to start

If you can tell me the row count of your biggest table and what sits in front of the database, I can tell you which column of the cost table you are in, in one free 30-minute call. If the answer is "leave it where it is", I will say so. Or answer the five prep questions first and the call starts with the price band. The migration checklist is free too, and works with anyone you hire, not just me.

Sometimes what looks like an old website is actually one of these systems wearing a dated front end: how to tell the difference before you pay for either fix.

Originally published at kove.nz, where the prices are re-checked quarterly.