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

Neil Simpson8 March 2026Updated 16 May 2026

enterprisecase-studyai-engineering

Person working at a laptop with organized notes and planning documents

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.

This post is a long-form version of the audit we run on every FileMaker engagement. By the end you should be able to assess your own system honestly enough to know whether you need to migrate, optimise, or leave it alone.

Key takeaways

Most FileMaker migrations fail because they're rewrites. Rewrite teams see 50 layouts and miss the 1,200 scripts, the hidden auto-enter calculations, and the privilege-set cascades that encode the actual business.
Extraction comes first, migration comes second. Use AI to parse the DDR XML into a script catalogue, a business-rules document, a dependency graph, and a risk register before writing any new code.
Half the systems we audit shouldn't migrate at all. Under 200 scripts, no integration pressure, no compliance pressure — optimise in place. AI-assisted DDR analysis often buys years of runway in a week.
When migration is the answer, do it incrementally. Phase the work module by module with the FileMaker system running the whole time. A single Shipments-style module typically lands in ~8 weeks; big-bang cutovers routinely double the timeline and triple the budget.
Decision rule. Under 200 scripts → optimise. 200–600 → audit and refactor in place; partial migration only for the most-strained modules. 600+ scripts with growth gated on capabilities FileMaker can't add → extraction-first migration.

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. The story is always the same: a team that's good at building new things underestimated how much logic is hiding in the old thing.

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.

Let me show you what each of these actually looks like in the wild.

Auto-enter calculations

These are calculations attached to fields that run on insert, modification, or both. They're invisible to anyone who doesn't open the field definition. A typical example:

Case (
  not IsEmpty(Customer::DiscountTier) and Order::Status = "Confirmed";
    Round(Order::Subtotal * Customer::DiscountTier, 2);
  Order::Subtotal
)

That tiny snippet is a pricing rule, an order-state guard, and a rounding policy bundled together. It runs every time anyone touches the order record. Nobody told the rewrite team that the React UI needs to replicate it, because nobody can see it from the layout view.

A typical mid-sized FileMaker solution we audit has 200–800 of these scattered across the database.

Script triggers

A script trigger fires a script on a defined event — OnRecordCommit, OnLayoutEnter, OnObjectModify, and so on. They turn a passive form into an active state machine.

Script trigger: OnRecordCommit
Layout:        Shipment Detail
Script:        Validate_And_Sync_Shipment

That Validate_And_Sync_Shipment might call three other scripts, write to four related tables, and send an HTTP request. None of that is visible from looking at the form. A rewrite team that hand-rebuilds the form has no idea any of it should happen.

Custom functions

FileMaker's calculation engine supports user-defined functions (effectively pure functions in FileMaker's calculation language). Mature solutions often have hundreds, encoding logic like phone-number normalisation, tax calculation, working-day arithmetic, and proprietary business rules. They get called from everywhere — auto-enter calculations, validation, script logic, layout calculations.

A migration that doesn't first extract the contents of every custom function will end up reinventing them, badly, scattered across the new codebase.

Privilege sets

Most modern apps push authorisation into middleware or row-level security at the database layer. FileMaker bundles it into named privilege sets that combine record access, layout access, script-run permission, and value-list visibility — sometimes with calculations attached. A single privilege set might say "this user can edit shipment records, but only ones where Region = $UserRegion, and only via the Dispatch layout."

That's three different authorisation primitives at once. A rewrite that doesn't first catalogue every privilege set and every calculation inside one will produce a security model that's either too permissive or too restrictive — and quite likely both, in different places.

Relationship-driven value lists

FileMaker value lists can be driven by the contents of related records. A "Select Carrier" dropdown might be populated from Carriers filtered by Carrier::Region = Shipment::Region and Carrier::Active = 1 — so the valid options change depending on the record you're editing.

That's a business rule masquerading as a UI control. It needs to survive the migration.

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.

The extraction-first pipeline. Source-of-truth flows from the running FileMaker solution into four artefacts that drive every subsequent migration decision.

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. Any FileMaker developer with [Full Access] privileges can generate one from Tools → Database Design Report in a few minutes.

The output is a self-contained directory of HTML and XML files. The XML is the part that matters:

<FMPReport link="Summary.xml" type="Report">
  <File ... name="YourSolution.fmp12">
    <BaseTableCatalog ... />
    <RelationshipGraph ... />
    <ScriptCatalog>
      <Script id="123" name="Validate_And_Sync_Shipment">
        <StepList>
          <Step id="68" name="If" enable="True">
            <Calculation>...</Calculation>
          </Step>
          ...
        </StepList>
      </Script>
    </ScriptCatalog>
    <ValueListCatalog ... />
    <CustomFunctionCatalog ... />
    ...
  </File>
</FMPReport>

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, which scripts touch which tables
Risk assessment highlighting the scripts with the most complexity and cross-table side effects
A catalogue of every privilege set with the actual permissions it grants
Every custom function documented with its inputs, outputs, and call sites

We did this with our own system — Onroute.io. 154 tables. 1,235 scripts. Over a decade of business logic accumulated through dozens of feature releases. The AI-assisted extraction produced a complete architectural map in days that would have taken a team months to build manually.

The map then becomes the source of truth for every subsequent decision: what to migrate, what to leave, what to refactor in place.

What the Extraction Actually Produces

The output of a real extraction has four parts:

1. A complete script catalogue. Every script, with a plain-English summary, its inputs, its side effects (which tables it writes to, which external systems it calls), and its call sites (which other scripts invoke it, which layouts attach it as a trigger).

2. A business rules document. Every auto-enter calculation, validation rule, custom function, and significant If/Else If branch lifted out and grouped by domain concept — pricing, scheduling, access control, data integrity. This document is often the single most valuable artefact of the project. It's the first time the business has a written record of how its own system actually behaves.

3. A dependency graph. A directed graph of script → script, script → table, script → external-system calls. Used to identify which modules can be lifted out independently and which are entangled.

4. A risk register. Scripts ranked by complexity (line count, branching depth, cross-table side effects), with the riskiest 10–20 flagged for special attention during migration.

With these in hand, you can plan a migration like an engineering project rather than a leap of faith.

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. Typically 1–3 weeks of elapsed time depending on solution size.

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 and could plausibly run independently. A typical solution has 3–8 of these. Pick the one with the highest business value and the cleanest boundary to go first.

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 — usually via the FileMaker Data API on one side and a queue or webhook bridge on the other.

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 because the old system is still running. The cutover for any given module typically takes a week, not a quarter.

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

A Worked Example: The "Shipments" Module

To make this concrete, here's roughly what a single-module migration looks like for a logistics-style FileMaker system:

An 8-week timeline for migrating a single Shipments module. The old system runs the whole way through; rollback is available until week 10.

Week 1: DDR extraction. Identify the Shipments module — its tables, scripts, layouts, privilege sets, external integrations. Confirm boundaries: which scripts only touch shipment-related tables and which cross into customer or finance.
Week 2–3: Build the new shipment service in TypeScript with a Postgres schema modelled directly on the FileMaker tables. Re-implement the business rules from the extracted business-rules document — not by copying calculation syntax, but by translating the intent. Tests cover the calculation logic before any UI work begins.
Week 4: Build a synchronisation bridge. The FileMaker Data API exposes shipment records; a small worker watches for changes and mirrors them into Postgres. Reverse direction once the new system is the authoritative store.
Week 5–6: Build the new UI. Because the calculation logic is already in place and tested, UI work is fast.
Week 7: Parallel running. Operations team uses both systems for a week. Discrepancies surface and get fixed.
Week 8: Cutover. FileMaker shipment screens go read-only; new system becomes authoritative. Rollback path is available for another two weeks.

That's roughly two months for a single module. Big-bang rewrite quotes for the same scope routinely come in at six.

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."

Rough decision framework:

Under 200 scripts, no integration pressure, no compliance pressure → stay and optimise.
200–600 scripts, performance pain, growing integration needs → audit, refactor in place, plan a partial migration only for the most-strained modules.
600+ scripts, multiple stuck integrations, recruiting difficulty → extraction-first migration is probably worth it.
System is core operational infrastructure, business growth is gated on capabilities FileMaker can't add → migration is no longer optional, but it still benefits from being incremental rather than big-bang.

The Common Failure Modes

Three patterns of failure we see repeatedly:

1. The rewrite team that doesn't read the DDR. They look at the layouts, sketch a new architecture, and start building. Three months in, they hit the first cascade of script triggers they didn't know about. Avoidable.

2. The big-bang cutover. Multi-quarter rebuild, one cutover weekend, no rollback path. When it goes wrong — and it does, every time — the business goes back to FileMaker with the budget gone. Avoidable.

3. The wrong destination stack. A team rewrites in whatever framework the lead developer wanted to use, not whatever fits the actual problem. Six months later there's a new pile of accumulated decisions to unpick. Choose the stack to fit the data model and integration surface, not the engineer's CV.

Getting Started

If you're considering a migration, start with the data — not the destination. The first artefact you need is a complete map of what already exists.

Get a free AI assessment of your FileMaker system in under a minute, or contact us if you'd like to commission a full DDR analysis. The full analysis is delivered within 24 hours of receiving your DDR export — and frequently changes the migration conversation from speculation to engineering.

If you decide to stay on FileMaker, that's the right answer. If you decide to migrate, you'll be doing it with a real map in your hand instead of optimism.

← All posts