SQL Server and Access migration checklist for a small NZ business

1. Inventory (before anyone quotes)

1. Exact version and edition of SQL Server (SELECT @@VERSION) or Access, and the Windows Server underneath. Check both against the end-of-support dates.
2. Every database on the instance, including the two nobody recognises, and whether each is still used.
3. Row count of every table in the production database, and the size on disk.
4. Every stored procedure, trigger, view and scheduled job, with one line each on what it does. Unknown is an acceptable answer at this stage; it is not acceptable at quote time.
5. Every front end: Access forms and reports, a Windows or web app, Excel links, Power BI, anything with a connection string.
6. Every integration: label printers, Xero or MYOB syncs, ODBC links, email jobs, a supplier portal. These are what people forget and what breaks on Monday.
7. Who uses it, how many people on a busy day, and which two people know it best.
8. Where the files live: attachments inside the database as blobs, or on a share it points at.
9. A tested backup restored somewhere else, before anything else happens. Not the Friday USB drive.

2. Decide the home

1. Biggest table over about 20,000 rows, or will be within three years? Leans Dataverse.
2. Money on the records (invoices, payments, payroll hours, anything an accountant reconciles)? Leans Dataverse.
3. More than three people editing on the same day? Leans Dataverse.
4. Three or more tables that genuinely relate (not just a lookup)? Leans Dataverse.
5. Need to prove who changed what and when? Dataverse.
6. Mostly no to 10 to 14? SharePoint lists, no extra licence. Mostly yes? Dataverse, at NZ$32.40 per user per month on Microsoft's NZ price list. The reasoning: SharePoint or Dataverse.
7. Licence line written down against real headcount, per month and per year, before the build is priced.
8. Considered not migrating: supported vendor product, fine server with a bad front end, or under 500 rows and one user.

3. Fix the source first

1. Delete or archive the tables nobody uses, with sign-off from whoever owns the data.
2. Access Single and Double columns changed to Decimal if precision past five places matters (Dataverse floats keep five).
3. Unique indexes listed, because they do not migrate automatically and become alternate keys by hand.
4. Multi-value lookups and choice lists documented, so they map to Choice columns cleanly.
5. Bad dates, orphaned rows and duplicate keys found and fixed in the source, not patched in the target.
6. Column names translated: what "fld_x2" means, written next to it.

4. Trial load

1. A separate dev environment or site, never the live tenant on the first attempt.
2. Loaded by a repeatable method (Power Platform dataflows, Microsoft's Access export to Dataverse, or a scripted import), so it can run again on cut-over day.
3. Row counts reconciled per table against the source, and a handful of known records checked by hand.
4. Every validator failure read and either fixed at the source or accepted in writing.
5. Autonumbers continue the old sequence for job and invoice numbers where the business relies on them.

5. Rebuild the front end and logic

1. Each stored procedure, trigger and macro mapped to a flow, a business rule, app logic, or deliberately dropped, in a table you can read.
2. The app built around the three things people do, not a copy of the old grid.
3. Tested by the two people who know the old system best, on the devices they actually use.
4. Every integration from item 6 re-pointed and tested end to end.
5. Reports rebuilt as views or Power BI, and the one report the owner looks at on Friday confirmed working.

6. Cut over

1. A named cut-over day, usually a Friday, with the old system frozen read-only from that afternoon.
2. Final load, counts and totals reconciled, sign-off recorded before Monday.
3. Old server or file kept intact and switched off for 60 days, then wiped and disposed of properly.

7. Hand-over

1. Source, credentials and admin rights in your own accounts, not the provider's.
2. A written map of what lives where, which flows exist, who owns each, and what licence each person holds, plus a warranty period and a plain answer to what happens if the provider is unavailable.

Why the trial load runs on a copy of real data, and what made-up records are still good for: building on fake data first.

Copying this checklist

Copy it freely, with a link: SQL Server and Access migration checklist, Kove, September 2026. kove.nz/sql-migration-checklist. If you want the same list applied to your system with the answers filled in, that is what the first call is for.

The same list is on GitHub as Markdown, with a read-only T-SQL script that answers most of section 1 in one run and a PowerShell script that maps a database's columns to Dataverse types: sql-to-dataverse-migration-checklist. Fork it, fix it, hand it to your provider.