Replacing Microsoft Access with Power Apps and Dataverse

Many small and mid-sized companies have an Access database that has been running for fifteen years. It handles quotes, the equipment fleet or customer files. It works, and that is exactly the problem: nobody dares to touch it. The person who built it has left or is about to, the file sits on a network drive, and opening it with two people at once is an adventure.

If that sounds familiar, you are not behind: you have a database that served you well. But it has limits you are already paying for. Here is what replacing Access with Power Apps and Dataverse actually means, what gets migrated, the known pitfalls, and an approach that does not stop the business.

Why replace Access now

• Sharing. Access is built for one workstation, or a few on the same network. No mobile, no access from another site, no remote colleague without workarounds.
• Dependence on one person. Forms, queries and VBA macros are documented only in their author's head.
• Fragility. A file on a network share, opened by several people, ends up corrupted one day. And an .accdb file tops out at 2 GB.
• Isolation. Access does not talk to Teams, Outlook or Power BI without manual exports.

Power Apps and Dataverse live inside your Microsoft 365. Your data stays in your tenant, reachable from a browser or a phone, with the permissions of the accounts you already have.

What gets migrated, and where to

An Access database mixes four layers. Each has an equivalent in Power Platform:

1. Tables go to Dataverse. For a very simple database, a few unrelated tables, a SharePoint list can do. But as soon as tables are linked (customers, orders, order lines), Dataverse is the right choice: it handles relationships natively.
2. Forms become Power Apps screens. We do not copy them: we redesign them for the browser and for mobile, often with fewer fields.
3. Queries and reports become Dataverse views, list screens, or Power BI reports for the analysis part.
4. Macros and VBA become Power Automate flows (sending mail, reminders, status calculation) or rules inside the app.

Access for Microsoft 365 includes a tool to export tables to Dataverse, which migrates the data and can link the old Access front end to the new tables. It is handy for a gradual transition. Check that your version of Access has it.

The known pitfalls of an Access migration

Relationships and identifiers. Access numbers its records with AutoNumber fields. Dataverse has its own identifiers. You need a mapping table so that orders find their customers again after migration. That is prepared, not improvised.

Attachments. Access attachment fields and OLE objects are heavy and do not migrate in one click. We move them to SharePoint or to Dataverse file columns, with a link from the record. Count them first: a hundred PDFs is not ten thousand.

Volumes and storage. Dataverse capacity is counted separately from your Microsoft 365 licences. A 50,000-row database is no problem. A database holding twenty years of history deserves sorting: what stays active, what gets archived?

VBA. There is no converter. Every macro gets reread, and the first question is whether it is still needed. Often half the code answers a need from 2012.

Licensing. Dataverse is a premium component. Expect a Power Apps licence per user, around 20 euros (or dollars) per user per month for the full licence, less for a licence limited to a single app; check the current Microsoft price list. Our article on what is included and what is premium goes into detail.

A step-by-step approach that keeps the business running

The good news: nothing switches over on a Monday morning. Here is the order that works.

1. Inventory. List tables, forms, queries, macros. Flag what is still used. This step alone often drops a third of the database.
2. Scoping. Redesign the target process, not the current database. A two- to three-day scoping is enough to freeze the scope and price what comes next.
3. Data model. Create the Dataverse tables, relationships and permissions. Migrate a sample of the data to test.
4. Screens and automations. Build the app, connect Outlook, Teams, SharePoint.
5. Real migration and testing. Load all the data, have users test on real cases, fix, go live.
6. Access in read-only. Keep the old database for a few weeks, locked, while you check nothing is missing.

The result is not "Access in a browser". It is an application that does the same job, better: reachable by everyone who needs it, on mobile, with a history, and with data ready for your dashboards. The steps, deliverables and warranty are described in our method.