When an Access database has reached its limits, the first strategic decision is whether to migrate or rebuild. Migration means keeping some or all of your existing application while changing the database engine. Rebuilding means starting over with a new application and new database.
Both approaches have real trade-offs, and the wrong choice can cost you months of wasted effort. Here is how to evaluate your situation.
What Migration Looks Like
The most common migration path is “upsizing” — moving your data tables from Access to a server database (SQL Server, MySQL, MariaDB, or PostgreSQL) while keeping your Access forms, reports, and VBA code as the front-end.
What changes: The data storage engine. Your tables live on a server instead of in a file. Queries run on the server instead of locally.
What stays the same: Your forms look and work the same. Your reports generate the same output. Your VBA code runs the same business logic (with some modifications for SQL dialect differences).
What you gain: Multi-user reliability, data security, crash recovery, better performance with concurrent users, and no more corruption.
Typical scope: Weeks to a few months, depending on complexity. Most of the work is testing and fixing the queries and VBA code that do not translate cleanly.
What Rebuilding Looks Like
A rebuild means creating a new application using modern tools — a web application, a desktop application in Python or C#, or a Power Platform solution. The Access application is retired completely.
What changes: Everything. The user interface, the business logic, the database, the deployment model.
What stays the same: Your data (which migrates to the new system) and your business requirements (which the new system must implement).
What you gain: Modern architecture, web/mobile access, proper security, scalability, modern development tools, easier maintenance.
Typical scope: Months to years, depending on the complexity of the Access application.
When to Migrate
Migration is the right choice when:
Your Access application works well. If the forms are well-designed, the reports are accurate, and the VBA code implements your business logic correctly, there is no reason to throw that away. The problem is the database engine, not the application. Fix the database engine.
You need results quickly. Migration can be done in weeks. A rebuild takes months. If your database is corrupting weekly and users are losing data, you need a fix now.
Your team knows Access. If the people maintaining the application are Access developers, they can maintain the migrated application. A rebuild to a web framework means hiring new skills or retraining.
Budget is limited. Migration costs a fraction of a rebuild. You are changing one component (the database) instead of rebuilding everything.
The application is large. An Access application with 200 forms, 50 reports, and thousands of lines of VBA represents years of accumulated business logic. Rebuilding all of that is a massive undertaking with enormous risk of missing requirements.
When to Rebuild
Rebuilding is the right choice when:
The Access application has fundamental design problems. If the database schema is poorly normalized, the forms are tangled and unmaintainable, and the VBA code is spaghetti, migrating just preserves the mess. You would be moving a poorly designed application from one database to another.
You need capabilities Access cannot provide. Web access, mobile access, role-based security, API integrations, real-time collaboration — these require a different application architecture, not just a different database.
Nobody understands the existing application. If the person who built it is gone and nobody can explain why things work the way they do, migrating preserves complexity that nobody can maintain. A rebuild forces you to rediscover and document the business requirements.
The application is small. If the Access database has 10 forms, 3 reports, and simple business logic, rebuilding it in a modern framework may take less time than you think. The threshold varies, but applications with fewer than 20 forms are often faster to rebuild than to carefully migrate.
You are making major business process changes anyway. If the business is changing how it operates — new workflows, new requirements, different user roles — a migration preserves the old way of doing things. A rebuild lets you design for the new way from the start.
The Hybrid Approach
You do not have to choose one or the other for the entire application. The hybrid approach works like this:
- Migrate the data to a server database immediately. This solves the corruption, locking, and performance problems right away.
- Keep the Access front-end for now. Users keep working with familiar forms.
- Gradually rebuild individual forms or modules in a new technology. Replace the Access forms one at a time with web forms or a desktop application.
- Retire Access when all forms have been replaced.
This approach gives you the stability benefits of migration immediately while spreading the rebuild effort over time. Each piece can be done, tested, and deployed independently.
The key requirement is that your new front-end can connect to the same server database. Since the data is in SQL Server, MySQL, or PostgreSQL, any modern development framework can connect to it.
Questions to Ask Yourself
Before deciding, answer these honestly:
Do your users have significant complaints about the user interface? If yes, lean toward rebuild. If no, lean toward migrate.
Can you find someone who can explain every form and report in the application? If no, lean toward rebuild with fresh requirements gathering.
Do you need web or mobile access? If yes, you need a rebuild for at least those components.
What is your budget? If limited, migrate now and plan for a rebuild later.
What happens if you do nothing for six more months? If the answer is “data loss” or “business disruption,” migrate now. If the answer is “continued annoyance,” you have time to plan a rebuild.
How many forms, reports, and lines of VBA code? Count them. A small application (under 20 forms) is reasonable to rebuild. A large application (over 100 forms) is a major rebuild project that deserves careful planning.
The Most Common Mistake
The most common mistake is underestimating a rebuild. Organizations decide to “just rewrite it in a modern framework” without realizing how much business logic is embedded in the Access application. A form that “just shows customer data” may also enforce business rules, calculate derived values, trigger email notifications, update related tables, and generate PDF documents.
When you migrate, you keep all of that automatically. When you rebuild, you have to rediscover, redesign, and reimplement every piece. Miss one, and users will tell you the new system is “missing features” — which is really just business logic that nobody documented.
If you rebuild, budget at least 50% more time and money than your initial estimate. Access applications always contain more complexity than they appear to.
The Bottom Line
Migrate if the application works well and you just need a better database engine. Rebuild if the application itself is the problem. Use the hybrid approach if you need immediate stability but also want to modernize over time.
In practice, most organizations should migrate first and rebuild later. Migration is faster, cheaper, lower risk, and solves the most urgent problems immediately. It buys you time to plan and execute a rebuild properly, if a rebuild is even necessary.