Your FileMaker System Isn't the Problem — Your Migration Plan Is

Every week someone tells us they need to "get off FileMaker." They say it like it's an escape — as though the platform itself is the enemy.

It isn't. FileMaker did exactly what it was supposed to do: it let domain experts build functional business systems without waiting for IT. The real problem is that nobody planned for what happens when those systems grow into the operational backbone of a company.

The Migration Graveyard

Most FileMaker migration projects fail. Not spectacularly — they just slowly die. A consulting firm quotes six months and $300K. They start rebuilding screens in React. Three months in, they discover an auto-enter calculation that triggers a cascade through four related tables and three script triggers. Nobody documented it. The original developer left in 2019.

The timeline doubles. The budget triples. Eventually someone pulls the plug and the team goes back to FileMaker, now with less confidence and less budget than before.

We've seen this pattern at least a dozen times.

Why "Rewrite From Scratch" Fails

FileMaker systems encode years of business logic in places traditional developers don't think to look:

• Auto-enter calculations that enforce business rules silently
• Script triggers that cascade across layouts and tables
• Custom functions that implement domain logic in FileMaker's calculation engine
• Privilege sets that encode workflow permissions at the record level
• Value lists driven by relationships that define what data is valid where

A rewrite team sees 50 layouts and thinks "50 pages." They don't see the 1,200 scripts, the 400 custom functions, or the fact that the relationship graph is doing the work that a modern system would split across an API layer, a rules engine, and an auth system.

Extraction First, Migration Second

The approach that actually works is extraction-first. Before you write a single line of new code, you need a complete inventory of what the FileMaker system actually does.

This is where AI changes the game.

A DDR (Database Design Report) export gives you the full structural definition of a FileMaker system — every table, field, script, layout, and relationship in XML. Historically, reading a DDR was a manual, months-long archaeology project. Today, AI can parse it in minutes and produce:

• A complete entity-relationship map with actual business semantics, not just table names
• Script-by-script documentation explaining what each script does in plain English
• Business rule extraction from auto-enter calculations and validation rules
• Dependency graphs showing which scripts call which scripts, which fields trigger which calculations
• Risk assessment highlighting the scripts with the most complexity and cross-table side effects

We did this with our own system — Onroute.io. 154 tables. 1,235 scripts. The AI-assisted extraction produced a complete architectural map in days that would have taken a team months to build manually.

The Incremental Path

Once you have the extraction, migration becomes incremental instead of big-bang:

Phase 1: Document and map. AI parses the DDR. You get a complete picture of what exists. No surprises later.

Phase 2: Identify boundaries. Not every part of the system needs to migrate at once. Find the natural seams — the modules that have clear inputs and outputs.

Phase 3: Build alongside. New features go into the modern stack. Existing features stay in FileMaker until they're ready to move. Data synchronisation bridges the gap.

Phase 4: Migrate module by module. Each module moves when it's ready, not when a project plan says it should. Users switch over gradually. Rollback is always possible.

This approach takes longer on paper than a big-bang rewrite. In practice, it's faster — because it actually finishes.

When to Stay on FileMaker

Not every FileMaker system needs to migrate. If your system works, your users are happy, and your business requirements aren't outgrowing what FileMaker can do — optimise it instead of replacing it.

AI can help here too. DDR analysis reveals performance bottlenecks, identifies scripts that could be refactored, and surfaces security issues in privilege sets. Sometimes a week of AI-assisted optimisation buys you years of runway.

The honest answer is: migrate when FileMaker is genuinely limiting your business, not when someone tells you the platform is "legacy."

Getting Started

If you're considering a migration, start with the data — not the destination. Get a free AI assessment of your FileMaker system and find out what you're actually working with before you commit to a plan.