← Bionic Forms

What a Microsoft Access export leaves behind

Every claim below is quoted from Microsoft's own documentation · checked 20 August 2026

If you are moving off Access, the export is the part everyone assumes is the easy bit. It is not that it fails — it is that it succeeds while quietly leaving several things behind, and Microsoft says exactly which.

This page is a companion to the same exercise done for Airtable, Notion, monday, Smartsheet and Quickbase. The pattern turns out to be identical across thirty years of database software: a flat file is a grid of text, and a grid of text has nowhere to put a file or the identity of a row in another table.

Your attachments do not come with you

“Graphical elements (such as logos, contents of OLE object fields, and attachments that are part of the source data) are not exported.”

That is the sentence to read twice. An Access database that has served a business for fifteen years is very often the only place a scanned contract, a signed delivery note or a photograph of a job lives. The export takes the row and leaves the file.

Relationships arrive as one half or the other, never both

A lookup field is how Access records that this order belongs to that customer. On export you choose, in effect, which half of that fact to keep. Exporting without formatting, Microsoft says “only the lookup ID values are exported” — you get 4172 with nothing to say who that is. Export with formatting and “the lookup values are exported” — you get the customer's name, with nothing to say which record it was.

One is unreadable, the other is unjoinable. Neither is the relationship, and getting both means exporting twice and matching them back together yourself.

Multi-value fields fare no better: “Fields that support multiple values are exported as a list of values separated by semicolons (;)”. Three linked records become one string with punctuation in it.

Every related table is a separate export

“When you export a form, report, or datasheet, only the main form, report, or datasheet is exported. You must repeat the export operation for each subform, subreport, and subdatasheet that you want to export.”

So a database with a dozen related tables is a dozen separate exports, each one landing as an island, with the job of reconnecting them left to you at exactly the moment you are trying to leave.

The logic does not survive at all

“The results of calculated fields are exported; the underlying expressions that perform the calculations are not.”

You keep the answers and lose the arithmetic. For a business whose Access file computes margins, lead times or renewal dates, the rules are the application — and they exist after the export only in whatever is left of the person who wrote them.

Microsoft adds that “when you export a form or report that contains a Microsoft Graph object, the graph object is not exported”.

And one that will catch somebody out

“Date values earlier than Jan 1, 1900 are not exported.”

Rare, silent, and permanent. If your data reaches back past 1900 — a property register, an archive, a family firm's own history — those dates are simply absent from the file, and nothing tells you at the time.

What to actually do

1. Get the attachments out separately, before anything else. They are the one thing the export cannot give you later, and the one thing that is genuinely irreplaceable.
2. Export lookups twice — once with formatting and once without — so you hold both the ID and the name and can rebuild the join.
3. Export every subdatasheet as its own file, and write down how they relate while you can still see it on screen.
4. Screenshot or copy out the expressions behind every calculated field before you close the database. Nothing in the export contains them.
5. Check your oldest dates if your data predates 1900.

Why we wrote this

We build Bionic Forms and we would like Access owners to consider it, so this is not neutral. What we can offer instead of neutrality is that the list above is Microsoft's, not ours, and that we will tell you where our own import helps and where it does not.

Where it helps: if your export kept a key column — and an Access export usually does, since CustomerID is exactly the shape Access encourages — bringing the files in reconnects them into real relationships and says in plain words what it did, keeping the original column so the step is reversible. If any row fails, nothing is written at all, and anything ambiguous stops and asks rather than guessing.

Where it does not: if you exported with formatting and now hold only the customer's name, no importer can safely rebuild that link, ours included. Two similar names or a renamed record would produce a wrong join that asserts something untrue in a place nobody checks. We decline rather than guess. And nothing we do recovers attachments the export never contained, or expressions Access did not write out.

Sourcing, plainly: everything quoted here comes from Microsoft's page on exporting Access data to Excel, checked on 20 August 2026. It covers the Excel path specifically; other export formats may differ and we have not verified them, so we have not written about them.

Being straight about where we are: Bionic Forms is pre-launch. There is no Windows desktop app yet and no iOS or Android app; the macOS and Linux desktop builds and the web app are what exist today, and we have no external customers to point at. The import behaviour described above is covered by our test suite, not by a case study.