When a self-hosted Microsoft Access alternative fits and when Access still does
Baserow fits when an Access database has outgrown a single desktop file and now needs to be opened in a browser by several people, with records kept on servers your organization controls. The usual trigger is a shared network file that has become slow, fragile or hard to change, or a team that needs access from outside the office. Baserow's spreadsheet-style tables, relationships, forms and application builder cover much of what everyday users do in Access, and its self-hosted edition keeps data on your own infrastructure. Keeping Access is reasonable when the database is a single-user tool or a small shared file whose logic lives mostly in VBA, complex reports and macros that would need rebuilding.
The decision turns on four questions. First, how much VBA and report logic the database depends on: list every module, query and report, and mark which ones only reformat data and which enforce business rules, because the second group needs a planned rebuild as automations and application builder pages. Second, how many users edit at the same time and from where, since that determines whether a server-based tool is needed at all. Third, whether you require single sign-on: Baserow's SSO for SAML, OAuth 2.0 providers and generic OpenID Connect is available on the Advanced and Enterprise plans with an activated license, so confirm the plan you need before you commit. Fourth, who will run the server, including patching, backups and upgrades. Confirm these answers with the people who own the Access file before you choose a path.
Which option fits each scenario
This table matches common Access situations to the better fit between keeping Access and moving to self-hosted Baserow. Read each row against your own requirements, because the answer changes when VBA logic, reports or on-premises rules are heavy. The main takeaway is that Baserow fits shared, browser-based data work well, while Access stays stronger for single-user desktop tools and heavy VBA.
| Scenario | Better fit | Reason |
|---|---|---|
| Small database used by one person on a desktop | Access | Forms, reports and local queries work offline on one machine, and a server adds setup with little gain. |
| Shared data edited by a team in a web browser | Baserow | Baserow runs in the browser for many users, with the same tables, views and permissions for everyone. |
| Heavy VBA modules and custom Access reports | Access | Baserow replaces VBA with automations and the application builder, so logic-heavy databases need rebuilding first. |
| Single sign-on across many users | Baserow | SSO for SAML and OpenID Connect is on Advanced and Enterprise plans with an activated license, so confirm the plan before rollout. |
| Records that must stay on your own servers | Baserow | A self-hosted Baserow instance keeps tables, attachments and users inside your network, unlike Access files on shared drives. |
| Relational data with many linked tables and lookups | Baserow | Baserow supports relationships between tables, but lookup and multivalued fields need checking during migration. |
| Access file near the 2 GB limit or shared over a network drive | Baserow | A server-based database avoids the file size and concurrency limits that Access files hit on shared drives. |
| Teams that need complex printed reports with precise layout | Access | Access report designer gives fine control over print layout, which browser views in Baserow do not match directly. |
What a spreadsheet-style table changes compared with an Access file
An Access file bundles tables, queries, forms, reports and VBA code into one document that each user opens on a desktop or network share. Baserow takes a different shape: tables, relationships and records live in a server-side application backed by PostgreSQL, and people reach them through a browser or the API. The forms, reports and macro logic that sat inside the Access file are rebuilt elsewhere, so the first decision is which of those objects your team actually uses every day and which can be retired. Baserow's own documentation describes it as a spreadsheet database hybrid that also builds applications, so the data model moves across while the front end is designed again.
A link-to-table field in Access usually maps to a link-to-table field in Baserow, which keeps the relationship between two tables visible in both directions. The mapping needs checking, though, for three field types. Multivalued fields in Access may need to become linked records or a separate junction table. Lookup fields and calculated values are the risk: Baserow's Airtable importer, for example, does not copy formula, lookup or rollup fields at all, and an Access importer will not guarantee the same behavior. Export each calculation as a result and as a written expression, then rebuild it as a Baserow formula or automation and compare the outputs on a sample of records. The exact field mapping must be confirmed against the Baserow documentation and a test import of a copy of your database, not assumed from this summary.
Capabilities side by side
This table compares the main capabilities of a Microsoft Access database with self-hosted Baserow. Read the open-source column as what Baserow's documented features cover, and confirm each gap against your own Access version and Baserow release before you plan the move. The main takeaway is that Baserow replaces the shared data and browser access well, but Access forms, reports and VBA have no direct equivalent and need to be rebuilt.
| Capability | Microsoft Access | Self-hosted Baserow |
|---|---|---|
| Tables and relationships | Relational tables with keys, relationships and referential integrity enforced in the database engine | Tables with link-to-table relationships between fields; confirm how your key and integrity rules map |
| Forms and reports | Native forms and printable reports built in the desktop client | Application builder provides forms and portals; Access reports need to be rebuilt, not copied |
| Queries and calculations | Query designer, SQL and expressions in forms and controls | Formula fields and filtered views; complex multi-table queries may need rework |
| VBA or macro logic | VBA modules and macros run inside the database file | Automations replace simple macros; VBA code has no direct equivalent and must be redesigned |
| Browser access | Desktop application; browser access requires a different platform | Browser-based by design for all users |
| Concurrent multi-user editing | Shared file over a network drive, with size and concurrency limits in practice | Multi-user editing on one server; confirm concurrency and sizing for your user count |
| Single sign-on | Depends on the Windows or Microsoft 365 identity used to open the file | SSO on Advanced and Enterprise licenses with an activated license |
| Role-based permissions | Managed through database security and file-level permissions | Role-based permissions listed for Advanced; confirm the exact roles you need |
| Audit logs | Not built in for typical Access files; confirm your setup | Audit logs listed for Advanced; confirm retention and export |
| Data import and export | Import and export per object, with attachments and OLE objects often left out | CSV, Excel, XML and JSON import; Airtable importer for bases from share links |
| API access | Automation through VBA or COM interfaces | API-first, with a REST API for records; confirm endpoints against your integrations |
| Licensing model | Included in Microsoft 365 plans or sold as perpetual versions with fixed end dates | MIT-licensed core; paid Premium, Advanced and Enterprise licenses for self-hosted instances |
Where Access forms, reports and VBA logic go in Baserow
Access forms give users a controlled screen for entering and editing records, with validation rules, drop-down lookups and subforms. In Baserow, day-to-day editing usually happens in the grid view, which works in the browser for many users at once. For a form-like experience, Baserow offers the application builder, which lets you assemble pages, forms and portals on top of your tables. Form-based data entry is therefore rebuilt as application pages, not converted from Access form objects.
- Grid view as the default editor: Most staff can edit rows directly in a browser, with filters and sorts saved on the view.
- Application builder pages: Build forms and portals that write to specific tables, with fields chosen per page.
- Field types for validation: Single select, link to table and date fields replace many lookup combo boxes, but check each field type against your rules.
- Subform equivalents: Access subforms become linked tables or detail pages, which need to be designed again.
- Access form code: Event procedures on form controls, such as BeforeUpdate checks, must be moved to automations or an external service.
Confirm with your team which Access forms are used daily, and test each rebuilt form with real users before retiring the original file.
Access reports group, total and format records for printing or PDF output, often with headers, page numbers and calculated fields. Baserow does not offer a direct equivalent to Access report objects in the sources reviewed for this page. Its dashboards and application builder pages can display summaries, and exported data can feed a document or reporting tool. Plan printed output as a separate workstream, because layout and grouping need their own design.
- Dashboards for summaries: Charts and totals suit on-screen review of key figures.
- Application pages for read-only views: Build a page that displays one record or a filtered list for review.
- CSV, Excel, XML and JSON export: Use these formats to produce output in a separate tool, such as a spreadsheet template or document generator.
- Formatted print layouts: Expect to recreate any multi-level grouped or page-numbered report outside Baserow.
- Calculated totals: Check whether formula results you need on a report are available as fields or must be computed in the export step.
Ask the report owners which printed outputs have legal or customer-facing requirements, and agree on how each will be produced before the migration begins.
VBA modules and macros in Access hold business rules, data checks, file handling and scheduled tasks. VBA code is not converted automatically when you move to Baserow. Simple macro steps, such as updating a field when a row changes, can often be rebuilt as Baserow automations. Logic that depends on Windows, local files, COM objects or complex branching has to move to an external service or be called through the Baserow API, which requires developer time.
- Simple macros to automations: Rules triggered by row changes or on a schedule can be rebuilt in Baserow's automation builder.
- External services for custom code: Move procedures that need a full programming environment to a service your team hosts, and call it from automations or integrations.
- API for custom clients: Baserow is API first, so scripts and applications can read and write rows through it, with credentials managed by your team.
- Windows-specific behavior: Code that opens local files, automates Office or uses ActiveX controls has no direct equivalent and must be redesigned.
- Error handling and audit: Access error routines and logging need to be recreated in the new services, and you should confirm what the target logs.
Inventory every module and macro in the Access file, classify each as simple, external or retire, and estimate developer time for the external group before agreeing scope.
Access queries select, filter, sort and join tables, and some are used as the record source for forms and reports. In Baserow, the closest everyday tool is the view, which stores filters and sorts on a table, and the link to table field, which holds relationships between tables. Select and update queries that change many records at once need a different approach, such as automations or API scripts, and the results should be tested against the Access originals.
- Filtered and sorted views: Saved views cover most simple select queries used by staff.
- Link to table fields: Relationships between tables replace joins for browsing related records.
- Lookup and rollup limits: The Airtable importer does not carry formula, lookup or rollup fields, so confirm how Baserow handles these fields in your own build before relying on them.
- Action queries: Bulk updates and deletes need automations, scripts or API calls, with a backup taken first.
- Query performance: Test large views with real data volumes, since heavy filters on large tables affect responsiveness.
List each query by purpose, mark which are views, relationships or code, and check the results of each rebuilt view against the Access output for the same records.
How data control and hosting work for a self-hosted Access alternative
Moving from a desktop Access file to a self-hosted Baserow instance changes where records and attachments live and who operates the server. The cards below cover the decisions that follow from that change, from the database location and hosting model to identity, backups and the compliance evidence your own auditors will ask for.
Data location and storage
Baserow keeps table data, relationships and uploaded attachments on the server you run, with PostgreSQL holding the structured records. An Access file on a network share is usually one file with its own attachments, so the new system has more parts to place. Confirm the disk, backup target and PostgreSQL host sit in the region and network zone your data rules require, and map where attachment files are written on the host.
Evaluation with the single container
The baserow/baserow Docker image runs all Baserow services in one container and includes an internal PostgreSQL and Redis by default. This suits a pilot with a copy of one Access database, but it bundles the database lifecycle with the application. Treat it as an evaluation setup and plan your move before any real records are loaded.
Production database and scaling
Baserow highly recommends an external PostgreSQL for production. Separating the database lets your DBA apply its own backup, patching and monitoring standards. For larger deployments, Docker Compose runs separate backend and web-frontend images, and Kubernetes with Helm supports horizontally scaled deployments. Ask which topology your user count and data volume need before choosing one.
Single sign-on and license tier
Baserow single sign-on covers SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect. It is available on the Advanced and Enterprise licenses with an activated license, not on the free edition. Access users who authenticate through Active Directory need an identity provider bridge. Confirm which protocol your directory supports and which license tier includes it before you plan the rollout.
Backup and access control responsibilities
Access files often rely on whoever copies the file to a backup folder. With Baserow, your team owns database dumps, attachment storage backups, restore tests and the access model for each workspace and table. Decide who can create workspaces, who manages permissions, and how restores are tested before go-live. Role-based permissions and audit logs are listed for the Advanced cloud plan, so confirm which of these your self-hosted license includes.
Compliance evidence and assessor decisions
A self-hosted system can support controls such as access reviews, logging and backup evidence, but the controls only count once your assessor tests them. DeployOpen prepares systems, configurations and evidence for assessments. It does not issue audit reports or certifications. Your own auditors decide whether the outcome meets your obligations, so agree the evidence list with them early.
What a self-hosted Access alternative costs to run, by component
Access costs are split between licenses, a shared file location and IT time spent on repairs. A self-hosted Baserow deployment moves those costs to a software license choice, a server, a database, backups and migration work. The cards below show who is paid for each item, which costs recur, and what to request in a written quote.
Microsoft 365 or perpetual Access licenses
Access is licensed per user, either through a Microsoft 365 subscription or as a perpetual version with a fixed end of support. Check which edition each user holds, whether licenses are tied to a device or a user account, and when the version in use stops receiving support. Licensing is the cost most likely to recur, since a Microsoft 365 subscription renews every year. Ask your Microsoft reseller to confirm current per-user terms for your tenant.
Shared network file and its backup
Most Access databases live on a network drive that many users open at once. The file server, its storage, its backup schedule and the restore test are costs that often sit in another team's budget and go unnoticed until something breaks. Moving to a server-based database shifts this work to one hosted service that your team backs up and restores. Ask who owns backup retention today and what a restore test would cost in staff hours.
IT time on repairs and file splitting
Large or heavily shared Access files tend to corrupt, bloat or get split into copies per department. Each repair, compaction or manual merge consumes help desk and developer time that rarely appears on a license invoice. Track the hours spent over a typical quarter before comparing options, since this is often the largest hidden cost. A migration removes most of this work but does not remove the need for someone to own the data model.
Baserow Community Edition under the MIT License
The self-hosted core of Baserow is free to use under the MIT License, which permits commercial and private use. Your spend here is infrastructure and staff time, not a per-user fee. Confirm which features your target design needs are in the non-premium tier, because single sign-on and some governance features sit in paid license types. Review the license terms with your legal team before rollout.
Paid Premium, Advanced or Enterprise licenses
Baserow offers three paid self-hosted license types: Premium, with seats assigned manually; Advanced, which grants paid access to users on the instance; and Enterprise, priced through sales. An instance uses only one license type. Single sign-on requires Advanced or Enterprise with an activated license. Ask the vendor which license type fits your user count and whether seat assignments or instance-wide access costs more as headcount grows.
Server, PostgreSQL, backup and migration
Self-hosting adds a server or cluster, an external PostgreSQL database that Baserow highly recommends for production, backup tooling and a migration project. Data volume, concurrency and the number of users drive the size of these components. The one-time migration covers table mapping, attachments and relationships. Ask any implementation partner for a fixed-scope written quote that lists each deliverable, the hosting assumptions and who handles ongoing upgrades.
How a move from Microsoft Access to Baserow usually runs
The sequence turns an Access file into a tested Baserow workspace with verified data, rebuilt views and forms, and a documented cutover that users can sign off.
Inventory every Access object
Before any data moves, list each table, form, report, query, macro and VBA module in the database, along with the owner of each and the people who use it. Record which tables link to each other, which fields hold attachments, multivalued choices or lookups, and which VBA procedures run on open, on save or on a button click. The Access owners and business users should confirm this list, because it sets the scope. The step is done when the inventory has been reviewed and each object is marked as migrate, rebuild, replace or retire.
Export each table from Access
Access exports one object at a time, so the team exports each table to CSV or Excel and keeps a record of the source file, the export date and the row count for every table. Attachments and OLE objects are not carried by a plain table export, so they need a separate extraction plan. The database owner checks the exported row counts against Access before moving on. The step is done when every in-scope table has an exported file and its count matches the source.
Test-import into a staging Baserow instance
Install Baserow in a staging environment inside your own infrastructure, using the Docker installation path with an external PostgreSQL for production-style testing. Import the exported files and check field types, dates, currency, single and multiple select values, and linked record fields one table at a time. Attachments need a separate check, because they must be uploaded to the new workspace and re-linked to their records. The step is done when a written list of field-level differences has been reviewed and each one is fixed or accepted.
Recreate relationships and views
Rebuild the link fields between tables so that the parent and child records match the Access relationships, then recreate the grid views with the filters and sorts that users rely on. Lookup and calculated values from Access queries usually need to be rebuilt as formula fields or as views, and the team should verify each one against a known set of records. The database owner signs off on a sample of related records. The step is done when relationship counts and key view results match the Access file for the agreed test set.
Rebuild forms and logic in Baserow
Recreate the Access forms and reports in the Baserow application builder, and replace macros with Baserow automations where the trigger and action are supported. Any VBA logic that cannot be expressed as an automation must move to external code that calls the Baserow API, and that code needs its own review and tests. Confirm the feature support for each piece against the current Baserow documentation before committing to the design. The step is done when every form and automation has been tested against the scenarios in the inventory.
Run users in parallel
Give a pilot group access to the Baserow workspace while the Access file remains the system of record, and have them enter real work into both for an agreed period. Record every difference in data, permissions or behavior, and fix the cause rather than the symptom. Access permissions must be mapped to Baserow roles and any single sign-on setup must be checked on the plan that includes it. The step is done when the pilot group and the business owners agree that the Baserow results match the Access results.
Cut over and archive the Access file
Set a cutover date agreed with the business owners, freeze new entries in Access, run a final export and import, and confirm the row counts and sample checks one more time. Make Baserow the system of record and tell users where to work. Keep the final Access file as a read-only archive in a controlled location, with its owner and retention terms written down. The step is done when the business owners have signed off on the cutover and the archive location is recorded.
Confirm what your team must provide
The effort depends mainly on how much VBA the database contains, how many forms and reports depend on it, and how many attachments must move. Your team needs Access owners who can explain the business rules, a representative set of test records with expected results, staff who can approve field mappings, and a named sign-off owner. Ask any implementation partner to quote against this written inventory, so that the scope and the test plan are agreed before work starts.
Microsoft Access alternative questions buyers ask before switching
What does it cost to move from Microsoft Access to self-hosted Baserow?
The cost is driven by components, not by a single license line. Baserow's open-source edition is licensed under the MIT License, so the software itself carries no license fee, but you still pay for a server, PostgreSQL operations, backups, the migration work and any support you buy. Recurring costs include infrastructure, patching and staff time, and any paid Baserow license you choose. Ask any quote to separate one-time migration work (export, mapping, rebuilding forms and automations, testing) from recurring operations, and to list each component with its owner. Your current Microsoft 365 or perpetual Access licenses and the file-share setup they depend on are the baseline to compare against.
How long does an Access to Baserow migration take?
No fixed duration applies to every database, so treat any single number with suspicion. The timeline is set by the number of tables and relationships, the volume of attachments, how many forms, reports and macros must be rebuilt, how many users must be trained, and how much testing your business requires. Baserow's Airtable importer illustrates a related limit: it copies one base at a time and does not carry automations or interfaces, so comparable manual rebuilding applies to Access objects that have no direct equivalent. Ask for a written scope that lists each object and the test sign-off criteria before agreeing to a schedule.
What does the migration need from our own staff?
Your team needs to supply knowledge that only the business has. Expect to need an Access owner who understands the tables, queries, forms and macros in daily use, a business user who can confirm that each report and workflow still produces the right result, and someone who controls the identity provider if you plan to use single sign-on. A written test plan with sample records, edge cases and sign-off names keeps the project from stalling. Also name an owner for the server after go-live, because patching, backups and user access reviews do not finish when the data moves.
Can a small team run the migration and the server without outside help?
A small team can do it if it has someone comfortable with Linux, Docker, PostgreSQL backups and database schema design, and if the Access database is modest in size and logic. Baserow's Docker image runs all services in one container by default, and Baserow highly recommends an external PostgreSQL for production, which adds a component to operate. If that skill set is thin, or the database has heavy VBA or many dependent reports, outside help for the build, hardening and handover is a reasonable choice. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and offers retainers for ongoing support.
Does Baserow replace VBA code in Access databases?
No. Baserow does not run VBA, so procedural logic must be re-expressed in other forms. Simple field validation and data entry rules can often be handled with field types and form settings, while event-driven steps such as sending a notification or updating a related record can map to Baserow automations. Logic that depends on custom code, external calls or complex transactions may need a service or script outside Baserow that calls its API, which Baserow describes as headless and API first. Inventory each VBA procedure and macro before choosing the target, because this step decides most of the rebuild effort.
How is single sign-on licensed in self-hosted Baserow?
SSO is a paid feature, not part of the open-source core. Baserow single sign-on covers SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect, and it is available on the Advanced and Enterprise license types with an activated license. Self-hosted Baserow offers Premium, Advanced and Enterprise license types, and an instance can use only one of them, so pick the license type before you plan your identity integration. Confirm current entitlements on the Baserow license documentation before purchase, because feature placement can change between releases.
What happens to attachments and calculated fields during the move?
Attachments and calculated fields need separate handling. Access stores some attachments and OLE objects in ways that a plain table export does not carry, so plan to extract files and link them to records deliberately. Baserow's Airtable importer copies attachments, but it does not copy formula, lookup or rollup fields, so the same rule applies to equivalent Access calculations: recreate them as Baserow formulas where the function exists, or move the calculation into an automation or a database view. Check each calculated value against the original on a sample of records before retiring the Access file, and keep the original file read-only for a defined period.
How DeployOpen helps evaluate, implement and migrate a self-hosted database
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Microsoft Access vs Baserow, we start with a written scope that covers your tables, users, attachments and access rules, then build the Baserow instance in your environment.
How we scope
- Inventory every Access table, query, form, report and macro that users depend on today
- Decide which Access logic becomes Baserow automations, application builder pages or external services
- Confirm the Baserow license type, SSO requirements and user counts before any build starts
- Agree deliverables, timelines and responsibilities in writing before work begins
How we build
- Deploy Baserow in your cloud account, data center or air-gapped network with external PostgreSQL
- Migrate tables, records, attachments and relationships, then test field types and link fields
- Rebuild forms and reports in the application builder and configure role-based permissions
- Run security testing on the application and its APIs before users are onboarded
How we hand over
- Document the architecture, configuration, backup procedures and user access model
- Provide a reconciliation report comparing record counts and sample values with the original Access files
- Walk administrators through permissions, automations, upgrades and day-to-day operations
- Prepare evidence of controls for your compliance assessment, which independent auditors then review
How we support
- Keep the instance patched and upgraded under a retainer agreed in writing
- Run recurring security testing of the application, APIs and hosting environment
- Maintain backups and test restores on a schedule defined in the support scope
- Adjust automations, views and permissions as the Access replacement matures
