Microsoft Access to web app in 2026: how to keep feature parity
TL;DR
A Microsoft Access to web app migration in 2026 rarely fails on the tables. It fails on features nobody wrote down: the form that blocks a bad date, the export someone emails every Friday. Microsoft's own migration assistant converts tables and most SELECT queries, while forms, reports, macros, VBA modules stay behind for you to rebuild.
- Access 2021 reaches end of support on October 13, 2026, and Office 2021 gets no extended security updates.
- One Access database tops out at 2 GB and 255 concurrent users.
- Copying everything is its own trap: Pendo measured 80% of features as rarely or never used.
- The fix is usage-verified parity. Every function is carried over, changed, retired with its owner's signature, or listed as new scope with a separate estimate.
Why MVP is the wrong word for a replacement
A minimum viable product is a bet on demand that does not exist yet. A replacement already has its demand: people who open the old tool every morning and expect yesterday's buttons. Give them a first release that drops what they use, and the scope reads as a downgrade with a budget attached.
We have made that mistake ourselves. A research client replacing an Access tool read our first scope and pointed out that many items on its out-of-scope tab were features their current application already had. They were right. The same buyer also wanted things the old tool never had, video calls and an API among them. That is the real shape of a replacement: old scope plus new scope, and an MVP label blurs the line between them.
The triggers are rarely dramatic. The Access application cannot absorb another feature. Or the people who understand it are leaving: one insurance administrator we spoke with was moving its business onto another core platform while losing key staff, and its team was typing the same data into two systems that were not integrated.
The Access support deadline is October 13, 2026
Microsoft's lifecycle list for 2026 retires Access 2021 and ends support for Access LTSC 2021 on October 13, 2026. For the Office 2021 family Microsoft is explicit: no security fixes, no software updates, no extended security updates.
The date does not force a rewrite. Upgrading Access buys time, and for a one-team tool that is often the right call. What the date forces is an inventory, because whichever way you go, somebody has to know what the application does. Treat October 13 as the day the parity map starts.
How we built this guide
Three rules, applied throughout.
- Platform behavior and limits come from Microsoft's documentation. Regulatory text comes from the eCFR, HHS guidance and the Federal Register.
- Engineering examples are projects we publish as case studies, linked so you can check them.
- Our own figures are shares rounded to five points, and any group with fewer than three data points is not published.
One disclosure. Mercury Development has built web applications since 2008 and sells the work this guide describes. The Access conversion guides we read, Apps4Rent's among them, cover the mechanical steps: move the data, recreate queries, rebuild forms and reports, rewrite the VBA. They stop before the question that decides the budget. Which of those features does anyone still use?
Feature parity at a glance
| Layer | Where it hides in Access | How you find it | How you prove it |
|---|---|---|---|
| Data rules | Field validation, default values, relationships | Read the schema | Row counts and control totals reconcile |
| Queries | Saved, parameter, cross-tab, action queries | Object inventory | Same inputs return the same rows |
| Screens | Forms plus the VBA behind their events | Watch each role work | The person who does the task signs it off |
| Outputs | Reports, Excel exports, mail merges | Collect last quarter's files | Old and new files compared line by line |
| Access control | Windows permissions on a shared folder | Ask who can open the file | Per-user log of every view and change |
| Schedules | Startup macros, scheduled jobs, linked tables | Check the machine that runs them | Both versions run, outputs compared |
The last two rows are where Access replacements surprise people. Nobody lists a permission model or a Friday job as a feature until it stops.
What an Access application really contains
Access is two products in one file: a database and an application builder. Microsoft's sharing guide describes the usual team setup, a split database, where only the data sits on the network share and each user runs a local copy of the front end holding the queries, forms, reports, macros, modules. The same guide recommends avoiding opening an Access database from OneDrive or a SharePoint library, because several copies may be created and unexpected behavior may follow. A synced folder is not a server.
The ceilings are documented in Access specifications: 2 GB per database, minus space for system objects, and 255 concurrent users.
The harder problem is that the business logic is scattered. A validation rule on a field. A default value in a table. A BeforeUpdate event in a form module. A calculated column in a saved query. A report that groups and subtotals in a fixed order. Each is a rule someone depends on, written in a different corner of the same file.
The feature parity trap and how to stay out of it
The authors of Feature Parity on Martin Fowler's site call it the feature parity trap. People greatly underestimate the effort, legacy systems bloat with features nobody uses, and in general they don't recommend the pattern. Thoughtworks put legacy migration feature parity on Hold in its November 2019 Radar, citing a 2014 Standish Group figure of 50% unused features. Pendo measured 80% of features in the average product as rarely or never used, across 615 subscriptions.
So copying everything is waste, and dropping what people use is a failed launch. The way out is evidence per function: who uses it, how often, what breaks downstream when it disappears.
Expect surprises. Hyrum's Law, named for Google engineer Hyrum Wright, puts it plainly: with enough users, every observable behavior of a system is depended on by somebody. In an Access tool that means the sort order of a report, the column layout of an export finance pastes into its own workbook, the field that quietly fills in today's date. None of those sit on a requirements list. All of them are features.
Build the feature parity map in five passes
The map is a spreadsheet with one row per function, built from five directions, because each one catches what the others miss.
- The file. List every table, query, form, report, macro, module. Access's Database Documenter prints most of it.
- The outputs. Collect every report and export the tool produced last quarter, printouts included, and ask who receives each one.
- The people. Sit with each role through a real working session. Do this first if anyone who knows the tool is leaving.
- The usage. If the application keeps no usage log, add one to form and report open events for a few weeks before deciding anything.
- The disposition. Every row gets one label: carry over, carry over changed, retire, or new.
Two rules make the map hold. Retire needs the signature of the person who owns that outcome. New goes on a separate list with its own estimate, because new scope priced inside parity is how a replacement budget grows without anyone deciding it should.
A bid that skips this map tends to look short, which is the pattern we cover in our guide to the software development timeline estimate.
Read the old code before you price the new one
An estimate written from a feature list prices the features someone remembered. An analysis phase prices the system you actually have. For the research client above, that is what we recommended: a formal review of the current code to establish what could be salvaged before anyone committed to a rebuild budget.
What usually survives is the data layer. Microsoft's migration assistant converts Access tables to SQL Server tables and most SELECT queries to views. UPDATE queries are not migrated, and SELECT queries that take parameters are not converted, nor are cross-tab queries. Forms, reports, macros, modules: not converted at all.
VBA will not run on a web stack, but it is the best specification you will get, because the business rules are already written down. On EyeIC, moving a 510(k) cleared medical imaging application from Windows desktop to the web, we reused key code from the desktop version to reduce cost, kept backward compatibility with files from the older version, and finished the migration in three months.
HIPAA turns a shared file into an architecture
There is no HIPAA certificate for software. The Security Rule's technical safeguards ask for mechanisms: a separate name or number that identifies and tracks each user, controls that record and examine activity, procedures that verify a person seeking access is who they claim to be, protection for data in transit. Automatic logoff and encryption are listed as addressable. Folder permissions answer part of that. A per-record history of who viewed and changed a participant's data is much harder to produce from one file on a share.
The cloud adds a contract. HHS guidance says a cloud service provider handling ePHI for you is a business associate, that lacking an encryption key does not exempt it, and that a business associate agreement is required.
The bar is also moving. The January 2025 proposed rule would expressly require encryption of ePHI, with limited exceptions, plus an inventory of technology assets and a map of how ePHI moves through them. The 2026 Unified Agenda projects final action for July 2027, after an earlier target of May 2026, McDermott reported in July 2026. A system built now should meet the proposal, because retrofitting encryption into a live data layer costs more than designing it in.
Research platforms can carry one more rule. If the records support an FDA-regulated clinical investigation, 21 CFR 11.10 calls for secure, computer-generated, time-stamped audit trails, and record changes shall not obscure previously recorded information.
The full sequence, from the PHI boundary to the BAAs, is in our guide to HIPAA compliant app development.
When the rebuild becomes a licensed product
Some internal tools come with a second ambition: sell them to other organizations. The client above wanted self-serve plans in the style of survey and email marketing software, with license start dates, expiry dates and renewal reminders for each customer.
That is new architecture, and parity does not cover it. Microsoft's multitenancy guidance draws the line: tenants are distinct from users, and multiple users from one organization form a single tenant. An Access schema was designed for one organization, so either every table gains a tenant key or every tenant gets its own database, and that choice comes before the first table moves. Plans, entitlements, onboarding, a tenant administrator and a super administrator who sees across tenants all follow from it.
All of it belongs in the New column of the map, with its own estimate.
If an outside team writes the new product, settle who owns the code when outsourcing before the first commit.
Prove parity before you switch Access off
Parity is a test result. Three checks do most of the work.
- Recorded outputs. Run last quarter's reports and exports from Access, keep the files, regenerate them from the new system on the same data, compare line by line.
- Parallel paths. GitHub's Scientist library runs the old and new code paths side by side, logs mismatches and returns the old result to the caller. The same idea works at report level for an Access replacement.
- Reconciled data. Row counts and control totals per table on every migration run, until they match.
Whether you cut over slice by slice or all at once is a separate decision. We compared both in big bang rewrite vs incremental replacement.
Which path fits your Access application
If the tool serves one team at one site, holds no protected data and sits well inside its limits, upgrade Access and move the tables to SQL Server or Azure SQL, which Microsoft lists as a way to share a desktop database. It is the cheapest honest option.
If staff work from several sites, the data includes protected health information, or an auditor asks who changed what, rebuild as a web application and start with the parity map.
If other organizations will pay to use it, build a multitenant web product and keep parity and licensing as separate lines in the estimate.
If the people who understand the tool are leaving, run the people pass this week. Knowledge leaves faster than code.
What our records and case studies show
Across the buyer conversations in our requirement records, around 15% describe a legacy foundation that no longer supports growth, and a similar share still run critical work through spreadsheets and disconnected tools. Replacement is a routine request.
Our published work shows it from the other side. Around half of the case studies we publish began with software the client already ran. The full replacements among them say what was carried across.
- Hit It Great: a new iOS and Android app replaced the old one, all features from the old app were preserved, and new ones were added on top.
- EyeIC: the web version kept backward compatibility with files from the older desktop version and added HIPAA-compliant online access.
- Precision Practice Management: the claims workflow system was built 100% compatible with the pre-existing rejection code process, which had run on weekly CSV reports filtered by hand with simple macros. We documented that process with subject matter experts before the specification. The system has been in production since 2006 and is on its fourth major release.
The hardest variant has no code to read. Element Labs had configuration software supplied by a hardware manufacturer without source code, so no new features or devices could be added. We redeveloped it as a cross-platform version 3, and Barco kept the relationship after buying Element Labs in 2010.
The MVP of a replacement is the old system
Opinion, stated plainly. Nobody should fund a first release that does less than what staff already have, and nobody should fund a copy of features no one uses. Both mistakes come from the same gap: scope written without evidence.
So we treat the parity map as a contract. Every row has an owner, a disposition and a test. Retire needs a signature, new needs its own estimate. Once both sides have signed the map, the argument about MVP versus everything is over, because there is a list both sides can check.
Two limits. A parity map does not make a migration cheap; it makes the cost visible before it is spent. And if the Access tool is small, stable, well inside its limits, the honest advice is to leave it alone.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The requirement reviews and case analyses behind this guide, where each replacement is read for what the old system did and what had to keep working, come from the engineering practice he works in.
Replacing an Access application? Start with a parity map both sides sign
Send us a description of what the tool does, who uses it and what it produces, or a copy of the front end with no patient data in it. We come back with a draft parity map: what carries over, what changes, what we would retire with your sign-off, and what is new scope with its own estimate.