Migrate from FileMaker to Baserow

How a FileMaker to Baserow migration works in practice

A FileMaker migration to Baserow usually starts when a renewal, a licensing change or a data residency question forces a decision on the existing solution. In practice, the data moves table by table, while layouts, scripts and access logic are rebuilt in Baserow's application builder and automations. The records are the easy part. The screens, the business rules and the permissions are where the effort sits, so the plan should treat them as separate work from the export. The work is normally done by the organization's own database owners, who know the FileMaker solution's tables, users and reporting needs, together with an implementation partner who handles the target platform, hosting and the rebuild. Baserow is open core: all non-premium and non-enterprise features are licensed under the MIT License, which allows commercial and private use. Premium and enterprise features fall outside that grant, so the team should list which features the rebuilt solution needs, such as single sign-on, and confirm their license type before committing. Baserow's self-hosted license documentation explains the Premium, Advanced and Enterprise options. For effort and risk, the honest answer is that the cost depends on how many layouts and scripts the solution contains, how many container fields hold files and how much business logic lives in calculations. Ask for a written inventory of each table, relationship, script and layout before agreeing a scope, and run a test import of one table to check field types and attachments early. Baserow's Airtable importer is not a FileMaker tool, so FileMaker exports will need their own preparation. Confirm the import path and the handling of each field type with Baserow's current documentation before the contract ends.

Which FileMaker capabilities map to Baserow and which need rework

This table compares common FileMaker capabilities with their Baserow equivalents and marks each row as clean, needs rework or gap. Read the migration note first, since it tells you how much rebuilding each feature will need. Most data structures move cleanly, while calculation-heavy scripts and custom layouts are where most of the effort sits.

FileMaker capability	Baserow equivalent	Migration note
Tables and fields	Tables with grid views, typed fields, filters and sorts	Clean: Baserow's importer copies tables, field types and grid views from a public Airtable share link. For FileMaker, export each table to CSV or Excel and recreate field types manually where the export loses them.
Relationships between tables	Link to table fields between tables	Needs rework: relationship links must be recreated by hand after import, and lookup or rollup fields need to be rebuilt as formulas or lookups. Confirm supported field behavior with Baserow.
Container fields (images, files)	File fields with attachments stored on the Baserow instance	Needs rework: FileMaker container contents do not export as a standard column. Plan a separate extraction step and confirm bulk upload behavior with Baserow before you commit.
Layouts and forms	Application builder pages and forms	Needs rework: custom FileMaker layouts must be redesigned in the application builder. Plan this as new design work, not a copy.
Scripts and calculations	Automations, formula fields and filters	Needs rework: calculation-heavy script logic does not translate line by line. Map each script to a trigger and action, and move complex calculations into formula fields where they fit.
User accounts and access privileges	Role-based permissions on Advanced plans and SSO on Advanced and Enterprise	Gap to confirm: FileMaker privilege sets must be remapped to Baserow roles. Confirm that role-based permissions and audit logs fit your required access model before you commit to a license type.
Reports and dashboards	Dashboards and grid view exports	Needs rework: rebuild FileMaker reports as views or dashboards. Confirm the dashboard feature set in your chosen Baserow edition.
Imports and exports	CSV, Excel, XML and JSON import, with CSV and Excel export from views	Clean: data moves as flat files. Layout, script and formatting data stay behind, as noted in the FileMaker export planning guide.

What data and integrations move, and what must be rebuilt

A FileMaker migration splits into separate workstreams: table data, container contents, relationships, access, imports and the logic that talks to other systems. Each one has its own export path and its own rebuild effort, so plan them as distinct tasks rather than a single data copy.

Table data exported one table at a time

Export each FileMaker table to CSV or Excel, starting with the tables that other tables depend on. Each export carries field values but not layouts, scripts, value lists or formatting, so the export is only the data layer. Check record counts, date and time formats, number precision and multi-line text against the source after each import, because these are where silent differences usually appear.

Container fields as a separate workstream

Images, PDFs and other files stored in FileMaker container fields do not travel with a standard table export in the same way as text. Extract them as files, map each file back to its record ID, and then attach them to the matching Baserow file fields. Confirm with your FileMaker export method how file names and record links are preserved, and budget a reconciliation check that counts files against records.

Relationships recreated as link fields

FileMaker relationships between table occurrences, often built on match fields, need to become Baserow link-to-table fields. The export contains the key values but not the relationship definitions, so the foreign keys must be resolved into link fields by a mapping step. Document each relationship, including one-to-many and many-to-many cases, and test lookups before users rely on them.

User accounts and single sign-on

FileMaker accounts and privilege sets do not transfer to Baserow. Map each privilege set to Baserow workspace roles and table permissions, then decide whether users sign in with local accounts or through your identity provider. Single sign-on with SAML or OpenID Connect requires the Advanced or Enterprise plan with an activated license, so confirm that licensing before planning the identity integration.

Imports through CSV, Excel, XML and JSON

Baserow's import options cover CSV, Excel, XML and JSON files, which is the path for FileMaker exports. The Airtable importer is not relevant here: it copies from an Airtable public share link and does not apply to FileMaker sources. Check that the import preserves field types, such as date, single select and link fields, and keep a dated log of each table you load.

External integrations rebuilt through the API

Any system that reads from or writes to the FileMaker database, such as ODBC or XML connections, web forms or scheduled scripts, must be rebuilt against the Baserow API, which is headless and API first. Inventory every external connection before cutover, assign an owner to each, and test authentication and rate behavior in a staging instance. Scripts inside FileMaker belong to a separate rebuild using Baserow automations.

Migration sequence from inventory to decommission

This sequence moves a FileMaker solution to Baserow in controlled stages, so each table, layout and script is accounted for before users depend on the new system. Each step produces a written artifact that the next step relies on, and the final step closes FileMaker only after its data is archived.

Inventory tables, fields, scripts and layouts
Start by listing every table, field, relationship, script, layout, value list and scheduled task in the FileMaker file, with the team that uses each one. The owner of the solution and a developer who knows the file should review the list together, marking which items hold data, which drive business rules and which are unused. The output is an inventory register, a single document that maps each FileMaker object to its planned Baserow equivalent or to a decision to retire it. The step is complete when the business owner has signed the register and every script has a named replacement or a documented reason to drop it.
Run a pilot with one table and one layout
Choose one table with a clear owner, a manageable number of fields and one layout that users rely on daily. Export that table, import it into a Baserow workspace, and rebuild the layout in the application builder with the same fields and filters. Ask a small group of users to complete their normal tasks in the pilot and record every gap they find. The output is a reconciled pilot dataset and a pilot findings log that lists each mismatch and how it was resolved, including any field types that did not carry over cleanly.
Export and import all tables with reconciliation
Export each remaining table from FileMaker to CSV or Excel, handling container fields as a separate attachment task, and import each file into Baserow in the dependency order defined in the inventory. After each import, compare row counts and spot-check key fields against the source file, then rebuild the relationships between linked tables. The output is a reconciliation sheet that records, for each table, the source count, the imported count, the checks performed and the person who approved the result. Do not treat the migration as complete until every table has a signed line on that sheet.
Rebuild automations and run users in parallel
Replace each FileMaker script that was approved for migration with a Baserow automation or application builder action, and test each one against sample records. Ask users to enter live work in both systems for an agreed period, comparing outputs at the end of each day or batch. Log every discrepancy, its cause and its fix. The output is a signed-off parallel-run log that shows which differences were resolved, which were accepted by the business owner and which remain open. Cutover should not be scheduled until this log has no unresolved items that affect records or reporting.
Cut over during a freeze window
Announce a freeze window in which no one edits records in FileMaker. Run a final export of every table, repeat the row-count and field checks from the reconciliation sheet, and confirm that the final import matches. Then point users to Baserow, update user access in the instance, and confirm that single sign-on or account setup works for each role. The output is a cutover record showing the final counts, the time the freeze began and ended, and the sign-off from the business owner. Keep the FileMaker file read-only from this point until decommission.
Decommission FileMaker with archived exports
After the agreed period of stable operation, create a full FileMaker backup and store it with the final table exports, the inventory register, the reconciliation sheet and the parallel-run log in a retained archive. Confirm with your legal, records and compliance teams how long these archives must be kept, and check that the archive is readable in a format your team can still open. Then cancel or let lapse the FileMaker licenses according to your contract terms. The output is an archived FileMaker backup and a decommission record that names who approved closure and where the archive is held.

Running FileMaker and Baserow in parallel without split records

Assign a single system of record to every table before any user touches the parallel run. Pick one owner per table, not per user: the table where the most records are created or changed is usually the best candidate to move first. Write the decision down as a short register listing each table, its owner system, the import date and the person accountable for it. Tables that feed scripts, portals or reports in FileMaker should move only after the dependent screens have been rebuilt, otherwise a user may update Baserow while the FileMaker script still expects the old values. Relationships between tables also need an owner: if a child table is authoritative in Baserow but its parent stays in FileMaker, the link values must be re-synced on a fixed schedule and tested before the pilot begins.

Two users editing the same record in both systems is the most common source of split records. Prevent it by making the non-owning system read-only for each table, using FileMaker privilege sets for the legacy side and Baserow's role-based permissions for the new side. Where a table must stay writable in both places for a period, agree on a key that never changes, such as an existing record ID carried into a Baserow field, and run a reconciliation query that flags duplicates or conflicting values. Ask the team who holds the sync script and who decides when a conflict is resolved. The reconciliation should run daily during the pilot, and its output should go to the table owner, not to a shared inbox.

Plan the cutover window as a sequence of reversible steps, with a freeze on the legacy table as the final action. Confirm the Baserow hosting decision before the pilot: the baserow/baserow Docker image runs all services in one container with an internal PostgreSQL and Redis by default, while Baserow highly recommends an external PostgreSQL for production, and Docker Compose or Kubernetes with Helm are documented for larger deployments (Baserow Docker installation documentation). Confirm backup and restore for the external database, the attachment storage path and the upgrade procedure before any users depend on the instance. Set the cutover date only after a full export and row-count comparison per table passes, and keep the FileMaker files available read-only until users have worked in Baserow for a full business cycle.

What drives cost and duration in this migration

This table lists the main drivers that raise or lower the cost and effort of moving a FileMaker solution to Baserow, with a way to keep each one down and what to request in a written quote. Use it to scope the work before comparing quotes, since the same drivers appear on every line of a proposal.

Driver	Why it moves cost or effort	How to keep it down
Number of tables and relationships	Each table needs a Baserow table, field mapping and checks, and each FileMaker relationship must be recreated as a link field, so cost rises with table count and link density.	Inventory tables and relationships first, retire unused tables, and migrate in waves by business process.
Layouts and screens	FileMaker layouts are rebuilt in the Baserow application builder, so every screen, portal and printed view is a separate build and test item.	Keep the first release to core screens and move reports or rarely used layouts to a later phase.
Scripts and calculation logic	Scripts become Baserow automations or application logic, and custom calculations, global fields and looping logic often need redesign rather than copying.	Catalog every script by business purpose, drop dead scripts, and document expected outputs with sample records.
Container fields and attachments	Attachment volume and file types affect export time, storage sizing and checks that each file reached the right row. Container fields do not map one to one.	Measure total container size per table, decide which files to keep, and agree a validation sample with the business owner.
Integrations and data feeds	Each external system, ODBC connection, import or web service call needs a new connector, credentials and testing against Baserow's API.	List every integration with its owner and direction, and mark which ones are still needed after cutover.
User count and license type	Baserow's self-hosted Premium, Advanced and Enterprise license types differ in how seats or paid access are counted, and SSO and role-based permissions depend on the plan chosen.	Confirm user counts by role, decide which features need a paid license, and document the license type before the build starts.
Hosting and PostgreSQL operations	An external PostgreSQL is highly recommended for production, so backups, patching, monitoring and capacity planning are added to the run cost.	Choose a managed or existing PostgreSQL service where policy allows, and agree who owns backup restores and upgrades.
Training and change management	Users who relied on FileMaker layouts need training on the Baserow interface, views and automations, and adoption effort grows with the number of user groups.	Train by role, provide short task guides, and run a parallel period for the most used screens.
Items to ask for in a written quote	Fixed-scope proposals should show each cost driver as a separate line.	Request a table inventory, layout and script counts, container size estimate, integration list, license type, hosting model, training plan, acceptance criteria and what support is included after go-live.

How the migration differs by solution size and starting point

A small solution usually has a handful of tables, one team of users and a few layouts that mostly act as data entry forms and simple lists. The migration here is short in sequence and light in governance, so the main work is careful data preparation and a quick, realistic user rollout. Start by exporting each table to CSV or Excel and checking field types, since FileMaker is loose about dates, numbers and text that look like numbers. Then import into Baserow and rebuild only the views people actually use.

Field types: Map FileMaker text, number, date and timestamp fields to the matching Baserow field types before importing, so sorts and filters keep working.
Layouts: Replace list and form layouts with grid views and row forms rather than rebuilding every screen.
Scripts: Convert the few scripts that matter into Baserow automations and document the rest as retired.
User adoption: A single team can be trained in one session, but the team still needs a clear cutover date and a fallback copy of the FileMaker file.
Access: Confirm which Baserow plan provides the role-based permissions the team needs before inviting users.

Confirm the current Baserow plan limits and the cutover approach with the vendor or in a test instance before committing.

What usually goes wrong in FileMaker to Baserow migrations

Most FileMaker to Baserow migrations stall for reasons that have little to do with the target platform. The risks below sit at different points in the sequence: export, relationship rebuild, script replacement, parallel run, reconciliation and training. Each one has a prevention step you can assign to a named owner before the first table is exported.

Container fields exported without references

FileMaker stores images, PDFs and other files in container fields, and a plain CSV export usually carries only file names or paths, not the binary content. When the export is planned table by table, the team may move records and forget the files they point to. Before exporting, inventory every container field, confirm whether each file is stored inside the database or as an external reference, and export the binaries to a separate folder with a key that maps each file back to its record ID. Then test a sample record in Baserow, where attachments are uploaded as files on the row, before you accept the table.

Relationship logic lost in translation

FileMaker relationships, table occurrences and lookups often encode business rules that never appear in a table list. A CSV export keeps the foreign key values but not the join definition, so related records can appear unlinked after import. Map each relationship on paper first: which table is the parent, which field holds the key, and whether the link is one to many or many to many. Recreate those as link-to-table fields in Baserow and check a handful of parent records against the FileMaker original before moving on to the next table.

Scripts underestimated during rebuild

FileMaker scripts often run validation, set fields, send emails, call other scripts and handle errors. Teams tend to count screens and tables but not scripts, so the rebuild estimate is too low. Inventory every script, label it by trigger (button, record commit, schedule or import), and mark which ones can become Baserow automations and which need an external workflow tool or a custom step. Scripts that depend on calculations across several tables should be specified in writing before anyone builds them.

Parallel run with two editable systems

If FileMaker stays live while Baserow is being tested, staff will keep entering records in both systems. The two copies then diverge, and the cutover becomes a manual merge. Choose a cutover date and state in writing which system is authoritative until then. Make FileMaker read only once the final export runs, and keep the export timestamp on record so anyone can see which data came from which run.

Row counts never reconciled

A table that imports with fewer rows than the source is hard to spot by eye. Duplicates, blank rows, filtered views and failed attachment uploads can all change the count without an error message. For each table, record the row count in FileMaker before export, the count in the CSV or Excel file, and the count in Baserow after import, then investigate any difference before continuing. Keep the reconciliation sheet as evidence for the project file, because auditors and business owners will ask for it later.

Training scoped to the screens only

Users are often trained on how to find a record in Baserow but not on the rules the old solution enforced silently, such as required fields, access by role or the way related records are created. Scope training from the process map, not from the new screens. Name which tasks each role performs, which automations now run in the background, and what users should do when a record looks wrong. Plan a short period after cutover for questions, and track them so the same gaps do not repeat.

Questions buyers ask before moving from FileMaker to Baserow

How much effort does a FileMaker to Baserow migration take?

Effort depends mostly on how much of the FileMaker solution is data and how much is logic. Tables, records and attachments move with export and import work. Layouts, scripts, calculation fields and custom access rules must be rebuilt by hand in Baserow's application builder and automations. The more scripts, portals and calculated fields the solution has, the more build and test work the migration carries. Ask for a written scope that lists each table, each script and each layout so the effort can be estimated from the inventory rather than from the file size.

How long does the migration run, and what sets the pace?

Duration is set by the inventory of the existing solution, not by the record count alone. The main pace setters are the number of tables and relationships to recreate, how many layouts and scripts need rebuilding, how many container field attachments must be moved, and how much user testing and training the team needs. Your contract end date also matters, so plan the export table by table before that date. Ask for a timeline in the written scope that ties each phase to a named deliverable.

What does the internal team need to provide?

The internal team provides knowledge the export cannot carry. That includes access to the FileMaker files and an admin login, a list of which scripts and layouts users rely on, a sample of real records for testing, decisions on access rules and field validation, and named business owners who can sign off each rebuilt workflow. Someone must also own the Baserow instance, its PostgreSQL database and its backups after go-live. Confirm these responsibilities in the written scope before work starts.

Can our own staff run the migration without an implementation partner?

Yes, a team with FileMaker and database skills can export tables and rebuild a simple solution in Baserow, provided it has time and someone who understands the data model. The work becomes harder when relationships are complex, container fields hold many files, or scripts carry business logic that users depend on. Baserow's Airtable importer does not apply here because FileMaker is not Airtable, so the exports and rebuild are manual. DeployOpen plans, implements and documents this kind of work under a written, fixed scope if you prefer outside help.

What does Baserow's open-source edition cover, and what needs a paid license?

Baserow is open core. All non-premium and non-enterprise features are under the MIT License, which allows commercial and private use. Premium and enterprise features sit outside that grant. Self-hosted Baserow offers three paid license types: Premium, with seats assigned manually; Advanced, which grants paid access to users on the instance; and Enterprise, priced through sales. An instance can use only one license type. Confirm with Baserow which features your solution needs, such as role-based access or audit logs, before you choose an edition.

Is single sign-on included, and how does it work with paid plans?

Baserow's single sign-on support covers SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect. According to Baserow's documentation, this feature is available on the Advanced and Enterprise plans with an activated license, so it should not be assumed for the open-source edition. If your identity provider policy requires SSO for every database user, confirm the license tier in writing and include the license cost in your cost comparison.

What happens to FileMaker scripts and layouts after the move?

Scripts and layouts do not transfer as code. Their behavior must be rebuilt. Simple data entry screens usually map to Baserow's application builder, and repetitive steps usually map to automations, but multi-step script logic, custom navigation and calculated behavior need design and testing. Keep a written list of every script, what it does and who uses it, then decide per item whether it becomes an automation, a builder page, a formula or a retired feature. Validate each replacement with the business owner before cutover.

What can we check ourselves before asking for a quote?

Start with an inventory: count tables, relationships, layouts, scripts, container fields and the users of each. Export one table to CSV or Excel and confirm that field types and relationships survive the trip. Note which records carry attachments and how large those files are. Then list which features users depend on daily. This inventory lets a provider write a fixed scope, and it lets you compare quotes on the same basis. Ask any provider to state its assumptions in writing.

What to confirm with Baserow and your own environment before you commit

Before you commit to a migration, confirm the current Baserow release and its changelog in writing with the project and in your own test environment. Baserow published 2.4.1 on October 13, 2026, following 2.4.0 on September 30, 2026, so check the Baserow GitHub releases page for anything newer and read the release notes for changes to the import tools, the application builder and the Docker images you plan to run. Treat the release you test as the release you deploy, and record the version in your project plan.

Next, get the feature matrix for the paid self-hosted license types in writing. Baserow offers Premium, Advanced and Enterprise, and an instance can run only one license type. Ask which features each type includes, especially role-based permissions, audit logs, single sign-on and any application builder capability your FileMaker access rules depend on. Then confirm how the license applies to your user count: whether Premium seats are assigned manually, whether Advanced grants access to every user on the instance, and what happens when headcount changes mid-term. Ask your vendor for the answer on a sample of your real users, not a generic count.

Finally, confirm the hosting and data handling in your own environment. Baserow's Docker image runs PostgreSQL and Redis internally by default, and Baserow highly recommends an external PostgreSQL for production, so decide who will run the database, its backups and its patching, and whether Redis will be a separate service. Test the export limits for container fields with your largest attachments, since FileMaker container contents may not arrive in the same form. Confirm where the instance, its backups and its attachments will physically sit, and document that residency decision with your data protection and compliance owners before the first production import.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a FileMaker to Baserow move, we start from a written scope that maps each FileMaker table, relationship, layout and script to a Baserow equivalent before any data is moved.

How we scope

Inventory every FileMaker table, relationship, container field, layout and script in the solution
Agree in writing which tables, users and workflows move in the first phase
Define which scripts become Baserow automations and which are retired or rebuilt
Confirm the target hosting, PostgreSQL setup, single sign-on and backup requirements before build

How we build

Stand up a self-hosted Baserow instance in your environment, using the Docker setup with an external PostgreSQL for production
Export each table from FileMaker to CSV or Excel and import it, checking field types and record counts
Move container field contents into Baserow file fields and test that attachments open correctly
Rebuild priority layouts in the application builder and test access rules per user role

How we hand over

Document the table map, field mapping, relationship rebuild and automation logic for your team
Deliver a reconciliation report comparing source and target records per table, reviewed with your staff
Run user training sessions tailored to the screens and workflows your staff actually use
Provide runbooks for backup, restore, upgrades and access administration

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainers can cover Baserow version upgrades and review of new releases before you apply them
Support can include hardening reviews and periodic security testing of the Baserow instance
Confirm response expectations and service levels in the written retainer before work starts