Ask the internet how to get your data out of FileMaker and you get the same four sentences every time: File → Export, choose CSV, back up first, check your field mappings. All true, all useless, because none of it warns you about the part that actually goes wrong — and Claris documents that part plainly.
“The tables list defaults to Current Layout (LayoutName) and displays only the visible fields on the current layout.”
Read that again, because it is the single most expensive default in the process. Whatever layout happened to be open when you chose Export decides which fields you are offered. A field that exists, holds data, and matters — but is not on that layout, or sits on a tab panel you were not looking at — is simply not in the list. Nothing warns you. The export succeeds. The file looks right. The field is gone.
This is the failure that survives a backup, because the backup is of the thing you still have. It shows up months later, on the other side, when someone asks where the notes field went.
The fix is one click and you have to know it exists: choose Current Table (TableName) instead, which Claris says “display[s] all field names from that table”. Do that for every table, every time, even when the layout looks complete.
For the two formats everybody actually uses, Claris’s own format table says the same thing about field names, and it is not what you would assume:
“You can specify” is not “we include”. A CSV can arrive as pure data with no header row at all, and a spreadsheet of forty unlabelled columns is a puzzle, not a migration. Three other formats behave differently — Claris says “Format retains field names” of dBASE (.dbf), FileMaker Pro (.fmp12) and Merge (.mer) — so if you want names guaranteed, that is where they are.
A FileMaker solution is worth something because of its relationship graph: this invoice belongs to that job, which belongs to that client. The export handles that by asking you to pick columns:
“Choose the name of the related table from the list in the upper-left corner of the dialog box, and then move the fields you want into the Field export order area.”
So a related record becomes extra columns on the parent row. That is a perfectly reasonable thing for an export to do, and it is also the moment the graph stops being a graph. Once the client’s name is a column on the invoice, nothing in the file says which client record it was. Two clients with the same name, or one renamed since, and the fact is no longer recoverable from the export — by us or by anyone.
The practical consequence: include the key field, not just the display field, in every export. If your relationship is built on a serial ID, put that ID in the Field export order even though it looks like noise. It is the only part of the relationship that survives the trip.
“You can’t export grouped summary values unless you sorted the data before you started the export process.”
A small one, but it fails in a confusing direction: the option is there, and it does nothing, and the reason is a sort order you set in a different dialog earlier.
We went looking for what happens to container fields — the contracts, signed delivery notes, site photographs and scanned drawings that a twenty-year-old FileMaker solution is very often the only copy of. Claris’s supported-formats table describes each export format and what it retains. Container contents are not mentioned for any of them.
We are stating that as an absence in the documentation, not as a proven limitation, and the distinction matters: we have not tested every export path ourselves, so we are not going to tell you your photographs will definitely not come out. What we will say is that a format described as carrying values and field names is not a format that carries files, that the same is documented outright for Access, and that this is the one part of your database that cannot be retyped if it turns out to be missing.
So do the containers first, separately, and confirm you have them — before you migrate anything, while you still have a working system to go back to.
Claris does say this about formatting generally: “Most file formats support data conversion only and do not import or export formatting such as font, size, style, and color.” Layouts, scripts, value lists and calculation definitions are not data; nothing in a CSV has anywhere to put them. If your solution’s value is in its scripts, understand up front that an export is a data export and the logic is a rebuild.
We build Bionic Forms and we would like FileMaker owners to consider it, so this is not neutral. What we can offer instead of neutrality is that every limitation above is Claris’s own documentation rather than our characterisation, and that we will say plainly where our own import helps and where it does not.
Where it helps: if you kept the key column, our loader rebuilds real relationships from it rather than leaving you with text. It reports exactly what it did for every row — resolved, empty, missing or ambiguous, kept apart rather than lumped together — and it keeps your original column so the step is reversible. It has been run in anger: it carried a real 62,691-note account export into a working app with the links intact.
Where it does not: if you exported the client’s name instead of the client’s ID, no importer can safely rebuild that link, ours included. Guessing would assert something untrue in a place nobody would ever check it, so an ambiguous match stops and asks instead. An unmapped column, two columns colliding onto one field, or a date that could be March or April all stop the load rather than resolve themselves quietly. And nothing we do recovers a container field the export never contained, or a script FileMaker did not write out.
Sourcing, plainly: everything quoted here comes from Claris’s own FileMaker Pro help — exporting data from FileMaker Pro and supported import/export file formats — checked on 20 August 2026. Where we describe container fields we are reporting what the documentation does not cover, and we say so rather than presenting it as a tested finding.
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 and by one real migration, not by a case study.
If you would rather not reassemble it by hand: tell us what your FileMaker solution does and we will build a working version and show you. No fee and no card — what we build fits the free plan, and we ask you to pay only once it is genuinely running your business.