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, and the cost, weeks and Dataverse capacity line for this job on one page is SQL Server to Dataverse in NZ.
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 left extended support on 14 July 2026, so it only gets security patches if someone is paying for Extended Security Updates (available for Standard and Enterprise, not Express). 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 lost 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 its limit (10 GB, or 50 GB on SQL Server 2025 for Windows), the migration has a deadline of its own: SQL Server Express limits: 10 GB, or 50 GB on 2025.
What does Microsoft 365 offer 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, 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. For 12 users that is NZ$4,665.60 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 as part of the data model. SharePoint can restrict or cascade deletes on a lookup, so orphaned rows are still possible unless the list settings or the app prevent 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.
Should you choose SharePoint or Dataverse for your data?
Answer these five questions about the biggest table in the database. They are prompts for scoping, not a scoring system. If any one of them is a hard requirement, such as money on it or having to prove who changed what, that one answer can decide it, and the answer is Dataverse. The row and editor counts are my rules of thumb for firms under 20 staff, not Microsoft limits.
- Does it have more than about 20,000 rows, or will it within three years? (my rule of thumb)
- Is money on it: invoices, payments, payroll hours, anything an accountant reconciles?
- Do more than three people edit it on the same day? (my rule of thumb)
- Does it relate to three or more other tables that also matter?
- Would you need to prove who changed what and when?
If none of these is a hard requirement, SharePoint lists may be the right home and the project costs less on both the build and the licence. If any one is a hard requirement, budget the NZ$32.40 a user and get the relational database. I scope that decision using the five questions above as prompts, not a vote. 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.
How does Dataverse compare with SQL Server?
People ask this as if it were a technology contest. For a firm under 20 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, or 50 GB on SQL Server 2025 for Windows) 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 | NZ$32.40 per app user per month, storage included to 10 GB plus 250 MB a licence |
| Who patches and backs it up | You, or whoever you pay to | Microsoft |
| Stored procedures, triggers, jobs | Keep working as they are | Rebuilt as flows, business rules and formula columns |
| Reporting | Any SQL tool, Power BI direct | Power BI, Dataverse views, Excel export; no ad-hoc T-SQL |
| Security | Database roles you design | Row and column security roles, auditing by checkbox |
| Integrations that speak SQL | Keep working | Re-pointed to the Dataverse API or a flow |
| 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 database is mostly tables and forms, the server is the problem, and no one wants to own infrastructure |
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.
How does keeping SQL Server and adding a gateway work?
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 (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 does a database migration run?
- 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 as prompts, not a vote. 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. For Dataverse, a Power Platform dataflow pulls straight from SQL Server, through the gateway if it is on-premises, into the new tables. For SharePoint lists I load with a Power Automate flow instead, because dataflows do not write to 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.
How many weeks the move takes, by source and destination, is in how long moving a small business off an old database takes.
If the aim is that staff notice nothing on the first Monday, copy the old system screen for screen first and improve it afterwards.
The trial load and the cut-over load are different jobs: should you build on fake data first?
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. 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.