Microsoft Access Database Migration

Why Access databases reach their limits

Microsoft Access let a capable person build a working business system in a few weeks, which is why so many companies still run orders, inspections, member records or production tracking on one. The problems arrive slowly. The file grows toward the 2 GB ceiling, several people open it over a network share, and a dropped Wi-Fi connection corrupts a table. Someone runs compact and repair every Friday, and only one person understands the VBA. Tepia hears a version of this story at the start of almost every Access migration.

Remote and mobile work made it worse. Access was designed for a local network, so opening a shared back end over a VPN is slow and fragile, and there is no native way to use it from a phone or tablet. Security is coarse as well: anyone who can copy the file can take the entire database home. Office updates add another risk when 32 bit and 64 bit installs disagree about an old ActiveX control or Windows API declaration.

Inventorying the Access application

Before moving anything, Tepia catalogs every object in the database and decides where each one goes. A typical inventory looks like this:

Usage review and interviews often show that a good share of objects are no longer used. Retiring them shortens the project and makes the new app easier to learn.

A two stage migration: data first, screens second

Tepia prefers to migrate an Access application in two stages because it lowers risk. In the first stage the tables move to a server database. Microsoft’s SQL Server Migration Assistant for Access handles much of the mechanical work, and Tepia fixes what it cannot, such as Yes or No fields, attachment columns, multivalued fields and data that Access tolerated but a stricter server rejects. The Access front end is then relinked to the new tables, so staff keep the same forms while the data gains backups, permissions and room to grow.

In the second stage Tepia rebuilds the front end as a web app in React with a .NET or Node.js API, plus mobile screens where field staff need them. Because the data already lives on the server, each new screen can go live as soon as it is ready, and the matching Access form is retired. The last Access form disappears at cutover rather than everything changing on one stressful Monday.

Connecting the migrated system to the rest of the business

Access databases often sit at the center of a web of manual imports. Every morning someone downloads a CSV from the ERP, imports it, runs three queries and emails a report built with Outlook automation. Once the data lives in SQL Server or PostgreSQL, Tepia replaces those steps with scheduled integrations:

• ERP and accounting connections to QuickBooks, NetSuite or Dynamics 365 for customers, items and transactions.
• Email and text alerts through SendGrid and Twilio instead of Outlook automation on one desktop.
• Single sign on with Microsoft Entra ID, so access follows employee accounts rather than a shared password.
• Direct reporting connections for Power BI or other BI tools, which read the server database without touching the app.

Our data integration and ETL team builds these pipelines with logging, so a failed import raises an alert instead of leaving a silent gap.

How Tepia approaches Access database migration

Tepia follows its six phase process for Access migrations, with a US based project manager who keeps daily operations running while the new system takes shape.

1. Discovery: an object by object inventory of the database, interviews with daily users, and a review of every file and system it imports from. Deliverables are an Investigation Summary with the object catalog, an Interview Summary and User Stories such as an inspector logging a result from a tablet.
2. Design: a design questionnaire, moodboards, a style guide and wireframes that combine cramped Access forms into clear screens organized by role.
3. Development and Testing: stage one data migration with relinked tables, then an Alpha and Beta of the new web app, with test plans that compare query and report outputs against Access.
4. Training: hands on sessions built around the tasks people did in Access, so each person sees where their old form went.
5. Launch: final data sync, retirement of the Access front end, and support reps available as the last users switch over.
6. Support: issue resolution, bug tracking and new features that were never practical in Access, such as customer facing status pages.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month, and staff keep working in Access throughout. More on our process.

Upsize only, Power Apps or a custom rebuild

There are three realistic paths, and Tepia recommends the smallest one that solves your problem.

• Upsize only: move the tables to SQL Server and keep the Access front end. This fits a small team on one office network that mainly needs reliability and backups.
• Power Apps: rebuild simple forms on Microsoft’s low code platform. This suits companies standardized on Microsoft 365 with straightforward workflows and internal users only.
• Custom web and mobile app: the right choice when you need outside users such as customers or contractors, offline mobile use, complex VBA logic carried forward, or integrations with several systems.

Read Power Apps vs a custom app and our legacy system modernization overview, then contact Tepia with a copy of your database structure.

Frequently asked questions