An Access application that worked well for years eventually grinds to a halt: nobody dares touch it anymore, only one colleague understands the macros, it doesn't work on mobile, and the GDPR position is weak. We migrate your .mdb or .accdb to a scalable web application with multi-user access, an audit trail and a proper back end.
For decades, Microsoft Access has been the pragmatic answer for SMEs, accountancy firms, local government, small care practices, laboratory environments and production tracking. Someone with domain knowledge could build a working application without a developer, with tables, forms, queries, reports and a few macros, all in one file. In many organisations that Access application is still running, because it simply "works".
The problem is that "simply works" is deceptive. A .mdb or .accdb sits on a network drive, sometimes via a file share dating back to the Windows Server 2008 era. With one user it's fine; with two you get record-locking issues; with five you get a corrupt file that has to be backed up in the evening and restored in the morning. No mobile app, no audit trail, no role management beyond a password-on-file, and logic buried in VBA macros that exactly one person can still decipher.
Replacing an Access database is rarely a purely technical exercise. It is usually a combination of risk management (GDPR, audits, single points of knowledge), scalability (more users, mobile access) and further development (your working process has outgrown what Access can handle). Our approach fits within our broader practice in web development and is closely linked to the wider context of platform migration. An Access replacement is, at its core, a platform migration with Access-specific pitfalls.
Not every Access database calls for the same approach. Sometimes the existing logic is so specific to your business that custom development is the only sensible route. Sometimes the working process has become generic enough that a low-code platform will do. Often it is a hybrid: the core custom-built, the edges low-code.
For relatively generic administrative applications, such as a membership register, a small customer database, stock tracking or a simple form-based workflow, we rebuild your Access database on Microsoft PowerApps, AppSheet or a comparable low-code environment. The data moves to Dataverse, SQL Server or Google Cloud SQL, the Access forms are rebuilt in the low-code editor, and reports go to Power BI or Looker Studio. This is the right choice when your organisation needs to be able to adjust the solution itself without a developer.
For Access databases where your business logic lives (specific calculations, your own workflow, integrations with other systems), we build a custom web application. Data moves to Postgres, MySQL or SQL Server; forms are rebuilt in React, Vue or Astro as a single page application; queries are available as REST or GraphQL APIs; macros are translated into clear backend logic. Includes multi-user access, an audit trail and role-based permissions.
For situations where several Access files exist side by side, often having grown over years with overlapping data and logic, we first consolidate the data layer (see also our page on data engineering platforms) and then build a digital platform on top that takes over and extends the Access functionality. This suits organisations that want to use the migration to get their reporting and BI in order straight away.
No more .accdb files on a network drive, no VBA macros that only Jan understands, and no pop-up saying "this file is being used by someone else". Instead, an environment that you can manage yourself or have managed for you, with your data and logic entirely in your own hands.
Five patterns in which organisations approach us to replace their Access environment. If you recognise one of them, a conversation is usually worthwhile, even if we ultimately conclude that a light upgrade will suffice rather than a full replacement.
The Access application is meant to be multi-user, but in practice the second user gets blocked. Records become locked, the file occasionally corrupts, and the ICT team restores backups before the day can begin. Once the team grows, this doesn't hold up.
Your staff in the field, on site or on a production floor have no access to the Access environment. They note everything on paper or in Excel and type it up in the evening. A web environment solves this at once: tablet, phone, laptop, all showing the same screen.
Your Access database contains personal data (customers, patients, employees, members) and sits as an .accdb file on a network drive with unclear access. Who has copies? Who changed what? In the event of a data breach or an investigation by the Dutch Data Protection Authority, you are poorly placed. GDPR requires demonstrable access control and logging.
If you work in healthcare, NEN 7510 requires demonstrable logging of who viewed and changed what. In accountancy and financial services, the Wkkgz (Wet keuring kwaliteit gezondheidszorg is not applicable here; rather the Wet op het financieel toezicht and Wta) carries comparable requirements. Access doesn't provide this; a modern web app does as standard, with an immutable audit log for every record mutation.
The Access application was built up over the years by one colleague: VBA macros, complex queries, many form events. If that colleague retires, resigns or falls seriously ill, nobody knows how the system works. This is an operational risk that only becomes apparent when it is already too late.
You want to connect a customer portal, add a mobile scanner flow, integrate with your accounting or support multiple branches. Access can technically still do some of this, but every extension becomes a workaround, and nobody can guarantee the existing flows will keep working. Over the years the setup has become too heavy for the platform.
A first conversation in which we understand what the Access database does within your work process, how many users there are, what the pain points are and what you would like. We then carry out a short technical scan of the file itself: number of tables, relationships, forms, queries, reports and VBA macros. At the end you receive an initial outline of the migration scope and an idea of the right target platform.
A workshop with your team plus interviews with a few daily users: what do you currently do in Access, what would you actually like, and which flows are business-critical? At the same time we carry out a thorough analysis of the Access file: reading out macros, working through queries, mapping data relationships. At the end: scope, planning, screen flows, and the target platform for each component.
We export the data from your .mdb or .accdb into Postgres, MySQL or SQL Server. Foreign keys that Access left implicit are made explicit, column types are harmonised, and data quality is checked with a report of discrepancies. For running in parallel, we set up a synchronisation script so your team can keep working in Access while the new environment is being built.
A working build every two weeks. We start with the most used flow, usually one main form with its associated lookup queries, and in later sprints expand to the other forms, reports, the audit trail and the API integrations. Your key users test along the way. The macros are not translated one-to-one but reviewed and turned into clear backend logic with tests.
A pilot group works in the old Access and the new environment in parallel for two weeks. Differences are identified and resolved, and screens are refined based on feedback. This is followed by training sessions for key users, short videos for end users, and go-live with a clear rollback procedure as a fallback. Access remains available on a temporary read-only basis for historical reference.
An optional management contract covering monitoring, backups, security patches and further development of requests that fell outside the scope during discovery. The environment grows along with your way of working.
Replacing an Access database breaks down into six tracks. First, the data export: tables from the Access file are transferred to the target database (Postgres, MySQL or SQL Server, depending on what your IT environment already runs). Access-specific column types (AutoNumber, Yes/No, OLE Object, Hyperlink, Memo) are mapped to serial, boolean, bytea and text. Foreign keys that existed implicitly in Access (via lookups in forms) are recorded explicitly in the schema with the corresponding constraints.
Next, the forms. Access forms are often a mix of input fields, lookup combo boxes, subforms and VBA events. We rebuild them as a web UI in React, Vue or Astro, with the same fields and validation rules but in a design that works across multiple screen sizes. Subforms become tabs or accordions, lookup combo boxes become search fields with autocomplete, and validation happens in the browser as well as again on the server side.
The reports move to a BI environment: Power BI if you are Microsoft-oriented, Metabase for self-hosted setups, or Looker Studio for Google environments. The advantage: reports are now live, shareable via link and interactively filterable rather than compiled at a fixed point in time. The monthly report that used to take an hour of Excel work becomes a dashboard that is always up to date.
The macros are the delicate part. VBA code can range from trivial ("clear this field when a new record is created") to complex ("generate an invoice PDF using several queries and email it to the customer"). We document every macro, decide with you which ones are still relevant to the new way of working, and rebuild those as backend logic in TypeScript or Python with tests, so that a later change does not quietly break a calculation. The rest we deliberately drop.
The queries, especially the saved queries used in forms and reports, become API endpoints. A REST or GraphQL API returns the data that used to sit in a query result. That immediately opens the door to integrations with other systems: your accounting, CRM or a mobile scanner app. Or another team can build its own customer portal on that API without ever touching the database directly.
Finally, the cut-over. Nobody likes to switch over all at once without a safety net. We work in parallel: Access remains as a reference, and a synchronisation layer mirrors changes between old and new. At go-live, the write direction switches; Access remains available for historical reference.
Microsoft Access is still going strong in six types of organisations we increasingly see as clients. SME administration: small businesses with their own customer or order database, often built by a single employee with a knack for IT. It works well for the first hundred customers but starts to struggle at the thousandth.
Small healthcare practices: dental practices, physiotherapists, small mental health clinics. Patient records, appointments and treatment history kept in an Access file, a setup that now clashes with NEN 7510 and GDPR. Replacement is often no longer optional here; auditors ask for demonstrable access control and an audit trail.
Accountancy and bookkeeping firms: small practices with their own Access database for hours, clients, files and invoice status, alongside their accounting package. The Wta requirements around file documentation and audit trails have become stricter, and Access generally does not meet them without a lot of manual work.
Local government and public services: municipal departments, water boards and small implementing bodies, often with a register, permits database or internal enforcement tool in Access. This is where GDPR, Freedom of Information requests and inter-governmental information sharing come together.
Research, labs and R&D: university research groups, clinical labs and smaller R&D departments tracking experiments, samples and measurements in Access. These often start with a PhD candidate; two years later the organisation is left with a knowledge gap. A web app with an API has the added advantage here that data can flow directly into a data pipeline.
Production tracking and small-scale manufacturing: SMEs in manufacturing that keep their work orders, stock and quality checks in Access. The main pain points are mobile access (shop-floor operators have no access) and integration (accounting, ERP and Access are not in sync). Replacement often goes hand in hand with a first integration layer towards integrations with other systems.
The target platform depends on two questions: how specific is your business logic, and how much self-service adaptability does your organisation want to keep? For generic administrative flows, a low-code route such as PowerApps with Dataverse or AppSheet with Google Workspace makes sense. Your own staff can make small changes later without a developer. The downside: the ecosystem sets the rules, and vendor lock-in is a real risk.
For applications where your own logic lives, we opt for custom development. Postgres is our default database: open source, robust and widely supported. SQL Server if your IT team already works with it, MySQL in shared-hosting scenarios. Front end in React, Vue or Astro; back end on Node.js, Python (Django or FastAPI) or .NET, depending on what your current or future maintenance partner knows.
For the migration itself, we use ODBC connections to the Access file, a Python script with pandas or a tool such as mdbtools to extract the data, and dbt or custom SQL scripts for the transformations to the new schema. For BI: Power BI (Microsoft-oriented), Metabase (self-hosted) or Looker Studio (Google). Authentication via SSO on Azure AD, Okta or Google Workspace; magic links or MFA for external users. And always an immutable audit log, which is the feature difference that is worth the most.
What clients usually want to know before we start.
A no-obligation introductory call of half an hour. We listen to your current Access workflow and the needs behind it, ask targeted questions, and give you direction you can act on, even if we ultimately conclude that a light upgrade will do instead of a full replacement.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
