The short version: Moving a small business off an old database takes 2 to 4 weeks for an Access file going into SharePoint lists and 3 to 6 weeks into Dataverse, and 2 to 5 or 3 to 8 weeks for SQL Server, on my fixed-price bands for firms under 20 staff. Copying the data is the quick part; rebuilding the forms and logic is where the weeks go.
How long it takes, by source and destination
| Moving from | Into SharePoint lists | Into Dataverse |
|---|---|---|
| Access database | 2 to 4 weeks, $4,000 to $10,000 | 3 to 6 weeks, $8,000 to $18,000 |
| SQL Server database | 2 to 5 weeks, $4,000 to $10,000 | 3 to 8 weeks, $8,000 to $18,000 |
These are my fixed-price bands for a firm under 20 staff, the same numbers as on moving an Access database to Power Apps and moving SQL Server to Dataverse. The weeks are calendar time from the day work starts to the day you are live, with the data migration, validation and cut-over included. Dataverse then costs NZ$32.40 per user per month; SharePoint lists cost nothing on top of Microsoft 365.
Where the weeks go
This is how I scope a six-week Dataverse move of an Access file. It is an estimate of shape, not a measured average across jobs, and it moves with the database.
| Stage | Typical share of the calendar | What happens |
|---|---|---|
| Inventory and decisions | Days 1 to 3 | Tables, row counts, forms, macros, anything outside that links to it, and the SharePoint or Dataverse call |
| Trial migrations | Two or three passes in week 1 to 2 | Read what the validator rejects, fix it at the source, run again until clean |
| Rebuild forms and logic | Weeks 2 to 5, the bulk | A Power App and flows built against the migrated data, with the old front end still working |
| Parallel checking | About a week, overlapping | The two people who use the old forms most try the new ones on real records |
| Cut-over | A Friday to a Monday | Freeze, final load, reconcile row counts and known records, go live |
| Old database kept | 60 days after | Left intact and read-only, switched off from daily use |
The step-by-step for each source is on the Power Platform migration hub, and the working document I use is the 38-point checklist.
What makes it longer
| Factor | Effect on the schedule |
|---|---|
| Undocumented VBA or modules nobody can explain | Plan for the top of the band and about a week of reading code |
| Stored procedures, triggers and scheduled jobs (SQL Server) | Each one that matters becomes a flow, business rule or line in the app; logic hidden in them moves a job up the range faster than table count does |
| Things outside the database that connect to it | A label printer, an ODBC link from Excel, a Xero sync: each is found late and added to the list |
| Dirty data | Rows the validator rejects are usually real problems hiding in the old system for years; fixing them takes the time it takes |
| Two busy users | The old forms are the spec, so the two people who use them most need time on the calendar; a fortnight of holidays in the middle adds a fortnight |
What keeps it inside the band
- Say up front that the goal is the same behaviour first and changes later. Every improvement asked for mid-build is a second project.
- Keep the old system running and linked while the new one is built, so there is no deadline forcing a rushed cut-over.
- Cut over on a Friday with a rollback: the old database untouched for 60 days.
- Book the two heaviest users for an estimated two to three hours a week during the rebuild (my estimate, not a measured figure).
When it takes longer than eight weeks
Past about twenty tables, several integrations or a system with real money moving through it, I would re-scope rather than stretch the band: move the core in one phase and the rest in a second, each with its own cut-over. That is a judgement, not a rule, and I say so on the intro call rather than quote a longer number without a reason.
What the copy has to match, and how to prove it does, is in moving a desktop database without changing how you work.
Why the trial migrations come first, and what they are run on, is in building on fake data before the real records.
Common questions
How long does it take to move an Access database to Power Apps?
Two to four weeks into SharePoint lists or three to six weeks into Dataverse, for a firm under 20 staff, with data migration and cut-over included. The tables move with Microsoft's export tool quickly; the forms, reports and VBA are rebuilt, and that is where the time goes.
How long does it take to move a SQL Server database to Dataverse?
Three to eight weeks into Dataverse or two to five into SharePoint lists. SQL Server sits toward the top of each band because of stored procedures, scheduled jobs and integrations that have to be rebuilt as flows and app logic.
How much downtime is there when we switch over?
A weekend. I freeze the old system on a Friday, run the final load, check row counts and a handful of known records, and you go live on Monday. Until then the old system keeps working.
Can we keep using the old database while the new app is built?
Yes. The old front end stays linked and usable throughout, and the old database is kept read-only for 60 days after go-live in case anything needs checking.
What does the move cost on top of the weeks?
$4,000 to $10,000 into SharePoint lists or $8,000 to $18,000 into Dataverse at a fixed price, plus NZ$32.40 per user per month for Dataverse (Power Apps Premium, paid yearly, on Microsoft's NZ list). SharePoint lists cost nothing on top of Microsoft 365.
Get the weeks for your database
Tell me the source, the number of tables and who uses it. Book a free 30-minute call and you leave with a band and a schedule, or a plain no if a smaller fix will do.