Imagi-Tech

Software

Microsoft Access to a Web App: Cost, Timeline and What Moves

Microsoft Access migration cost for a web app comes down to how many forms, reports and pieces of code have to be rebuilt to run in a browser. We price it as a fixed quote in writing after a free audit, and a single-department database usually takes eight to twelve weeks from audit to cutover.

Most owners who call us about an Access database ask two things first: what will it cost, and how long will the shop run on two systems? This guide answers both for the route most of them end up on, which is to convert the Access database to a web app that runs in a browser. For a line-by-line look at what pushes a quote up, see our guide to what a Microsoft Access migration costs.

What a typical Access migration costs

There is no typical price, and we don’t publish one. The number is set by what has to be rebuilt, and two files of the same size can be very different jobs. What is typical is how the price gets set:

  • A free audit first. We document every table, query, form, report and macro in the file. You keep the audit whether or not you hire us.
  • A fixed quote in writing. The scope, the price and the month you switch over go into the quote before anything is billed.
  • A web app costs more up front than keeping Access. Every form and report is rebuilt to run in a browser, so nothing from the old screens carries over.

The cheaper route keeps the Access screens and moves only the tables to SQL Server. For a small business, an Access to SQL Server migration is often the first option on the table, and for one office on one network it can be enough. It stops paying off when people need the system from a truck, a job site or home, or when the VBA itself is the problem. The audit says which side of that line you are on. Sometimes it says to leave the file alone for now.

How long it takes, module by module

Every timeline here runs from audit to cutover, with the parallel run inside it:

  • One department, one job: eight to twelve weeks.
  • Several departments in one file: about three months.
  • A multi-module system: up to a year.

A module is one job the database does: estimating, job costing, order entry, renewals. A file that does several jobs doesn’t have to move all at once. We phase it so the module that is forcing the issue ships first, and the rest follow in stages while the business keeps running. Each module goes through the same four pieces: audit, blueprint, prototype, then a parallel run before that part of the old file is switched off.

Two things stretch a schedule more than size does. The first is business rules buried in VBA, which have to be found and written down before anything is rebuilt. The second is dirty data: dates typed as text, or the same customer under four spellings. Both turn up in the audit, so they are in the schedule before you sign it.

If your year has a busy season or a hard month-end, the cutover is planned around it, never across it.

What moves cleanly and what gets rebuilt

When you replace a Microsoft Access database with a web app, the data and the screens go two different ways. The data moves. The screens and the code are rebuilt.

What moves cleanly:

  • Tables and records. The data comes across with tools and checks. Row counts and totals on the key number columns are compared at both ends, and staff spot-check records they recognize.
  • The history. Years of customers, jobs and orders come with you once the duplicates and bad dates are cleaned up.

What gets rebuilt:

  • Forms. Each screen is rebuilt to work in a browser on a desk, a tablet or a phone. We keep the layout people know where it works, so the new screens look familiar on day one.
  • Reports. Invoices, pay sheets and month-end reports are rebuilt to match the old printouts, because someone will hold the two side by side.
  • VBA and macros. The code doesn’t run in a browser, but the rules inside it carry over. Each one is found, written down and rebuilt, so it no longer lives only in the code.
  • Imports and exports. The Excel import, the QuickBooks export and the email sent through Outlook are each rebuilt and tested.
  • Working offline. If crews use it where the signal drops, the app has to save their entries and sync later. That choice shapes the build, so it is made in the blueprint.

What gets dropped, on purpose: queries nobody has run in five years, and forms for a process that ended. Each one is listed and dropped in the open, so nothing disappears quietly.

In return you stop paying for Access licenses and stop working inside a 2 GB file limit. The office, staff at home and crews in the field all use the same system.

Running both systems side by side

Your staff keep using the Access file the whole time we build. Once the web app is ready, both run live. Work goes into both, and we compare the outputs until they agree. Then the old file goes read-only and stays around for a set period before anyone deletes it.

Run both through at least one full cycle that carries risk for you. If month-end is your hard date, that means at least one month-end in both systems. It doubles the data entry while it runs, and it is where you find a rounding difference or a missing category while it is still cheap to fix. Our post on retiring Microsoft Access without stopping the shop walks through the parallel run step by step.

Examples by industry: construction, insurance, wood products

What gets compared during the parallel run depends on the trade. These are the systems we most often find in each one, and the numbers that should agree before the old file is switched off.

  • Construction. Estimating and bid tracking, job costing, change orders and field time logs live in the file. Job cost totals, change order amounts and field hours should match in both systems. Field hours are also where a web app earns its keep: crews enter them on a phone and they land in payroll without retyping. More on Access migration for construction.
  • Insurance. Policy records, claims tracking, and renewal and commission reporting are the usual pieces. The renewal list and the commission report should come out the same from both systems, so nothing lapses during the switch.
  • Wood products. Log and lumber inventory by species and grade, kiln schedules and moisture records, and order entry with tally sheets. The tally by species and grade should agree before the old file goes read-only. After the switch, the kiln schedule is visible to the whole crew instead of one notebook. More on Access migration for sawmills and lumber yards.

Plenty of Access files started life as a spreadsheet, and parts of them still behave like one. Our post on when a spreadsheet quietly becomes a system covers the signs. The Access migration page covers what a migration includes, and the free audit is the first step either way.

Free audit

Let's get started

Tell us what's giving you trouble, in your own words. "Our Access database is dying" is plenty to go on.