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.
Top comments (0)