Guide · Access replacement
Converting an Access database to a web application: what's involved
There's no button for it. Here's what actually happens, step by step.
People often hope there's a tool that takes an Access file in one end and puts a website out of the other. There isn't, and anyone who tells you otherwise is selling something.
The good news is that it isn't a mystery either. Every Access database is made of the same five kinds of thing, and each one has a clear path to the web. Knowing what they are helps you judge any quote you're given, including ours.
What converts, and what gets rebuilt
| Part of the Access database | What happens to it | How much work |
|---|---|---|
| Tables and data | Moved to a server database such as MySQL or SQL Server, with proper data types, keys and relationships. | Low to medium. Cleaning the data is usually the bigger job. |
| Queries | Rewritten as SQL in the new application. Simple ones translate almost directly. Ones that call Access functions or read values off open forms need rethinking. | Medium |
| Forms | Rebuilt as web pages. This is a chance to fix the screens people hate, not just copy them. | Medium to high |
| Reports | Rebuilt as on-screen reports, PDFs or spreadsheet exports. Often the biggest single chunk of work. | High, unless you prune the list first |
| VBA code and macros | Read, understood and rewritten as server code. This is where the hidden business rules live. | Varies wildly. Ten lines or ten thousand. |
Microsoft does have a free tool, SQL Server Migration Assistant for Access, that moves tables and data into SQL Server. It's useful, but it only does the first row of that table. Your forms, reports and code still run in Access afterwards. Our guide on Access to SQL Server migration explains when that's enough on its own.
How a conversion runs
1. Read the database properly
Every table, query, form, report, macro and module, listed and understood. On a recent project the front end alone had 184 forms, 126 reports and 515 saved queries. You can't estimate that from a demo. It has to be read.
This is also where you find the odd things. A query with a year typed into it. A report that relies on a number being truncated rather than rounded. Holidays recorded as fake bookings. Each of those is a business rule, and the new system needs to follow it (or deliberately fix it).
2. Talk to the people who use it
The database tells you what it does. Only the people tell you what they do around it: the spreadsheet on the side, the whiteboard, the report that gets printed and written on. Usually there's one power user who knows it inside out. Book their time early, especially if they might be moving on.
3. Write the specification
A plain-English list of what the new system must do, split into must-haves, should-haves and could-haves. Agree it before building. It also stops the project quietly turning into "everything Access did plus everything we ever wanted".
Now is the time to prune. Ask which reports were opened in the last year. On older databases a good share haven't been, and some no longer work at all. Every report you drop is money saved.
4. Build in short rounds
Working software every couple of weeks, starting with the part that matters most to the business. You click through it, say what's wrong, and it gets fixed in the next round. Far better than seeing everything for the first time at the end.
5. Move the data, then check it
Run the migration several times during the build, not once at the end. Each time, compare old and new: number of records in each table, totals on invoices and payments, and a sample of records checked line by line. When the numbers match on every run, you're ready.
6. Run both side by side
For a few weeks, the new system is live and Access is still there to check against. Staff are trained, the last niggles are fixed, and Access becomes read-only. Keep a copy of the old file somewhere safe. Somebody will want to look something up in it next year.
What you end up with
- It works anywhere. A browser on any computer, tablet or phone. No VPN, no remote desktop, no "only on the office PCs".
- It handles everyone at once. A server database is built for many people reading and writing at the same time.
- Proper logins. Each person has their own account and sees only what they should, with a record of who changed what.
- Backups that run themselves, off site, and tested.
- It can talk to other systems. Your accounts package, your website, a customer portal.
- Anyone competent can maintain it. We build on standard PHP and MySQL, so you're not tied to one person or one supplier.
Where conversions go wrong
- Copying screen for screen. The new system ends up with all the old system's awkwardness, in a browser. Copy what each screen is for, not how it looks.
- Copying the bugs. Hard-coded dates and broken reports should be fixed or dropped, not faithfully rebuilt.
- Leaving the data until last. Messy data always takes longer than anyone expects. Start early.
- Skipping parallel running. It's tempting when the deadline's close. It's also how people discover on day three that the VAT report is wrong.
- Moving the knowledge into one new head. If only the new developer understands the new system, you've rebuilt the original problem. Insist on written documentation.
As a rough guide, a typical departmental system takes two to four months. We use AI-assisted development to read the old database and speed up the routine parts of the rebuild, which keeps the cost down. More on the main replacing Access page.
Access to web app questions
Not in any useful way. Tables and data can be moved automatically. Forms, reports, queries and VBA code only run inside Access, so they have to be rebuilt for the web.
A small database can take four to eight weeks. A typical departmental system takes two to four months. A database that runs most of the business can take four to nine months, usually delivered in phases.
Microsoft retired Access web apps and Access Services in SharePoint Online, so there's no longer a Microsoft route for publishing an Access database to the web. A conversion now means rebuilding it as a proper web application.
We usually use MySQL, which is free, widely supported and runs on standard hosting. If you already use SQL Server elsewhere, the new system can use that instead.
Only where that helps. We keep the parts people are used to and like, and redesign the screens that are slow or confusing. The aim is that staff find it familiar on day one and quicker by day five.
Thinking of moving Access to the web?
Tell us about your database and we'll tell you what's involved.
What it does, how many people use it, and roughly how many forms and reports it has if you know. A copy of the front end helps, but isn't needed to start.
What we will cover:
- What converts easily and what needs rebuilding
- Which reports you could probably drop
- A rough cost and timescale
Rather talk now? Book a call or ring 01474 639 089.
We reply within one working day.
