How to migrate from Microsoft Access to Baserow without losing data or logic
Tables and records move to Baserow, but forms, reports, VBA and macros must be rebuilt, so plan the migration as two projects: a data move and a logic rebuild. Most teams start this work after a renewal notice, a change in how Access is licensed, a file that has outgrown shared-drive use, or a requirement to keep records in a specific region. The database owner inside the organization usually holds the schema knowledge and the business rules, while an implementation partner handles the import, the Docker deployment, single sign-on and the rebuilt interface. Effort is driven mainly by the number of forms, reports and VBA procedures, not by the row count, so inventory those objects before you estimate anything.
Start with a full inventory of the Access file: every table, query, form, report, macro, module and linked table, plus which users rely on each one. Baserow's importer works from Airtable, not Access, so Access data normally leaves the file as CSV or Excel, and the export must be handled per table. Attachments, multivalued fields and lookups need a separate decision, because the flat export loses their structure. Record the relationships and the business rules that Access currently enforces through validation rules, referential integrity and code. Confirm how your Baserow edition handles user accounts and permissions before import, since the Advanced plan's role-based permissions and single sign-on sit behind a paid license. Test the rebuilt tables with a copy of real data before anyone depends on them.
Which Access features map to Baserow, and which need rework
This table compares the main Access objects with their Baserow equivalents and marks each as clean, needs rework or gap. Read the rows as a planning checklist: anything marked rework or gap must be rebuilt by hand, and the importer does not carry Access-specific objects across. The Airtable importer limits are included only as a reference point for what Baserow importers skip in general.
| Access feature | Baserow equivalent | Status | What to plan |
|---|---|---|---|
| Tables and text, number, date fields | Tables with matching field types | clean | Map each Access data type to a Baserow field type and check precision, date formats and required flags. |
| Primary keys and AutoNumber | Auto-increment row ID | needs rework | Baserow row IDs are not your Access keys. Keep old keys in a plain text field if other records reference them. |
| Relationships (one-to-many) | Link to table fields | needs rework | Access enforces relationships in the table design. Recreate each link field and confirm which side holds the reference. |
| Multivalued fields | Multiple select or link to table | needs rework | Access multivalued fields have no direct import path. Split them into a link table or a multiple select field before importing. |
| Lookup fields | Lookup field on a link | needs rework | The Airtable importer skips lookup, rollup and formula fields, so expect to recreate these by hand from linked tables. |
| Calculated fields and expressions | Formula field | needs rework | Access expressions must be rewritten in Baserow formula syntax. Test each result against the original Access output. |
| Queries (select and crosstab) | Filtered and sorted views | needs rework | Simple select queries become views. Joins across several tables and crosstabs usually need a rebuilt design or a saved view per report. |
| Forms and reports | Application builder pages | gap | Access forms and reports have no import path. Rebuild layouts in the application builder and confirm print output needs. |
| Macros and VBA | Automations and the API | gap | Macros map to automations where triggers and actions exist. VBA logic has no equivalent and must be redesigned as automations or external code. |
| Attachments and OLE objects | File fields | needs rework | Access attachment fields and OLE objects are exported separately. Confirm file counts and sizes, and re-link files after import. |
| User access and security | Workspace roles and SSO on paid plans | needs rework | Access user-level security is not carried over. Define roles in Baserow and confirm which SSO options your license includes. |
What moves cleanly and what does not
Plan the migration around a clear split: plain tables, text, number and date fields, and individual records move with the least risk, while calculated values, query logic, VBA and form layout each need a design decision before anything is imported. Start by listing every table in the Access database and marking each field as either stored data or derived data. Stored values such as names, codes, quantities and dates are the ones the importer is most likely to carry across unchanged. Derived values, such as expressions in queries, calculated controls and anything that depends on VBA, have to be rebuilt in Baserow as formula fields, automations or application builder logic. Confirm each of these choices against the importer documentation in Baserow's Airtable import guide, which describes the Airtable path, and treat Access-specific objects as outside what that guide promises.
Attachments, multivalued fields and lookup fields need explicit handling rather than a default assumption. Access exports do not carry OLE objects and attachments in the same way as plain columns, so decide whether files will be re-uploaded from a folder, linked from a file store, or kept in the Access file as an archive. Multivalued fields in Access often arrive as delimited text in a flat export, so decide how each one becomes a link to another Baserow table or a multiple select field. Lookup fields that Access resolves at query time should be recreated as link fields and lookups in Baserow, and their values checked row by row. Run the complete export, import and check on a copy of the database, compare record counts, attachment counts and sample relationships against the source, and only schedule cutover once those checks pass.
Migration sequence from inventory to decommission
This sequence moves an Access database into Baserow in controlled stages, so each table, relationship and business rule is proven against the original before Access is retired. Each step closes with a named output that the next step depends on.
Inventory every object in the Access file
List every table, form, report, query, macro and VBA module in the database, and note who uses each object and how often. Record which tables hold attachments, multivalued fields, lookup fields and calculated expressions, because these need special handling. The database owner and at least one daily user should sign off the list. The output is an inventory sheet with one row per object, marked as migrate, rebuild, replace with an automation or retire.
Build the field map and target schema
Map each Access table and field to a Baserow table and field type, and decide how each relationship will be recreated using link-to-table fields. Decide how multivalued fields will be split into linked tables or kept as multiple select fields, and how lookup values will be recreated with lookup fields where Baserow supports them. Confirm the mapping with the business owner of each table. The output is a field map that names the source object, target table, field type and any transformation for every column.
Run a pilot import of one table with attachments
Choose one representative table that contains attachments, a relationship and at least one filtered view, then export it from Access and load it into a non-production Baserow instance. Baserow's Airtable importer is not the route for Access data, so plan a CSV or Excel import and re-attach files manually or with a scripted upload where needed. Compare row counts, attachment counts, date and number formats, and relationship links against the source. The output is a pilot defect list with each issue, its cause and the fix applied.
Import the remaining tables in dependency order
Load parent tables before child tables so that link fields can reference existing rows, and apply the fixes from the pilot defect list to the import scripts. Rebuild grid views with the filters and sorts users depend on, then check that permissions for each workspace match the access model agreed with the business owners. The output is a loaded staging instance with a table-by-table record count that matches the source.
Rebuild forms, reports and macro logic
Recreate Access forms as forms or pages in Baserow's application builder, and reports as dashboards or filtered views where the layout allows. Replace macro and VBA logic with Baserow automations, and document any logic that cannot be reproduced so the owner can decide whether to change the process. Test each automation with sample records before enabling it for live data. The output is a rebuild register listing each form, report and automation, its test result and any accepted gap.
Run a parallel period with Access read-only
Put the Access file into read-only mode for reference, and have users enter new records in Baserow during an agreed parallel period. Each business day, compare key totals and record counts for the most used tables between the two systems, and log any difference. Keep Access available only to answer questions about historical records. The output is a reconciliation report that shows each comparison, the variance found and the resolution.
Cut over and freeze the Access file
Schedule the cutover at a point when no users are entering data, run a final incremental export from Access, and load the changes into the production Baserow instance. Confirm that the reconciliation report shows no open variances, switch users to Baserow links, and tell them where the old file lives. The output is a signed cutover record listing the final export time, the final counts and the approver.
Decommission Access and retain an archive
After the agreed retention period in your records policy, remove the working copy of the Access file from shared drives and user desktops, and store a read-only archive copy with its inventory and reconciliation records in a controlled location. Confirm with your records or legal team how long the archive must be kept. The output is a retired Access file with a retained archive and a decommission record that names the owner and the storage location.
Data exports, attachments and integrations to rebuild
Access stores data, files and logic in different places, and each one moves on its own path. This section covers the four areas that most often take longer than the table import itself. Plan them before the first table moves, so nothing is lost or silently changed.
Exporting each Access object
Access exports one object at a time, so every table, query and saved export needs its own pass. Export tables as delimited text or Excel files, then check row counts against the source database before anything is imported. Record which queries hold business logic, because a query exported as data loses its criteria and joins. Keep a dated copy of the original .accdb file until the new system has been checked against it.
Attachments and OLE objects
Attachment fields in Access can be exported as file references, but embedded OLE objects such as Word documents, images or spreadsheets often do not come across as usable files. Extract these objects from the database first and store them in a folder named by record ID. Then map each file back to its row in Baserow's file field. Confirm the file size limits and storage location of your self-hosted instance before bulk upload.
Flattening multivalued fields
Access multivalued lookup fields store several values in one cell, and a CSV export usually flattens them into a delimited string. Decide whether each one becomes a multiple select field, a link to another table, or a plain text column. Split and check these values before import, since a comma inside a value can break a column. Test a sample of records with several selections to confirm the values survived.
Rebuilding table links
Access relationships are enforced by keys and referential integrity, while Baserow expresses them as link to table fields. Import tables in dependency order, then recreate each link by matching the primary key values from the source. Compare a count of linked records per parent row before and after the move. Access lookup fields do not carry over as lookups, so rebuild each one as a lookup or rollup in Baserow and check the result on a sample.
Rebuilding automations and API integrations
Access macros, VBA procedures and linked data sources need replacements in Baserow's automations and REST API. List every scheduled task, data export and external connection, then assign each one an owner and a target. Baserow's API is token-based, so create scoped tokens for each integration rather than sharing one login. Test each automation against copied data, and confirm the trigger and error handling match the original logic.
How the migration differs by database size and starting point
A small Access file with one table, a form and perhaps a report is the simplest case. The work is mostly a clean export and a rebuilt view, and the main risk is forgetting a field that only exists in a form. Because there are few relationships, the migration can usually be checked by comparing record counts and a sample of rows against the original.
- Scope: one table, its fields and any saved filters or sorts that users depend on.
- Sequencing: export the table, import it into a Baserow workspace, then rebuild the grid view with the same filters and sorts.
- Hidden logic: check whether a calculated field or a default value lives in a query rather than the table, since it will not travel with the data.
- Users: decide whether the tracker stays single-user or moves to shared access, which affects whether SSO on a paid plan matters.
Confirm with the people who use the tracker which columns they actually read, so the rebuilt view matches daily work rather than the original form layout.
A database with linked tables, attachments and lookup fields needs the most planning before any data moves. Baserow's Airtable importer does not carry formula, lookup or rollup fields, and Access exports do not carry attachments or OLE objects in the way a table export suggests, so each of these needs an explicit plan. Relationships are recreated as link fields, and this step is where mistakes in referential structure tend to appear.
- Dependency map: list every table, relationship and lookup, and mark which ones Baserow can represent as link fields.
- Attachments: extract files from the Access database separately and map each file back to its record ID before import.
- Lookups: rebuild them as formula fields in Baserow after the linked rows exist, then compare results with the original.
- Multivalued fields: decide whether each becomes a link, a multiple select or a text field, since a flattened export loses the structure.
- Import order: load parent tables first so link fields can point to existing rows.
Review the export guide for Access before starting, and ask whether each attachment is still referenced by a record, since orphaned files often inflate the migration.
When much of the business logic sits in VBA modules, the data is often the smaller problem. Baserow replaces macros with automations and offers no direct equivalent to VBA procedures, so each routine must be read, classified and redesigned. The migration becomes a requirements exercise, and the schedule depends more on how many routines exist and how many depend on each other than on record volume.
- Inventory: list every module, procedure, macro and event handler, and note what triggers each one.
- Classification: sort routines into data validation, calculations, notifications and integrations, since each category maps to a different Baserow feature.
- Automations: rebuild simple triggers as Baserow automations, and document any logic that needs an external script or a service.
- Testing: write test cases from the existing behavior, including edge cases users rely on, before switching off the original.
- Parallel running: keep the Access file read-only during verification so the two outputs can be compared.
Ask for a written list of routines and their owners before agreeing on scope, because undocumented VBA is the most common reason a migration expands.
A database shared over a network drive by many users changes the sequencing more than the content. The migration must account for who edits data during cutover, how access is granted, and how changes made during the transition are reconciled. Baserow is server-based and browser-accessed, so the cutover is a planned switch rather than a file copy, and access rules must be set up before users arrive.
- Freeze window: agree with users when edits stop on the Access file, and who is responsible for the final export.
- Permissions: map existing Access users and their editing rights to Baserow workspace roles before the switch.
- Identity: SSO is available on Baserow's Advanced and Enterprise plans with an activated license, so confirm which identity provider the organization will use.
- Deployment: plan the self-hosted server, with an external PostgreSQL recommended for production, before the cutover date.
- Delta sync: decide how records created in Access during testing will be re-imported or entered manually.
Confirm the license type you need for SSO and the number of concurrent editors before requesting a quote, since both affect the setup.
What usually goes wrong in an Access to Baserow migration
Most failed Access migrations do not fail loudly. The data arrives, the tables look right, and the problems surface weeks later in a report, a form or a user's login. The six cards below cover the points where Access behavior, Baserow behavior and undocumented logic diverge, with a prevention step for each.
Silent loss of calculated values
Baserow's Airtable importer does not carry over formula, lookup or rollup fields, and Access calculated fields and lookup columns deserve the same scrutiny in any export. A lookup exported as an ID or a calculated column dropped without warning can leave totals and reference values blank. Before cutover, list every calculated and lookup field in the source, record the expected value for sample rows, and compare those values after import in Baserow.
Attachments not carried across
Access stores attachments and OLE objects in ways that a plain table export does not preserve, so files often arrive as missing or broken references. Baserow's file fields need the files themselves, not only their names. Inventory which tables hold attachments, extract the files to a controlled location with their record keys, re-upload them into Baserow file fields, and spot-check that each record opens the correct document.
Relationships recreated incorrectly
Access relationships enforce referential integrity through the relationship window, while Baserow expresses them as link-to-table fields with their own behavior. A one-to-many link recreated as many-to-many, or a link pointing at the wrong table after a rename, can duplicate or orphan records. Draw the source relationship map first, rebuild links table by table in Baserow, and test with a record that has several children and one that has none.
Form behavior the builder does not match
Access forms can enforce validation rules, tab order, subforms and default values in ways users rely on daily. Baserow's application builder and forms cover data entry, but they do not replicate every Access form behavior one for one. Before rebuilding, record what each form does for its users, including required fields and default values, and run a pilot with the people who use those forms to confirm the replacement behaves as they expect.
VBA logic left undocumented
Macros and VBA modules often hold business rules that nobody wrote down, such as status changes, notifications and data clean-up routines. Baserow replaces these with automations, and anything not listed in the inventory will simply stop running. Read every module and macro, write each rule as a plain statement, then assign each one either to a Baserow automation or to a documented manual step with an owner.
SSO assumed available on every plan
Teams often assume single sign-on comes with any self-hosted install, but Baserow's SAML, OAuth and OpenID Connect sign-in is available on the Advanced and Enterprise plans with an activated license. Access users who authenticate through Windows accounts may find that sign-in changes at cutover. Confirm the license type you need before the project starts, and ask the vendor which plan includes SSO for your setup.
What drives cost and duration, and how to keep each down
This table breaks the migration into cost components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote and to compare internal effort with external work. The main takeaway is that the Baserow license is only one line item, and the rebuild of forms, reports and VBA logic usually drives the effort.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Internal inventory and sign-off | One-time | Number of tables, forms, reports, macros and VBA modules, plus how many business owners must approve the target design | Export a table and field list early, retire unused objects before migration, and agree the sign-off list in writing |
| Self-hosted server and storage | Setup one-time, hosting recurring | Expected user count, attachment volume and backup retention, since Access attachments are copied into Baserow | Size storage from the attachment inventory, not the .accdb file size, and confirm backup and restore targets |
| PostgreSQL database | Setup one-time, operation recurring | Use of the internal PostgreSQL in the default Docker image versus an external PostgreSQL that the Baserow documentation highly recommends for production | Use an existing managed or internal PostgreSQL service where the organization already runs one, and confirm patching responsibility |
| Baserow license | Recurring if paid | Free edition versus Premium, Advanced or Enterprise, which are paid self-hosted license types; SSO is included on Advanced and Enterprise with an activated license | Start on the free edition for pilot groups, and buy a paid license only for features the business needs, such as SSO on Advanced; confirm current terms with Baserow |
| Migration and rebuild work | One-time | Lookup, multivalued, formula and linked fields that the Airtable importer does not copy, though Access imports are handled separately; forms, reports and VBA logic must be rebuilt in the application builder and automations | Map each Access object to a target feature before build work starts, and split rebuilds into fixed-scope phases |
| Data validation and cutover | One-time | Record counts, attachment checks, relationship integrity and parallel-run period before Access is retired | Write acceptance tests from the inventory and run one reconciled export per table |
| Ongoing support, upgrades and testing | Recurring | Release cadence (for example, Baserow 2.4.1 followed 2.4.0 in the same season), security patches, user onboarding and changes to automations | Agree a support scope in writing, define who applies upgrades, and budget review time for each release |
| Written quote checklist | Planning | Missing scope items cause change orders | Ask for line items per component above, the license type assumed, the data volume assumed, and the exact objects in or out of scope |
Questions buyers ask before moving from Access to Baserow
How much effort and cost does moving from Access to Baserow involve?
The cost is mostly labor, plus a server and a license decision. Baserow's open-source edition under the MIT License carries no license fee for the core product, but the work of exporting tables, rebuilding relationships, recreating forms and reports, and replacing macros is paid for in staff time or an implementation engagement. The main drivers are the number of tables and relationships, how much VBA and how many macros the database contains, the volume of attachments, and how many users need access. Ask for a quote built from a written scope that lists each object to be migrated and each form, report and automation to be rebuilt. One-time migration work is separate from recurring costs such as hosting, PostgreSQL administration, upgrades and support.
How long does an Access to Baserow migration take, and why does it vary?
Duration depends on the shape of the database, not on the row count alone. A flat database with a few tables and no custom logic moves faster than one with dozens of linked tables, multivalued fields, lookups and VBA procedures that drive business rules. Other factors include how many users must be trained, whether data needs cleansing before import, how many attachments must be checked, and how many parallel reports or forms need to be rebuilt in the application builder. Ask for a timeline in the written scope, with milestones for export, import validation, rebuilding of views and automations, user acceptance testing and cutover.
What does the migration need from our own staff?
Your staff supply knowledge that the database itself does not record. Someone who understands the business rules must confirm which forms, reports and queries are still used, which macros enforce policy, and which fields are reference data that should stay consistent. A database owner must approve the field mapping, test imported records against the original file, and sign off on access rules for each group of users. Plan time for these reviews, because they are often the step that decides how quickly the project closes.
Can our internal team migrate Access to Baserow without outside help?
A team with database and PostgreSQL experience can usually handle a small, flat Access database without help, using the Airtable-style import paths as a reference and Baserow's own documentation for field types. Teams with multivalued fields, lookup chains, complex VBA or a need for SSO and audit logs typically benefit from an implementation partner for the design decisions. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under fixed-scope engagements, so the choice between doing it internally and buying the work can be made against a written scope rather than an estimate.
Do SSO and audit logs require a paid Baserow license?
Yes, for self-hosted instances. Baserow single sign-on, covering SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect, is available on the Advanced and Enterprise plans with an activated license. Role-based permissions and audit logs are listed for Advanced on Baserow's pricing page. Confirm the current license terms before you plan, because an instance can use only one license type, and a Premium license does not carry the same feature set. Ask the vendor for the written entitlement list that applies to your instance size and user count.
What happens to our macros and VBA after the move?
Macros and VBA do not move with the data. Baserow's Airtable importer, for example, does not carry automations or interfaces across, and the same principle applies to Access logic. Each macro must be rewritten as a Baserow automation, a field formula, or an application builder action, and VBA procedures that perform calculations, validation or integration usually need redesign. Inventory every macro and procedure during scoping, classify each one as replace, simplify or retire, and test the replacement against the behavior you recorded in Access.
How are cutover and rollback handled?
Cutover should be planned as a dated switch with a documented rollback. Keep the Access file read-only after the final export, run a reconciliation of record counts and key totals between the file and Baserow, and keep the original file available until users confirm the new forms and automations. Rollback means returning users to the Access file if validation fails, which is only safe if no new records were written to Baserow in the meantime. Ask for the cutover plan, reconciliation checks and rollback criteria to be written into the scope before work starts.
How DeployOpen scopes and runs the migration
A DeployOpen migration starts with a written scope, not an open-ended project. Before any table is moved, the scope document should name each Access object in play: the tables, the queries that feed forms and reports, the macros and VBA procedures, the linked files and the user groups that depend on them. It should also list the deliverables, such as a rebuilt set of Baserow tables, the application builder pages that replace Access forms and reports, the automations that replace macros, and a short runbook for your administrators. Timelines are agreed in the same document. Ask for each deliverable to be tied to an acceptance check you can run yourself, for example a record count per table compared with the Access source, and a sign-off step before the old database is set to read-only.
The Baserow instance itself is deployed inside your own cloud account, data center or air-gapped network, so Access files, attachments and access rules never leave your environment during the work. Confirm with DeployOpen which Baserow image and deployment pattern fit your scale: the single container from the baserow/baserow image is suitable for a pilot, while production should use an external PostgreSQL, and a multi-instance layout needs Docker Compose or Helm. Hardening covers the parts a security reviewer will ask about: TLS termination, SSO configured on a plan that supports it, least-privilege workspace roles, network restrictions on the admin interface, and secrets stored outside the compose file. Backups of the PostgreSQL database and the attachment storage are configured and restore-tested before cutover, because a restore test is the only evidence that a backup works.
Documentation and support are handled as separate items in the scope. The handover pack should cover the data mapping from each Access field type to its Baserow equivalent, the decisions made for lookups and multivalued fields, the upgrade procedure, and the restore steps. Ongoing support, upgrades and continuous checks can be contracted as a retainer after go-live, and it is worth asking whether the retainer covers Baserow version upgrades and how security patches are applied. Pricing is set only from the written scope, so ask for a quote that separates the one-time migration work from any recurring retainer and from your own server and storage costs.
