How to export your data from FileMaker

Effort grows mainly with the structure of the solution, not only with its size. The main drivers are the number of tables, the relationships that link them, the container fields that hold files, and the scripts and layouts that depend on the data model. A solution with a few tables and simple links is mostly a data task. Each relationship has to be recreated in the target platform, and each container field needs its own extraction plan, so two solutions with the same table count can produce very different workloads. Record volume adds time to validation, but it usually matters less than structure. Before anyone exports, inventory tables, fields, relationships, containers and scripts. That inventory is the basis for any estimate you request.

Yes, for many solutions a trained FileMaker administrator can export tables to CSV or Excel from the application. The harder work begins after the files leave FileMaker. Someone has to confirm that field types, dates, number formats and multi-line text survived, rebuild relationships in the target, and prove that every record and attachment arrived intact. Teams with strong database knowledge but no migration experience often underestimate that validation step. An outside partner adds the most value when the solution is calculation-heavy, when many users depend on it, or when the internal team is committed to other work during the window. Whichever route you choose, ask how record counts will be reconciled per table and who signs off on each one.

Business owners name the process owners, confirm which tables and fields are still in use, and identify which scripts encode business rules that must survive the move. They also define acceptance criteria, such as the reports, lists and approvals users must still complete afterwards. IT owners provide the target environment. For Baserow, that means a Docker host, and Baserow recommends an external PostgreSQL database for production deployments. For Grist, it means a Docker host with persistent storage for the /persist volume. IT also covers identity integration, backups, network access and the decision on who holds administrator rights. Both groups should agree on how long old FileMaker files and containers are kept, because archive requests often arrive after the old system is switched off.

The calendar depends on the same drivers as effort, plus how quickly decisions are made and how many test cycles the business needs. The export step is often the shortest part. Validation, relationship rebuilds, user acceptance testing and training usually set the pace. Running the old and new systems in parallel extends the calendar, and so does a change of requirements mid-project. DeployOpen's engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask any partner to tie its timeline to named deliverables and to explain what happens if requirements change. Also check the end date and notice period in your FileMaker contract, because the export must finish before access ends.

Standard exports move data, not the solution logic. Layouts, scripts, value lists, custom functions, privilege sets and calculation definitions do not arrive as working objects in CSV or Excel output. They must be documented and rebuilt. Record their behavior before the move: what each script does, which layout each user group sees, and which calculations feed reports. Some of that logic can be recreated in the target. In Grist, formulas support full Python syntax, along with many Excel functions. In Baserow, automations and application builder pages cover parts of the workflow. Keep the original file, plus a written catalog of each layout, until the new system has passed acceptance testing.

Container fields usually need their own extraction step, because a table export may carry file references or names rather than the complete file contents. Ask your FileMaker administrator how each container is stored, how many files exist, and how much storage they occupy in total. Plan a folder structure that maps each file to its record identifier, so attachments can be linked back to the right record after import. Test a sample of files in both directions before the full run, and check the file size and storage settings of the self-hosted target before moving large media. Decide in advance whether old container files are migrated, archived or retired, since that decision changes both the workload and the storage you must provision.

Choose the format for each table based on what the target imports and what the table contains. Baserow's pricing page lists CSV, Excel, XML and JSON import. Grist supports import and export in Excel format and CSV. CSV is the most portable option for flat tables, but it does not carry field types, so confirm how each target interprets dates, numbers and empty values. XML and JSON suit nested or structured data, though they usually need mapping work. Test each format on a small sample table before running the full export. Also remember that Grist documents are based on SQLite, so the numeric and text data stays readable with standard tools if you need it later.

A written scope should name every table, container field and script in the inventory, and state which items move, which are rebuilt and which are retired. It should identify the target platform, the hosting model in your environment, the export formats and the reconciliation method, such as record counts per table and spot checks on attachments. Ask for named deliverables, acceptance criteria, cutover and rollback steps, training materials and handover documentation. Clarify who is responsible for backups before and after cutover, and who approves data retention decisions. DeployOpen plans, implements and supports self-hosted platforms in the client's own infrastructure, and it agrees scope, deliverables and timelines in writing before work starts. Ask for the exclusions too, because they show what the quote does not cover.