Export data from Microsoft Access: a complete guide

How to export your data from Microsoft Access before you move

Access exports one object per export, so every table you need to keep has to be exported on its own, and nothing moves as a single package. Attachments and OLE objects are left out of a standard export, and multivalued and lookup fields need extra handling before the data leaves Access. Whether you are facing a renewal, a licensing change or a move away from a shared Access file, the goal is the same: get every table out intact and know exactly what did not carry over. Start by listing each table and marking any field of these types, because each one changes the export plan.

Build the plan from that list. For each table, record the row count, the attachment and OLE fields, and the multivalued fields, which Access flattens into a single text value. Note the lookup fields as well, since they export as the IDs of the related records, not the names a user sees on screen. Keep the original .accdb file unchanged and make a separate working copy for exporting, so you can repeat any step. Export each table to CSV, then compare row counts and spot-check a sample of records against the source. Mathesar imports CSV with comma, tab, semicolon, colon or pipe delimiters, and Baserow imports CSV, Excel, XML and JSON, so confirm the delimiter and encoding your target expects before you start.

This page describes only the export paths that Access documents, and the exact menu names and options depend on your Access version, so check them in your own installation before you rely on them. Attachments are the most likely gap, so decide early how each file will be extracted and linked to its record in the new system, and test that link with one record. Keep a written record of what was exported, what was excluded and why. The import and rebuild steps for each target platform are covered on the sibling migration pages, which pick up from the files you produce here.

What Access can export and in which format

This table lists the export paths Access offers and what each one carries into a file. Confirm the exact options and limits for your Access version in Microsoft's documentation, since menus and behavior vary by release. The main takeaway is that attachments, embedded objects, multivalued fields and lookups each need their own handling before any table leaves Access.

Data type	Export method	Format	What to check
Table rows	Export as text from a table	Delimited text (CSV)	One object per export; confirm delimiter and encoding options
Query results	Export a query output	Delimited text, Excel, XML	Exports the query's output, so filters and calculations apply
Table or query rows	Export as Excel workbook	Excel (.xlsx)	Check sheet and row limits in Microsoft's Excel specifications
Table structure and field types	Export as XML	XML	Confirm how relationships and multivalued fields are represented
Form data	Export the underlying table or query	Delimited text, Excel, XML	Forms have no separate data path; export the source object
Attachments and OLE objects	Not carried by text or Excel exports	Separate files	Extract files and record each file's link to its record
Multivalued fields	Flattened into one column on export	Delimited text, Excel	Plan a child table before export to keep every value
Lookup fields	Exported as the stored ID	Delimited text, Excel, XML	Export the related table and rebuild the lookup after import

What Access drops during export and how to recover it

Access exports tables cleanly as plain values, but several field types and object kinds do not survive the trip. Each card below names one gap, the workaround that recovers it, and the check to run before you move the data.

Attachments and OLE objects

Attachment fields and embedded OLE objects are not written to a flat export, so the file itself never reaches the target. Export the files from the file system or from the attachment folder you control, then keep a manifest that maps each record key to its file name. In the target, upload the files and link them back by that key. Confirm that every record with an attachment has a matching file before you retire the Access copy.

Multivalued fields flatten

A multivalued field exports as one cell with the values joined into a single string, which loses the separation between items. Before export, create a child table with one row per value and a key back to the parent record. Then export both tables. In the target, these become a linked records or multi-select field. Check a sample of multivalued records against the source to confirm no values were merged or truncated.

Lookup fields come out as IDs

A lookup field carries the related record's key rather than the value you see on screen, so the export shows numbers where names should be. Write a join query in Access that resolves each lookup to the display value, and export that query instead of the raw table. Compare row counts and a few known records between the query output and the form view to confirm the values match.

Relationships and referential rules

Relationships between tables, along with cascade update and cascade delete rules, are schema rather than data, so a CSV export carries none of them. Record the join keys, cardinality and rules in a document before export, and recreate them as links in the target database. Verify that orphan records, which Access may have allowed, are found and resolved rather than silently linked to the wrong parent.

Macros, VBA and saved logic

Macros, VBA procedures, validation rules and default values live in the database file, not in the tables, so they stay behind when you export data. Inventory every macro and module, note which ones enforce data rules and which only drive forms. Rules that protect data need equivalent checks in the target, such as required fields or automations, and should be tested with the same bad inputs you used in Access.

One object per export

Access exports one table or query at a time, so a database with dozens of objects needs a planned sequence rather than a single action. Keep a checklist of every table and query, its row count, and the export file it produced. Use the same export settings for each run, and store the files with a checksum so you can prove later that the copy you imported is the copy you exported.

Why a single export is not a complete copy

A complete copy of an Access database is more than its table data. It includes the tables and their field types, primary keys and indexes, the relationships that link them, the saved queries that shape what users see, the validation rules and default values that govern entry, and the attachments and OLE objects stored inside records. A plain export of each table captures the rows and little else. Before you export anything, inventory the database object by object in the Access Navigation Pane and in the Database Documenter, so you know which items carry data and which carry logic. Anything in the second group is a rebuild task on the target platform, not a copy task.

Decide, for each object, whether it must be kept as data or can be rebuilt. Table contents, lookup lists that users maintain, and historical records are data and must move with verified row counts. Forms, reports, macros and VBA procedures are logic. Keep the logic only as documentation: write down what each form does, which query feeds each report, and what each macro and procedure changes. Confirm this inventory with the people who use the database daily, because undocumented behavior, such as a button that writes an audit row, is the most common thing lost in a move. Record the decision for each object in a migration register so the sign-off is traceable. Keep the original .accdb file untouched after cutover, marked read-only and stored in a location where it cannot be edited by mistake. It is the only reference for what the database did, and it lets you re-run a comparison if a discrepancy appears weeks later. Also keep a dated copy of the exported CSV files and of the export log, with checksums, so you can prove what left the source. Check the retention and legal hold rules that apply to the data before you decide how long the archive must be kept, and confirm them with your records or compliance owner rather than assuming a period.

The export sequence for a complete Access data move

This sequence turns an Access database into a complete, verified set of tables, keys, attachments and settings that can be loaded into Baserow or PostgreSQL with Mathesar. Each stage closes with a check against the source file, so gaps are found before the original is retired.

Freeze changes and back up the file
Agree a cut-off with the people who edit the database, then ask them to stop entering or changing records. Make a copy of the .accdb or .mdb file, store it on a separate location with read-only permissions, and record its file name, size and last-modified time in the migration log. The step is done when the copy opens on a second machine and the record counts in the copy match the live file. Keep this copy untouched until the new system has passed acceptance.
Inventory every table, query, form and attachment
Open the database in Access and list every table, linked table, query, form, report, macro and module, with the field types and the relationships shown in the Relationships window. Note which fields are attachment, OLE object, multivalued, lookup or calculated, because each one exports differently. Count the attachments per table and note any linked tables that point to other files. The output is a spreadsheet that the migration lead signs off, and it becomes the checklist for every later step.
Export each table with keys and field types
Export each table on its own, because Access exports one object at a time. Use the export to a text file or Excel option, and keep the primary key, foreign key columns and date and number formats intact. Record the delimiter and encoding used for each file in the log. Confirm for every file that the row count in the export equals the row count in the table, and that the primary key values are unique and not blank. Where a relationship depends on an AutoNumber key, note the key values so that they can be recreated in the target.
Export attachments separately
Attachment fields and OLE objects are left out of a standard table export, so extract them through a separate process. Save each attached file to a folder structure keyed by the record's primary key, and write a manifest that maps each file to its table, record and original name. Confirm that the number of files in the folder matches the attachment count from the inventory. Then open a sample of files, perhaps one from each table, and compare them with the originals in the source to check that the content is intact.
Flatten multivalued fields and lookups
Multivalued fields and lookup columns need a flat form before they can be loaded. Export multivalued values into a child table with one row per value, linked back by the parent key, and export lookup columns as the stored ID plus a separate lookup table so the name can be recovered. Note that exports of lookups carry IDs rather than the displayed text. Check that the total number of child rows matches the count of values in the source, and that a sample of parent records shows the same values as the form view in Access.
Rebuild queries and calculated fields as documentation
Queries, calculated expressions and VBA logic do not move with the data, so record each one in the migration log with its purpose, its inputs and the output it produces. Save the SQL of each query as text, and keep a list of macros and modules that run automatically. The output is a document that the target team can use to recreate filters, views or automations. Confirm with the business owner which outputs must match exactly, because those become acceptance tests after the import.
Record export settings and reconcile counts
Write a manifest that lists every exported file with its row count, checksum, delimiter, encoding, export date and the person who ran it. Compare the totals with the source counts from the inventory, and mark any difference as an open item that needs an explanation before import. The step closes when the manifest is signed off and stored with the frozen backup. This record is the evidence that the move was complete, and it is the reference point for any later question about missing data.

How to verify an Access export before the source is retired

Do not retire the Access database until every table has passed a count comparison and a sample review against the source. Start with row counts: for each table, record the count in Access before export, then compare it with the count in the target after import. Include the exported CSV files in the comparison, since a mismatch there points to a delimiter, quoting or encoding problem rather than an import fault. Keep a short register listing each table, its source count, its target count and the person who checked it, so a gap can be traced to a specific table and run.

Next, check the values that import most often changes. Dates may shift between day and month order, numbers stored as text in Access may lose leading zeros, and long text fields may be truncated or altered by line breaks. Pick a sample of records from each table, including edge cases such as blank dates, very long notes and values with accents. Then test attachments: open a selection of files in the target and confirm they match the originals by name, size and content, because Access attachments are not carried by a plain CSV export and must be handled through a separate route. Confirm lookup IDs still resolve by following several foreign keys from the child table to the parent and checking that each returns the expected record. Sign-off should sit with the data owner for each table, who can judge whether the values are correct, and with a second person who did not run the export, such as a database or IT lead, who confirms the counts and the checks were completed. Keep the count register, the sample checklists with reviewer initials, screenshots or exports of the test records, the export and import logs, and a dated record of the decision to retire the source. For internal review, store these with the migration project. For an external auditor or assessor, ask them in advance which evidence they expect, since requirements depend on your own regulatory obligations and the standards you are assessed against.

What to plan before the Access contract or license ends

Exporting is the last step of a longer plan. Before the Microsoft 365 subscription or perpetual license reaches its end date, confirm the dates, decide how long the old file must stay readable, and rehearse the export so that nothing is discovered late. The cards below cover the decisions that most often get skipped.

Confirm license end dates

Confirm with Microsoft which Access version, subscription or perpetual license you hold, and the end-of-support or end-of-subscription date that applies to it. Check whether your organization's agreement sets a different date from the public product lifecycle. Record the date in the project plan, because the export rehearsal and the cutover both depend on it. Ask your licensing contact to confirm in writing which rights continue after the end date, including read-only use of existing files.

Set the readable life of the old file

Decide how long the original .accdb file must remain openable after cutover, and who holds it. Auditors, legal holds and historical reports often need the original database, not just the exported data. Make sure whoever owns that archive also has an Access runtime or licensed copy that can open it. Store the file read-only, with a checksum and a dated copy of the source schema.

Plan retention of exports and attachments

Exports leave copies of personal and business data in CSV files, which are easy to forget. Attachments need their own plan, because Access attachments and OLE objects are not carried by a plain CSV export. Set a retention period for every export file and extracted attachment, and assign an owner for deletion. Check the rules that apply to your sector and your data residency commitments before you copy files to a new location.

Rehearse the export on a copy

Run the full export on a copy of the database, never on the live file. Compare row counts per table, check that multivalued fields are flattened as expected, and confirm that lookup columns contain the IDs you need. Time the rehearsal and note every manual step, so the production run is a repeat rather than a first attempt. Keep the rehearsal log as evidence for the migration record.

Decide the target platform early

Choose between Baserow, Grist and PostgreSQL with Mathesar before the export format is fixed, because each one imports data in a different way. Baserow offers an Airtable importer but no Access importer, so its CSV, Excel, XML and JSON import is the path to test. Mathesar imports CSV with several delimiter options. Confirm the chosen platform's import limits and field-type mapping with its maintainers or your own test before committing.

Agree who signs off the export

Name the business owner who confirms that the exported data is complete and correct, and the IT owner who keeps the source archive. Agree the acceptance criteria in writing before the production export, including which tables, queries and reports are in scope. Assign who can access the export files during the transition, and who revokes that access afterwards. A named sign-off avoids disputes about missing records once the old database is switched off.

Common questions about exporting data from Access

How much effort does exporting an Access database take?

The effort depends mostly on how many tables, queries and attachments the database holds, and on how many of its fields are multivalued, lookup or OLE objects. Access exports one object at a time, so a database with many tables means many separate exports, each needing a check that the column names, data types and record counts match the source. A small database with plain text and number fields is a short job. A long-running database with attachments, linked tables and years of lookup relationships takes much longer, because each of those features needs its own export path and its own verification. Ask any provider to break the effort down by table group, so you can see where the time goes before any work starts.

Can our team export the Access data without outside help?

Often yes for a small, simple database. Access can export each table as CSV or Excel, and the team can review the output in a spreadsheet. The risks appear with the features Access does not export cleanly: attachments and OLE objects are left out of standard exports, multivalued fields are flattened, and lookups come out as IDs rather than the displayed values. Someone must map each of those fields to a new structure and confirm that nothing was silently dropped. If the team has no one who knows the database's relationships and business rules, or if the data holds regulated records, outside help can reduce the chance of a gap that surfaces months later.

What do we need from the business owner and IT before an export?

The business owner needs to name which tables and records are still in use, which are archives, and who signs off that the migrated data is complete. IT needs to provide a target server or cloud account, access to the Access files and any shared network drive, and a decision on who holds the database credentials after the move. Both sides should agree on a cut-off date so that no one keeps editing the old file during the export. Confirm these inputs in the written scope, because a missing sign-off or an unclear cut-off is one of the most common reasons an export has to be repeated.

How are attachments and OLE objects handled during an Access export?

Standard Access exports do not carry attachments or OLE objects along with the table rows, so they need a separate extraction step. The usual approach is to pull each file out of the database, keep the original file names, and store a reference to it in the new system's record. Confirm with the provider how each attachment is linked back to its record, how the file count is reconciled against the source, and where the files will be stored. Ask for a sample of exported records with their files opened and checked, not just a count of rows.

What should a written quote for an Access export include?

A usable quote lists the scope in concrete terms: the number of tables, queries, forms and reports in the source file, the field types that need special handling, and the attachment volume. It should state the target system, the method used for each export and import, the verification steps and the sample checks, and the acceptance criteria the business owner will sign. It should also separate one-time work, such as the export and reconciliation, from recurring costs, such as hosting, support or upgrades. Ask for the assumptions in writing, including what happens if the scope changes during the work.

Does Access export multivalued fields and lookups correctly?

Access does not preserve these fields in a form a new database can use directly. Multivalued fields are flattened into a single text value, which can make the separator a problem if the source data contains the same character. Lookup fields export as the ID of the related record rather than the displayed value, so the related table must be exported and the IDs remapped. Engineers should check a sample of these fields in the exported file against the original Access view before accepting the data, and should record each mapping decision so the next person can understand it.

How do we confirm the export lost no data?

Confirm it by reconciling each table against the source: record counts, a checksum or hash of key columns where practical, and a set of spot checks on records chosen by the business owner. Compare totals in numeric fields and check that date and time values have not shifted. Keep the original Access file read-only and archived until the reconciliation report is signed. Ask the provider to show the reconciliation method in the written scope, along with who signs it off and how any difference is logged and resolved.

Does DeployOpen export Access databases for us?

DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with the scope, deliverables and timelines agreed in writing before work starts. A data export from Access would be scoped the same way, using the table, attachment and reconciliation details above. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the export method, the reconciliation evidence and the post-move support terms in that scope.

Where the exported data goes next

Baserow suits Access tables that behave like spreadsheets: linked tables, attachments, and grid views that people filter and sort. Its Airtable importer does not apply here, because it copies a base from a public Airtable share link and has no Access path. For an Access export, load the CSV or Excel files instead, which Baserow's pricing page lists among its import formats.

Plain columns: Text, number, date and single-select values usually arrive cleanly when each record is one row in the export.
Attachments: Attachment fields and OLE objects are left out of the export, so extract the files from Access separately and upload them to Baserow file fields.
Relationships: Link fields must be recreated after import, using the ID columns you exported to match records across tables.
Multivalued fields: Values flattened by the export need splitting back into link or multiple select fields.
Forms and reports: Rebuild them in Baserow's application builder, and plan a separate replacement for VBA macros.

Check with Baserow how its CSV and Excel import handles your field types and file sizes before you commit to a load.

How DeployOpen scopes and delivers an Access data export

DeployOpen treats the export from Access as a scoped piece of work with written deliverables, not a file copy. The engagement starts with an inventory of every table, query, attachment and relationship, and the export is planned so that nothing is lost before the target platform is chosen.

How we scope

Inventory every Access table, query, form and linked file before agreeing the export method
Record which fields are multivalued, lookups, OLE objects or attachments that need a separate route
Agree in writing which tables, views and record counts are in scope for the export
Confirm the target platform, whether Baserow or PostgreSQL with Mathesar, before export work starts

How we build

Export each table with a documented method and keep a reproducible script or procedure
Map lookup fields to their related keys and capture the join logic from each query
Extract attachments into a folder structure that links back to the records they belong to
Test each export against the source by comparing row counts, key values and sample records

How we hand over

Deliver a written export report listing each object, its method and any items left out
Document the field mapping, known gaps and the manual steps the client must still complete
Provide the validation checks and results so the client's own reviewers can repeat them
Walk the client's data owners through the reconciliation before the Access file is retired

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Ask any provider to confirm which export steps are covered by their written scope
Quotes follow from the written scope, so request one that itemizes each deliverable

How to export your data from Microsoft Access