Converting a legacy Access database is one of the most consequential technology decisions a small or mid-sized organization can make. Done well, it eliminates years of technical debt and opens the door to mobile access, real-time collaboration, and modern integrations. Done poorly, it disrupts operations and destroys institutional knowledge baked into the original system. This guide walks through the full process — from deciding whether to migrate at all, through choosing the right platform, to executing the conversion successfully.
First, decide whether migration is actually necessary
Not every old Access database needs to be replaced. Before committing to a migration project, answer these questions honestly:
Is the current system causing real operational pain — crashes, data loss, user workarounds, or compliance gaps? Are there users who need access from mobile devices or outside the office network? Is the organization moving to cloud-first infrastructure that makes a locally-hosted .accdb file increasingly awkward? Is the database approaching the 2 GB file size limit? Are there security or audit requirements the current system cannot meet?
If the answer to most of these is no, a well-maintained Access database with a split front-end/back-end architecture may be perfectly adequate for years to come. Migration for its own sake is expensive and risky. Migration to solve a real problem is an investment.
Understand what you actually have before touching anything
The single biggest mistake in Access migration projects is underestimating the complexity of the existing system. Before any platform decision is made, conduct a thorough inventory:
Tables and data volume. How many tables? How many records in each? Are relationships properly enforced with foreign keys, or is referential integrity being maintained informally through application logic?
Queries. How many queries exist, and what do they do? Pay particular attention to action queries (updates, deletes, appends, make-table) — these embed business logic that must be replicated in the new system.
Forms and user workflows. How do users interact with the system? Are there complex forms with subforms, conditional formatting, calculated controls, or cascading dropdowns? Each of these represents logic that needs to be rebuilt, not just migrated.
Reports. What reports exist, who runs them, and how often? Some reports are critical; others haven’t been opened in years. Don’t rebuild what nobody uses.
VBA code. This is where legacy Access databases hide most of their complexity. Open every module, every form’s code-behind, and every report. Document what the code does in plain language. VBA automation, custom validation, API calls, and inter-application integrations (Outlook, Excel, Word) all require explicit handling in the new platform.
Macros. Older databases built before VBA was standard may use legacy Access macros. These need to be understood and translated.
External dependencies. Does the database link to external tables in SQL Server, SharePoint, or other Access files? Does it import or export data from Excel or CSV? Does it send email through Outlook? Each dependency is a thread that runs through the migration.
Choose the right destination platform
There is no single right answer. The best destination depends on your organization’s existing infrastructure, the complexity of the application, and your budget.
Microsoft Power Apps + Dataverse is the natural modern successor to Access for most business applications. Dataverse is a proper relational database with role-based security, audit logging, and enterprise compliance built in. Power Apps provides the form and UI layer. Power Automate replaces VBA automation and workflow logic. If your organization is already in Microsoft 365, this stack costs little to nothing incrementally and integrates natively with Teams, SharePoint, and Outlook. It is the right choice for most internal business applications that need to go mobile, go cloud, or go multi-user beyond Access’s practical limits.
Access front-end + SQL Server back-end is the lowest-disruption path when the Access forms and reports are still serving users well but the data layer is the problem. You migrate the tables to SQL Server, relink them in Access using ODBC, and the front-end continues to work largely unchanged. This eliminates the file size limit, improves concurrent user handling dramatically, and gives you enterprise-grade data security — without requiring a full application rebuild. It is the right choice when the Access UI is working fine and the problems are purely at the data layer.
SharePoint Lists + Power Apps works well for simpler data models with moderate record volumes. SharePoint lists have their own limitations (list view threshold, limited relational capability), but for straightforward applications with a few tables and a few hundred to low thousands of records per list, this is a cost-effective and highly accessible option.
Azure SQL + custom web application is the right choice when the application needs to be public-facing, requires complex business logic, or will serve a large user base. This is a full redevelopment project — not a migration — and carries the cost and timeline of custom software development. Reserve this path for applications that genuinely require it.
Other low-code platforms — Airtable, Zoho Creator, AppSheet, and similar tools — are sometimes considered. They can work for simple use cases but introduce a new vendor dependency outside the Microsoft ecosystem, which creates long-term integration friction for organizations already running on M365. Evaluate carefully before leaving the Microsoft stack.
Design the new data model before writing a single line of anything
Migrating an old Access database is not the same as copying it. Legacy Access databases frequently have data model problems — redundant fields, denormalized tables, calculated values stored instead of derived, and relationships that exist informally rather than structurally. The migration is an opportunity to fix these problems, not replicate them in a new environment.
Review each table and ask whether it is properly normalized. Ensure every table has a meaningful primary key. Map relationships explicitly and confirm they reflect how the data actually behaves. Identify lookup tables that should be driving dropdowns but are instead hard-coded in VBA. Clean up field naming conventions — Access tolerates spaces in field names; most modern platforms technically allow them but it creates pain downstream.
If the existing data model is sound, replicating it in the new platform is straightforward. If it has grown organically over fifteen years without intentional design, the migration project is also a database redesign project. Budget accordingly.
Migrate and clean the data
Data migration from Access to a modern platform typically follows this sequence:
Export tables from Access to CSV or Excel. Inspect the data for quality issues — duplicates, nulls in required fields, broken foreign key references, inconsistent formatting, values that should be in lookup tables but were typed freehand. Clean the data before loading it into the new platform, not after. Load into the destination using the platform’s import tools, a Power Automate flow, or a script depending on volume and complexity. Validate record counts and spot-check values against the source. Run any calculated fields or derived values and confirm they match expectations.
Data quality problems that were invisible in Access — because the application worked around them — become highly visible when you load data into a platform with stricter data typing and relational enforcement. Budget time for this. It is almost always more work than expected.
Rebuild the application layer
This is the largest portion of the project for complex databases. Every form, workflow, and report in the old Access application needs a counterpart in the new platform.
For Power Apps specifically: canvas apps give you the most control over layout and behave most like Access forms; model-driven apps give you less design flexibility but inherit Dataverse’s built-in views, forms, and business rules automatically, which is faster for straightforward data entry applications. Power Automate replaces VBA automation for workflow triggers, email notifications, approvals, and scheduled tasks. Power BI or built-in Dataverse reporting replaces Access reports for analytical output.
Rebuild in order of user impact — the screens users touch every day first, the rarely-used reports last. Involve actual users in review during the build, not just at the end. The institutional knowledge of how the old system worked lives in the people who used it, not in the documentation (which probably doesn’t exist).
Run both systems in parallel before cutting over
Never cut over to a new system cold. Run the old Access database and the new application in parallel for a defined period — typically two to four weeks for moderately complex systems. Users enter data in both systems during this period, or enter in the new system and validate against the old. This surfaces gaps in functionality, data model mismatches, and workflow logic that was replicated incorrectly. It also gives users time to build confidence in the new system before the old one disappears.
Define a hard cutover date in advance and hold to it. Parallel running periods that have no endpoint tend to drift indefinitely, which doubles the operational burden and undermines adoption of the new system.
Train users and document the new system
Users who have worked with an Access database for years have deep muscle memory for exactly how it behaves. A new platform will do things differently — navigation, search, data entry, report generation. Training is not optional and should not be a single one-hour session the day before launch.
Document the new system in plain language: how to enter records, how to run common queries or views, how to export data, who to contact when something breaks. Screenshots help. Video walkthroughs help more. A reference document that lives on SharePoint and is actually maintained after launch is worth more than a training deck that nobody can find six months later.
What the project actually costs
Access migration projects are routinely underestimated. A realistic framework:
A simple database — five to ten tables, basic forms, no complex VBA, clean data — might take forty to eighty hours of professional development time to migrate to Power Apps on Dataverse, including data migration and testing.
A moderately complex database — fifteen to thirty tables, significant VBA automation, custom reports, external integrations — typically runs one hundred fifty to three hundred hours.
A complex legacy system — thirty-plus tables, extensive business logic in VBA, multiple external dependencies, years of data quality debt — is a project measured in months and can exceed five hundred hours of work.
These ranges assume a competent developer who knows the destination platform. Organizations that attempt migration with staff who are learning the platform simultaneously should expect timelines to stretch significantly.
The payoff
A well-executed Access migration delivers things the old system simply cannot: access from any device, anywhere; proper security with individual user accountability; automated workflows that run without someone remembering to trigger them; a data layer that scales without hitting file size walls; and integration with the rest of the modern Microsoft 365 ecosystem.
More than the technical improvements, it delivers confidence — in the data, in the process, and in the organization’s ability to build on the system rather than just maintain it.
That confidence is what the project is really for.
Ready to talk through your options? Reach out to Anthony at AccessEvolved — email anthony@accessevolved.com or call 212-951-1010. No sales pitch, just a straight conversation about what makes sense for your situation.