From Excel and Access to a Web App: A Migration Roadmap for US Operations Teams

Some limits are hard numbers. Microsoft's Access specifications cap a database file at 2 gigabytes, minus space for system objects, and list 255 concurrent users as a maximum. In practice, files shared over a network drive slow down and risk corruption long before that many people edit at once. The Excel specifications and limits allow 1,048,576 rows by 16,384 columns per worksheet, but lookups across large workbooks become painfully slow well short of that.

Support dates matter too. Microsoft's 2025 end-of-support list shows Access 2016, Access 2019, Excel 2016 and Excel 2019 reaching end of support on 14 October 2025. If a business-critical tool still depends on those versions, it no longer receives security updates.

The softer signs are usually what force the decision:

• One person understands the VBA, and everyone worries about their vacation.
• Files named "Inventory FINAL v7 (2).xlsx" circulate by email.
• Nobody can answer who changed a price or a quantity, or when.
• Month-end means copying data between three workbooks by hand.
• Customers or auditors ask for reports that take a day to assemble.

Phase 1: Inventory what the files actually do (1–2 weeks)

List every workbook and database involved, then every table, query, form, report and macro inside them. For each, record who uses it, how often, and what leaves the building: invoices, compliance filings, customer reports. Hidden logic lives in conditional formatting, lookup formulas and macros that run on open. If it changes a number, it goes on the list.

Phase 2: Design the data model (1–3 weeks)

Spreadsheets mix data, calculations and presentation. A database separates them. Turn repeated text into lookup tables, give every record a stable ID, define which fields are required, and decide what happens to duplicates. This is where you clean data: one customer spelled four ways becomes one customer record with a history.

Phase 3: Move the data to a server database first

For Access, Microsoft's SQL Server Migration Assistant for Access moves tables and data to SQL Server or Azure SQL. You can then relink the Access front end to the new tables, so users keep their familiar forms while the 2 GB ceiling and file-locking problems disappear. If you prefer an open-source stack, PostgreSQL works just as well; the migration scripts are simply custom. Excel data is imported through validated scripts that reject bad rows and produce a report of what failed and why.

Phase 4: Rebuild workflows as web screens, one at a time

Rank workflows by pain: error rate, hours spent, and business risk. Rebuild the worst first. Each rebuilt workflow gets role-based permissions, an audit trail that records who changed what, validation at the point of entry, and an export button, because people will still want a spreadsheet for analysis. Write every macro and formula down as a test case before rewriting it, so you can prove the web app produces the same answer.

Phase 5: Parallel run, cutover and archive

Run the old and new systems side by side for one or two full business cycles, usually a month-end. Reconcile totals daily. When they match, make the old file read-only, archive it with a date, and announce a single source of truth. Keep the archive; auditors and future you will want it.

If you already pay for Microsoft 365, Power Apps can turn simple forms and approvals into apps quickly, and it connects naturally to SharePoint and SQL Server. It suits small user groups and straightforward logic. The trade-offs show up later: per-user licensing as headcount grows, complex business rules that become hard to maintain in a visual builder, and a platform you cannot take elsewhere.

A custom web application costs more upfront. In return, you own the code, you can model complex rules properly, and you can integrate with anything that has an API, such as QuickBooks, Salesforce, a shipping carrier or your bank's file formats. A reasonable rule: if the tool is internal, simple and used by a small group, try low-code first. If it runs a core process, touches customers or must integrate deeply, build it.

Migration is not a chance to throw away everything people rely on. Keep:

• The exports your staff use, as an Excel or CSV download on every list.
• Report layouts that finance or compliance has already signed off.
• Business rules buried in formulas and macros, now documented and tested.
• Historical data, migrated where it is clean and archived read-only where it is not.
• Familiar terms. If your staff call it a "work ticket", the web app should too.

The main cost drivers are the number of workflows, the integrations, the state of the data, the number of user roles and the reporting you need. A single-workflow tool with clean data sits at the low end; a multi-department system with accounting and CRM integrations sits well above it.

We do not publish a price list, because two Access databases of the same size can hide very different amounts of logic. After a short discovery call, we send a written scope and a fixed quote. During the build you see working software on a staging server every two weeks, and the source code and accounts are set up in your company's name. Our legacy modernization work follows the five phases above. The largest consolidation we have done was ERPSetu, where we merged 17 of our earlier ERP codebases into one product for Indian businesses.

Can we keep using Excel for reporting after the migration?

Yes. Most teams keep Excel for ad hoc analysis. Give it a read-only connection to the database or an export from the web app, so the spreadsheet becomes a view of the data rather than the place the data lives.

Do we have to move to SQL Server?

No. SQL Server is a natural fit for Microsoft shops, and Microsoft's migration assistant helps with Access. PostgreSQL and MySQL are also solid choices. Pick the database your team or vendor can support for the next ten years.

How do we avoid disrupting daily operations?

Rebuild one workflow at a time, keep the old front end working against the new database during the transition, and cut over only after a parallel run reconciles. Nobody should arrive on a Monday to find their tool gone.

What if our Access application has years of VBA in it?

That is common. Treat each macro as a requirement: document what it does, write a test that captures its output, then rebuild the behavior in the web app. Some macros turn out to be workarounds for problems the new data model removes entirely.

If you have an Access database or a workbook that has become a system, book a scoping call. Send a copy of the file structure with sample data removed, and we will tell you which phase to start with and what a fixed-scope first release would cover.