Access 2021 end of support: what the deadline forces you to decide
Your team depends on an Access 2021 database, and Access 2021 leaves support in October 2026. The choice in front of you is between staying on a supported Access build and replacing the database with a different system. That decision has to be made now, because moving tables, forms, queries and VBA logic usually takes longer than buying a license. Access 2019 is already out of support, so any database still running on it has no vendor fix path. Treat that as an exposure to close now, not a later housekeeping item, and list every machine and file that still opens an Access 2019 copy.
Start with an inventory of what the database actually does. Record who opens the .accdb file, whether it sits on a shared network drive, which tables are linked to other sources, how many VBA modules and macros it contains, and which reports are sent outside the team. Then check which Access build each user runs and confirm with Microsoft which supported builds your current licenses cover and when each one ends. Those answers determine whether an upgrade is a license purchase with a short rollout or a project with data migration, testing and retraining attached.
In short, upgrading keeps the database in Access and keeps its existing logic in place. Replacing it moves the data into a self-hosted system such as Baserow, or into PostgreSQL with Mathesar for spreadsheet-style editing. Which path fits depends on your own database, including its size, the number of concurrent users and how much logic lives in VBA. Ask your vendor and your own technical staff to confirm those details before you commit to either route, and set the decision date early enough that a migration could finish before the deadline.
What a supported database needs from your organization
The October 2026 retirement of Access 2021 forces a decision about every layer the database depends on. Each card below is a requirement your environment must meet, whether you upgrade Access or move the data to a new platform.
A supported Office build
Access only receives security updates while its Office build is supported, so the first decision is which build your users will run. Access 2021 retires in October 2026, and Access 2019 support has already ended. Confirm the support lifecycle for Access in Microsoft 365 and for LTSC 2024 directly with Microsoft, and map each machine that opens the database to its build and update channel.
A database platform that still gets patches
Moving to Baserow or PostgreSQL shifts patching to your team or your implementation partner, so someone must own every component in the stack. For Baserow, that includes the Docker image or Helm deployment and its PostgreSQL and Redis services. For Mathesar, it includes the application and the PostgreSQL version it supports. Write down who applies each update and how often you review it.
A data location you control
An Access file on a network share sits wherever that share is hosted, but a cloud spreadsheet database often stores metadata and authentication data elsewhere. Both Baserow and Mathesar can run on servers you choose, so decide which region, data center or on-premises network will hold the records and attachments. Ask any vendor you evaluate where each data type is stored, not only where the main records live.
Access rules that match your staff
Access files usually rely on shared-folder permissions and user-level habits rather than defined roles. A supported platform needs roles that map to job functions, such as editors, reviewers and read-only users. Mathesar uses PostgreSQL roles and privileges, while Baserow provides role-based permissions and single sign-on on paid plans. Export your current access list before you design the new roles, and confirm which identity provider will supply users.
An export path that does not depend on the file
Keeping the data usable after the migration means exporting it in a form that a new platform can read without the Access application. Access exports one object at a time, and attachments, OLE objects and multivalued fields need separate handling. Test the export on a copy of the database, check record counts and relationships against the source, and keep the original file read-only until users sign off on the new system.
Upgrade to Access 365 or LTSC 2024, or replace with Baserow or Mathesar
This table compares three paths for an Access 2021 database: staying in Access through Microsoft 365 or LTSC 2024, moving to self-hosted Baserow, or moving to PostgreSQL with Mathesar. Read each row against your own deadline, data location and access model. The main takeaway is that the upgrade keeps your current design intact, while the replacements change where data lives and how users reach it.
| Option | Meets the deadline by | What stays on your servers | Trade-offs | What to confirm |
|---|---|---|---|---|
| Access in Microsoft 365 or LTSC 2024 | Moving to a supported Access release before Access 2021 retires in October 2026 | The Access file and VBA code, still on a file share or local disk | Keeps the desktop and shared-file model, with its size and multi-user limits | Licensing route for your users, and whether the file share and VBA dependencies still work |
| Self-hosted Baserow | Replacing the Access database with a web application before the deadline | Tables, records and attachments on your PostgreSQL and application servers | MIT-licensed core, but SSO needs the Advanced or Enterprise plan with an activated license | Which features need a paid license type, and how VBA logic maps to automations |
| PostgreSQL with Mathesar | Moving tables into PostgreSQL and editing through Mathesar's spreadsheet-like interface | Data, schemas and access roles on your own PostgreSQL server | Open source under GPLv3, but in public beta; version 0.12.0 was tagged July 2, 2026 | Beta readiness for production, PostgreSQL version support, and forms or reports you still need |
A timeline that works backward from October 2026
The sequence turns the October 2026 end of support for Access 2021 into a set of ordered checkpoints, so each database is either upgraded or replaced before the date with tested data and a rollback path. Durations are not set here because they depend on your own inventory.
Inventory every database and its users
Start by listing each Access file, its owner, the tables, forms, reports, queries and VBA modules it contains, the number of attachments, and the people or processes that open it. Include files on network shares and any that link to other Access files or external sources. Your IT team and the business owners should both sign off on the list. The step is done when every file has a named owner, a user count and a note on whether it is used daily, monthly or rarely.
Decide upgrade or replace for each database
For each file, record whether it can stay in Access in Microsoft 365 or Access LTSC 2024, or whether it should move to Baserow or PostgreSQL with Mathesar. Files that are mostly single-user and form-based may suit an upgrade. Files with heavy VBA, growing record counts, or many concurrent users usually need a server-based database. Hold the decisions in a register that names the reason for each choice. The step is done when each database has one recorded path and an accountable owner.
Confirm the target environment and access model
For databases moving to self-hosted platforms, confirm where the server will run, how users will sign in, and which PostgreSQL roles or Baserow permissions map to today's Access security. Ask your team to check how single sign-on is licensed on the platform you choose, since Baserow lists SSO on its paid plans. Document backup, hosting and patching responsibilities before any data moves. The step is done when the target has a signed-off design and an owner for operations.
Run a test migration on a copy
Work on a copy of each source file, never the original. Export tables one at a time, then load them through the import path that fits the target: Baserow's Airtable-style importer applies to Airtable sources, while CSV import is the route for Access exports into Baserow or Mathesar. Compare row counts, field types, relationships and attachments against the source, and record every field that did not carry over, such as lookups or VBA logic. The step is done when a test copy opens, the counts match, and the gaps list is agreed with the business owner.
Rebuild the business logic and test it
Recreate forms, reports, queries and automations on the target platform, and replace macros or VBA with the closest supported equivalent. Have representative users run their normal tasks against the test copy and log any differences in results or permissions. Keep a short list of logic that cannot be ported and decide how it will be handled. The step is done when the business owner accepts the test results in writing.
Cut over with a parallel-run window
Choose a cutover date that falls well before October 2026, and keep the Access file in read-only mode for a defined parallel-run period while users work in the new system. Agree in advance which system is the record of truth during that window and how any late changes will be reconciled. Reconcile counts and spot-check records each day of the window. The step is done when the parallel period closes with no unreconciled differences and users have confirmed the new system.
Retire the old file and keep an archive
Once the cutover is accepted, make a final archived copy of each Access file and store it under your retention policy, then remove shortcuts and access to the working file. Update the register so every database shows its final location and owner. Confirm that backups of the new platform are running and have been restored at least once. The step is done when the archive is verified, the old file is no longer in use, and the register is closed.
What moves cleanly and what needs rebuilding
Records move; the application logic does not. Table data, attachments, field types, relationships and grid views are the parts that carry over. VBA modules, Access forms and reports, macros and the navigation pane do not come across automatically in any of the options considered here, so they must be counted as rebuild work before a date is set. Baserow's documented importer copies tables, records, attachments, field types, relationships and grid views with filters and sorts from a public share link, one base at a time. It does not copy formula, lookup, rollup or collaborator fields, automations, interfaces, comments or revision history. If your Access tables depend on calculated fields or lookups, plan to recreate those fields in the target and check the results row by row.
Mathesar takes a different path. It connects to a PostgreSQL database, so the tables become real PostgreSQL tables and the data stays in the schema you define. Mathesar imports CSV files with comma, tab, semicolon, colon or pipe delimiters, and it adds a form builder, a Data Explorer for queries and a file data type. Access queries, validation rules and VBA logic will need to be rewritten as PostgreSQL views, constraints or application code, and access rules move to PostgreSQL roles and privileges. Confirm with the Mathesar documentation which field types map to the PostgreSQL types you plan to use before you rely on the import.
Plan the export object by object and test on a copy. Access does not export a whole database in one step, so tables, queries, forms, reports and macros each need their own decision: move, rebuild or retire. Attachments and OLE objects are a common gap, and multivalued and lookup fields often arrive as flat values or IDs. Take a copy of the database, run the export and import against a test instance, and compare record counts, attachment counts and sample rows for each table. Do this for every object before the cutover date, and keep the original file read-only until the team has signed off on the results.
Which path fits which Access database
Trigger: one person opens a single .accdb file on a workstation, nobody else edits it, and the concern is that the installed version stops receiving support.
Path: move to Access in Microsoft 365 or Access LTSC 2024 as a bridge. The existing file, forms and VBA usually carry over, so this buys time without a data migration. Treat it as a holding step, because the database still lives on one machine and depends on one person's backups.
- Keep the file and code: forms, reports and VBA stay in the same .accdb, so the change is a software upgrade rather than a rebuild.
- Check the license model: Microsoft 365 is a subscription that recurs, while LTSC 2024 is a perpetual build. Confirm which one your organization is entitled to buy.
- Review 32-bit and 64-bit declarations: VBA declarations that call Windows APIs often need review when the bit version changes.
- Set a retirement date: write down when the migration will happen so the bridge does not become permanent.
- Inventory add-ins: confirm that any ActiveX controls or third-party add-ins in the file are still supported on the new build.
Confirm with your IT team which build your license covers and whether the file depends on components that Microsoft has not kept current.
Trigger: several people open the same .accdb over a network drive, and the file locks, corrupts or slows as more users join.
Path: move the data to self-hosted Baserow so people work in a browser against one server, with access set per table and per user. Baserow's non-premium features are under the MIT License, but single sign-on and the controls a team usually needs sit in the paid tiers, so the license choice matters as much as the software.
- Browser access: users log in from a browser, so the network drive and local copies of the file go away.
- SSO needs a paid plan: SAML and OpenID Connect single sign-on require the Advanced or Enterprise plan with an activated license.
- Match the license type to your headcount: Premium assigns seats to named users, while Advanced grants paid access to users on the instance. One instance can use only one license type.
- Plan the export: attachments stored in Access OLE fields and multivalued fields need a separate step before import.
- Pilot one table: move a single busy table first to test permissions and the change in daily habits.
Confirm which license type fits your user count and whether role-based permissions and audit logs are included in the license type you choose.
Trigger: the database holds heavy VBA logic, many queries and several reports, and the data model has outgrown a spreadsheet-style interface.
Path: move the tables into PostgreSQL and use Mathesar as the browsing and editing layer. Mathesar is open source under the GPLv3 license, is maintained by a 501(c)(3) nonprofit and can be self-hosted, so data stays on your servers. Its project describes itself as in public beta, and version 0.12.0 was tagged on July 2, 2026, so validate it in a test environment first.
- Keep the data model: Mathesar connects to existing schemas and tables, so keys and constraints carry over from the Access design.
- Permissions follow PostgreSQL roles: access uses roles and privileges you already manage, which suits teams with database administration skills.
- Queries and reports: Mathesar's Data Explorer covers everyday queries, but complex reports may still need SQL views or a separate reporting tool.
- Version support: check the PostgreSQL versions listed for your Mathesar release before choosing the database server.
- Ownership after go-live: decide who changes schemas and maintains views once the system is live.
Confirm your Mathesar release, the supported PostgreSQL versions and which report outputs must be reproduced exactly before committing to this path.
Trigger: most daily use of the database is data entry through forms, approval steps or simple screens, with lighter reporting than the calculation-heavy case.
Path: build the app on Baserow with its application builder, or keep the data in PostgreSQL and use Mathesar's form builder. Baserow describes itself as a spreadsheet database that also builds applications and portals, runs automations and offers dashboards. The choice depends on whether the team wants a browser-first database or a SQL-first one.
- Baserow applications: the application builder can cover data entry screens and portals for people outside the core team.
- Mathesar forms: the form builder suits teams whose data already lives in PostgreSQL.
- Automations replace macros: Access macros map to automations, but the Airtable importer does not carry automations across, so confirm what logic must be rebuilt.
- Rebuild each screen: Access forms with embedded VBA rarely transfer unchanged, so plan a rebuild and a test for every screen.
- Check conditional logic: list the screens that depend on calculated fields or branching before you pick a platform.
Confirm which screens depend on conditional logic and whether the application builder or Mathesar's form builder covers them before you choose.
How to deploy Baserow or PostgreSQL with Mathesar on your own servers
This sequence takes the platform from host selection to a tested, backed-up, TLS-protected instance inside your network, with a rollback path if the migration stalls. Follow it for either Baserow or PostgreSQL with Mathesar, and run both only if your data model needs it.
Choose the host and network boundary
Your infrastructure team picks a server or virtual machine inside your data center or cloud account, with access limited to the internal network and the users who need the database. Document the host name, operating system, storage location, and who holds administrator access. Confirm with your security team that the host sits in the same network zone as your existing Access file share or a zone with equivalent controls. The step is done when the host is reachable only from approved networks and the access list is written down.
Run a test instance of Baserow
On the host, run the baserow/baserow Docker image as a single container for evaluation only. This image bundles all services with an internal PostgreSQL and Redis by default, which suits a test but not production. Load a sample of your Access tables or an Airtable import to check field types, attachments and grid views. The step is done when a test user can sign in, create a record, upload a file and see the same data after a container restart.
Build the production stack with an external PostgreSQL
Deploy Docker Compose with separate backend and web-frontend images for production, or Kubernetes with Helm if you need horizontal scaling. Point the backend at an external PostgreSQL instance, which Baserow highly recommends for production, and keep that database on managed storage with its own patching schedule. Store secrets in your existing secrets manager rather than in the Compose file. The step is done when the stack restarts cleanly and the database holds the Baserow tables, not the container.
Set up PostgreSQL and Mathesar as an alternative path
If your Access data is a line-of-business system better suited to a relational database, create or connect a PostgreSQL instance and install Mathesar with Docker Compose, or from scratch on Linux, macOS or WSL for a lab. Mathesar is in public beta, so confirm the version you deploy against the version support table and keep it off production until your own testing passes. Map user access to PostgreSQL roles and privileges, using existing roles or roles created in Mathesar. The step is done when a test role can read and edit only the tables it is granted.
Enable TLS, identity provider and backups
Place the service behind a reverse proxy with TLS certificates issued by your internal certificate authority or public CA, and restrict plain HTTP. Connect your identity provider: Baserow single sign-on, covering SAML, OAuth 2.0 and generic OpenID Connect, requires an activated Advanced or Enterprise license, so confirm licensing before you plan login rollout. Configure scheduled PostgreSQL backups and test a restore to a separate host, including attachment storage. The step is done when a restore test returns the same record counts and the sign-in flow works through your identity provider.
Migrate and validate the data
Export each Access table as CSV, since Access does not produce a single portable file, then import into Baserow or Mathesar and recreate relationships, field types and permissions. Rebuild Access forms, reports and VBA logic separately as views, automations or application screens, and record which items are not carried over. Ask a business owner to sign off on a sample of records for each table. The step is done when record counts match the source, attachments open, and each signed-off table has a written validation record.
Run parallel use and prepare the rollback
Keep the original Access file read-only for a defined parallel period agreed by your project sponsor, and have a named owner decide when the cutover is final. Write a rollback plan that states how to restore the Access file from the last export, how to revoke new users, and who approves the switch back. Test that the rollback steps work on a copy before cutover. The step is done when the sponsor has signed the cutover criteria and the rollback steps have been rehearsed.
Hand over operations and confirm support
Transfer the runbook covering upgrades, backup schedules, certificate renewal and access reviews to the team that will run the platform. Confirm with the vendor or your implementation partner how upgrades and security patches will be applied, and decide whether a retainer covers them. Schedule a first access review and a restore test on a fixed cadence. The step is done when the operations owner has accepted the runbook and the first scheduled review is on the calendar.
What auditors and change boards will ask to see
A migration off Access 2021 is judged by the records it leaves behind, not by the cutover day alone. The cards below list the evidence that connects the platform decision, the data move, the access model and the retirement of the old file. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any assessment or attestation.
Platform support status record
Record the version of the chosen platform, its release date and its support or maintenance status on the day the decision is signed. For Mathesar, note the tagged release and the public beta status, and the PostgreSQL versions that release supports. For Baserow, note the release version and the license type in use. Ask the change board to file this record with the decision, so later reviewers can see why the platform was judged acceptable at that time.
Migration test results with checksums
For each table, keep the source row count from Access, the target row count after import, and a checksum or hash of the exported CSV. Compare them before and after the load and record any difference with its cause. Access exports one object at a time, so the test log should list every table and view. Attachments and OLE objects need their own counts, because they are often dropped silently during export.
Access role mappings
Document how each Access user group, form permission and linked-file permission maps to a role in the new platform. In Mathesar, access follows PostgreSQL roles and privileges. In Baserow, record which role or workspace permission replaces each Access group, and whether single sign-on on the paid plan is used to assign it. Reviewers will check that no user keeps access they did not have in Access, and that no removed user still holds a login.
Backup and restore test records
Keep a dated record of at least one restore test from the new database, including the backup file used, the restore target, the time taken and the result of comparing restored rows with the source. Write down who ran the test and who approved it. If the platform runs in a single container with an internal PostgreSQL by default, document the external database and the backup job that replaces it for production.
Access file decommissioning record
Record when the Access file was made read-only, where the final copy is archived, who approved deletion, and when the file was removed from shared drives and user machines. Note the retention period set by your own policy, since no default is assumed here. A decommissioning record closes the gap that would otherwise leave an unsupported Access file in use after cutover.
Signed scope and change approvals
Keep the written scope that sets the deliverables, the migration steps, the exclusions and the acceptance criteria, signed by both the client and DeployOpen before work starts. Attach the change board approvals for cutover and rollback. Engagements are fixed-scope, so this document is the reference against which every other record is checked. Confirm with your own assessor which of these records they require in their evidence list.
Questions buyers ask before replacing Access
What drives the cost of upgrading Access versus replacing it?
The biggest difference is which costs recur. Upgrading to Access in Microsoft 365 or LTSC 2024 keeps the per-user licensing model and the shared-file setup, so licenses are a recurring cost and the database still runs on a file share. Replacing it moves costs into a server, a PostgreSQL instance, a migration project and support. Baserow's own pricing lists Premium at $10 and Advanced at $18 per user per month billed yearly on its cloud service, and its self-hosted edition is free under the MIT License for non-premium features, so per-seat fees depend on which license type you choose. Ask any vendor or partner for each component as a separate line: licenses, hosting, PostgreSQL administration, data migration, rebuilding forms and logic, and ongoing support.
How much work does the migration need from our own staff?
Expect your staff to supply knowledge and approvals, not to do the engineering. Someone who knows the Access database must list every table, form, report, macro and VBA module, and identify which ones people use. A data owner must confirm which records are current and who needs which access. Your infrastructure team must provide a server or cloud account, backups and network rules. Baserow's Airtable importer, for example, does not carry over formula, lookup, rollup or collaborator fields, so the owners of those fields must be involved early in any similar move from Access.
Can our team migrate Access to Baserow or PostgreSQL without outside help?
A team with database and web application skills can do the migration in-house, but the risk sits in logic rather than data. Moving tables is mostly a matter of export and import, and Baserow and Mathesar both accept CSV. The harder work is replacing VBA, queries and forms, which needs rework in the new platform. Mathesar's CSV import accepts comma, tab, semicolon, colon and pipe delimiters, which helps with messy exports. Whether to bring in a partner depends on how much logic your Access files contain and how much time your staff can spare. DeployOpen plans and implements these migrations under a written, fixed scope.
How long does replacing Access take, and what sets that length?
The length depends on the number of tables, the volume of VBA and macros, the number of forms and reports, and how many users must be trained and cut over. No supplied figure gives a standard duration, so ask for one in the written scope rather than relying on a general estimate. A useful split is discovery and inventory, data export and mapping, rebuilding logic and interfaces, testing with real users, and cutover. Keeping Access running in parallel during testing usually adds time but reduces risk. Ask for a timeline that lists each phase and the client decisions each phase needs.
What happens to our VBA code, forms and reports?
VBA does not move across as code. Its business rules must be rewritten as automations, formulas or application logic on the new platform. Baserow offers automations and an application builder for forms, pages and dashboards, while Mathesar offers a form builder and a Data Explorer for queries, and PostgreSQL views can hold many queries. Access reports usually need to be rebuilt as dashboards or exports. Before quoting, ask the provider to classify each VBA module and form as keep, rebuild, or retire, since that classification is the main cost driver for this part of the work.
Does our data stay on our own servers after the move?
Yes, if you self-host, and that is the reason to choose this path. Mathesar states that it is committed to always being self-hostable, so data does not have to leave your own servers, and it can connect to an existing PostgreSQL database. Baserow's self-hosted edition runs on your infrastructure with PostgreSQL. Confirm three things in writing: where backups are stored, which third-party services the installation calls, and whether any import step uses a vendor-hosted service. Note that the Airtable importer reads from a public share link, so do not use that route for sensitive data.
What should we ask for in a written quote?
Ask for a fixed scope that lists every Access object in the inventory, with a decision for each one: migrate, rebuild, or retire. Require the quote to separate one-time costs (discovery, migration, rebuilding logic, testing, training) from recurring costs (hosting, PostgreSQL maintenance, upgrades, support, any Baserow license). Ask which Baserow license type applies and why, how access rules and single sign-on will be configured, and what backup and restore testing is included. Also request acceptance criteria, a cutover plan, and a rollback path to the existing Access file until the new system is signed off.
Which Baserow or Mathesar features need a paid license?
For Baserow, paid self-hosted licenses are Premium, Advanced and Enterprise, and an instance can use only one license type. Single sign-on with SAML, OAuth 2.0 providers and generic OpenID Connect is available on Advanced and Enterprise with an activated license, so plan for it if you need SSO. Mathesar is GPLv3 open source and currently describes itself as in public beta, with version 0.12.0 tagged on July 2, 2026, so check its roadmap and release notes against your production needs. Confirm each feature you depend on against the current documentation before you commit.
How DeployOpen plans and runs an Access replacement
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so an Access 2021 replacement runs in your cloud account, data center or air-gapped network. The work follows a written scope, from confirming which databases and users depend on Access through to a documented, supported system.
How we scope
- Inventory every Access file, linked table, macro and user group that depends on the database.
- Confirm which target fits: Access in Microsoft 365 or LTSC 2024, Baserow, or PostgreSQL with Mathesar.
- Agree deliverables, timelines and responsibilities in writing before any migration work begins.
How we build
- Deploy the chosen platform in your environment with a server, PostgreSQL and backups you control.
- Test migrated tables, relationships, attachments and access rules against a copy of the original data.
- Document configuration, roles and user access so your team can review and change them later.
How we hand over
- Run a cutover plan with a rollback path and confirm sign-off from the database owners.
- Deliver runbooks for backup, restore, upgrades and user administration in your own terms.
- Train the people who will edit records, manage access and maintain the platform after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope project ends.
- Plan platform upgrades on a schedule you approve, including checks on release notes and test restores.
- Ask for the support scope, response expectations and fees in writing as part of your quote.
