Data
- Tables, keys and relationships
- Linked tables and their sources
- Data quality issues to fix in the move
MS Access to Web App
MS Access to web app migration: your data, forms and reports in the browser
The Access database that runs orders, jobs or records lives on a shared drive, slows down as more people open it and only works on Windows desktops with Access installed. Agnotic Technologies moves it to a web app: your data in SQL Server or Azure SQL, your forms and reports rebuilt as browser screens, and your VBA rules rewritten as tested code.
Data keptForms as web screensReports in the browserSQL Server or Azure SQL
Trusted by global innovators
How do we replace our Microsoft Access database with a web app?
Replace a Microsoft Access database with a web app in three moves: put the tables in a server database such as SQL Server or Azure SQL, rebuild the forms and reports as browser screens, and rewrite the queries, macros and VBA that hold business rules as tested server code. Agnotic Technologies starts by inventorying every table, query, form, report, macro and module, and asking who uses each one. We migrate and clean the data, build the web app with logins and roles, and run it beside the Access file until both give the same results. Then the team switches, and Access becomes read-only.
Data, forms and reports
Can we keep our data and move our Access forms and reports to the browser?
Yes. Your data moves with its history into a server database, and each form and report is rebuilt as a web screen that does the same job, often with fewer clicks. Agnotic Technologies maps every Access object to its web equivalent before building, so nothing your team relies on is dropped.
The screens will not look identical to Access, and that is usually a gain: forms that grew tab by tab can be split by role, and reports can be filtered, exported to Excel or saved as PDF from any browser.
Migration path
Should we move the Access back end to SQL Server first?
Often, yes. Moving the tables to SQL Server first, while users keep their Access forms, removes the shared-file limits quickly and lets the web app be built against the final database. Skip that step when the front end is the bigger problem or the data model needs redesigning anyway. These are the three paths we compare with you.
| Path | When it fits | What changes for users |
|---|---|---|
| Back end to SQL Server, keep the Access front end | Data size or many users are the main pain, and the forms still work | Nothing visible at first; the Access forms read from SQL Server |
| Back end first, then a web front end | You want the web app, but need relief now and a gradual switch | Access forms keep working while web screens replace them one area at a time |
| Straight to a web app with a redesigned database | The data model is the problem, or nobody can maintain the VBA | One switch to the web app after a parallel run |
Microsoft's SQL Server Migration Assistant for Access can move tables and data in the first two paths. The forms, reports and VBA still need to be rebuilt for the web.
Inventory
What do we inventory in an Access database?
Every object, who uses it and what depends on it, before a line of new code is written.
Logic
- Queries, including action queries
- Macros
- VBA modules and form code
Screens
- Forms and subforms
- Switchboards and navigation
- Who uses each form
Outputs
- Reports and their filters
- Exports to Excel and other systems
- Scheduled or manual jobs
The move
How does the move from Access happen?
The order we follow so the business keeps working throughout.
Inventory
Every table, query, form, report, macro and VBA module listed with its users.
Database
Tables designed in SQL Server or Azure SQL, with the data migrated and cleaned.
Rules
Queries and VBA that hold business rules rewritten as tested code.
Screens
Forms and reports rebuilt in the browser, with logins and roles.
Parallel run
The web app runs beside Access until results match.
Switch
Users move to the web app, and the Access file is kept read-only.
For users
What changes for the people who use it
The everyday differences after the move to the browser.
- Works in any modern browser, on Windows, Mac or a tablet
- No more locked or corrupted shared file
- Each person signs in and sees the screens for their role
- Every change is recorded with who made it and when
- Reports filter, export to Excel and save as PDF
- Remote staff use it without a VPN to the file share
Failure points
Where do Access migrations go wrong?
What we plan for from the start.
Challenge
VBA hides rules nobody documented.
Agnotic approach
Each module is read and its rules listed before rebuilding.
Challenge
Action queries change data in ways users forget.
Agnotic approach
Every action query is traced and replaced with a tested job.
Challenge
Data has duplicates and broken links.
Agnotic approach
Cleaning rules agreed with you and applied during the move.
Challenge
Users miss a report on the first day.
Agnotic approach
Every report on the inventory is checked off before switching.
Challenge
Linked spreadsheets feed the database.
Agnotic approach
Imports replaced by integrations, or a controlled upload screen.
Related services
Where does an Access migration connect?
Access databases often sit beside spreadsheets and older systems that move too.
Replace Excel with custom software
Workbooks that feed or sit beside the Access database, moved to the same web app.
Application modernization services
Wider modernization when Access is one of several older applications.
What is legacy system modernization?
The approaches to moving off older systems, explained.
Database development services
Database design and tuning for the new SQL Server or Azure SQL back end.
Facts and sources
What does Microsoft document about Access limits and migration?
Microsoft's own Access specifications and migration tool documentation, each linked to its source.
Microsoft's Access specifications list the maximum total size of an Access database (.accdb or .mdb), including all database objects and data, as 2 gigabytes minus the space needed for system objects.
Source: Microsoft Support, Access specificationsThe same Microsoft Access specifications list 255 as the maximum number of concurrent users of an Access database.
Source: Microsoft Support, Access specificationsMicrosoft describes SQL Server Migration Assistant (SSMA) for Access as a tool for migrating databases from Microsoft Access to SQL Server and Azure SQL, with supported targets including SQL Server 2019 and later, Azure SQL Database and Azure SQL Managed Instance.
Source: Microsoft Learn, SQL Server Migration Assistant for Access
Standards
Platforms and standards for the new web app
SQL Server and Azure SQLSSMA for AccessOWASP ASVSWCAG 2.2OpenID Connect
Where it starts
Access databases we often move
Business databases that outgrew a shared file.
Order and job tracking
Orders, jobs and work tickets with status and history.
Inventory and assets
Stock, equipment and tool registers.
Quality and inspection records
Inspection results, nonconformances and certificates.
Customer and contact records
Customer lists, contracts and service history.
Scope
What decides the size of an Access migration?
We do not publish prices. These are the drivers we size once we have seen the database.
Objects
How many tables, queries, forms, reports and modules.
VBA
How much business logic lives in code.
Data
Volume, history to keep and cleaning needed.
Path
Back end first, or straight to the web app.
Integrations
Linked tables, imports and exports to other systems.
Users and roles
Who uses it and what each role may see or change.
Engagement
How does an Access migration project run?
We start with a copy of the database.
1.
Scoping call and inventory
You share a copy of the database; we list its objects and users and recommend a path.
Scope2.
First release
A fixed-scope first release: the database migrated and the most used forms and reports in the browser, run beside Access.
Build3.
Switch and extend
Remaining screens, reports and integrations, then the switch, with support after launch.
ScaleFrequently Asked Questions
Yes. Users keep working in Access, and if the back end moves to SQL Server first, Access and the new web screens share the same live data during the transition.
We read it, list the rules it enforces and rewrite those rules as tested server code. Code that only formats or moves data on screen usually disappears in the web app.
Yes. Lists and reports can be exported to Excel or saved as PDF, and bulk data can be imported from a sheet through a controlled upload.
SQL Server and Azure SQL are the usual choices because Microsoft's migration assistant targets them and many teams already license them. PostgreSQL or MySQL also work when they fit your hosting better.
We do not publish prices. The number of objects, the amount of VBA, data volume, the path, integrations and roles decide the size, and we agree a fixed first release after the inventory.