FileMaker Solution Assessment
Describe your FileMaker setup. Our AI will analyse the architecture and deliver tailored recommendations — in under a minute.
Solution Basics
How to audit a FileMaker system
What to look at before you decide between staying, optimising, or migrating
The wizard above produces a tailored assessment in under a minute. This guide explains what we look atwhen we run a manual audit — so you can pressure-test the wizard's output, or do a rough audit yourself before committing to anything.
The honest answer for most FileMaker systems is not the dramatic one. Migration gets the airtime, but roughly half the solutions we look at are best served by staying on the platform and tightening what already exists. The job of the audit is to tell you which group you're in — before you commit a budget either way. For the deeper methodology behind this approach, see the extraction-first migration guide.
1. Size and shape
Start with raw counts: number of tables, scripts, layouts, custom functions, value lists, and privilege sets. These come straight off the Database Design Report (DDR) XML — any FileMaker developer with access can generate one in a few minutes.
Rough thresholds we use: under 50 scripts is small and almost always best optimised in place; 50–200 is mid-sized and depends entirely on business pressure; 200+ scripts means the system has become operational infrastructure and deserves a serious conversation about modularisation or migration.
Onroute.io — the platform we built N90's practice from — peaked at 1,235 scripts and 154 tables before we modernised it. Solutions at that scale don't fit in anyone's head anymore; the audit becomes a tool for the team that already lost track.
2. Hidden business logic
The danger zones in a FileMaker system are the places business rules hide outside the scripts. Specifically:
- Auto-enter calculations that silently enforce rules on data entry — almost never documented.
- Script triggers on layouts and records that cascade behaviour the user never sees attached to a button.
- Validation calculations that block saves under conditions the team has forgotten about.
- Privilege setsthat drive what records exist and what scripts run depending on who's logged in.
- Relationship-driven value lists that change valid input depending on context.
Any honest audit catalogues every one of these. AI-assisted DDR parsing is the only practical way to do that in a reasonable timeframe — manually it's a multi-week archaeology project.
3. Performance and architecture risks
Long-running scripts, deep relationship traversal, unsplittable monolithic scripts, and scripts-that-call-scripts-that-call-scripts are the patterns that make a FileMaker system slow over time and fragile to change. Performance pain is rarely about the platform — it's about accumulated structural debt.
An audit identifies the top 10–20 highest-complexity scripts (by line count, branch count, and cross-script call depth) and flags them for refactor. Often a week of targeted refactoring on those alone buys years of additional runway.
4. Security and access posture
Privilege sets are where most FileMaker security mistakes live. Common findings: shared admin accounts, full-access privilege sets handed to operational staff, no separation between read and write, scripts running with elevated privileges in ways no-one remembers configuring.
An audit examines every privilege set, every "Run script with full access privileges" instance, every external-access route (Data API, ODBC, XML/PHP publishing), and produces a remediation list ranked by risk.
5. Migration readiness — only if it's the right answer
If the audit points toward migration, the next question is readiness, not destination stack. Readiness has three components: boundary clarity (can you identify modules that could leave first?), data quality (will the data export cleanly or does it need cleansing?), and change appetite (will users tolerate a phased cutover?).
Migrations that fail almost always fail on one of those three, not on the choice of new platform. A good audit grades your readiness honestly before anyone draws a target architecture.
What happens after the assessment
The wizard's output is meant to be the start of a real conversation, not the end. If the summary lands and you want to go deeper, the typical next step is a paid DDR analysis: you send us your DDR XML export, we parse it with our AI toolkit, and within 24 hours you have a complete architectural map — every script documented, every dependency traced, every business rule extracted. From there, the decision between stay-and-optimise and migrate becomes evidence-based, not stress-based.
FAQ
Common questions about the assessment
What does the assessment actually do?
You answer a short set of structured questions — solution size, age, team setup, current pain points, business context — and our AI generates a tailored written assessment with three things: a realistic picture of the technical situation, the options open to you (stay-and-optimise, refactor, partial migration, full migration), and the first three concrete steps for whichever path makes the most sense.
How accurate can this be without seeing our database?
The wizard gives you a directional read, not a forensic audit. For a precise picture we need your DDR XML export, which lets us parse every script, field, relationship, and privilege set. The wizard is designed as the first conversation, not the last one — most clients use it to decide whether a deeper paid assessment is worth commissioning.
Will you push us to migrate?
No. The assessment frequently recommends staying on FileMaker and optimising — particularly for solutions under 200 scripts where the platform is still a great fit. Migration is one option among several, and the wrong one for a lot of working systems.
Is the assessment confidential?
Yes. The questions you answer are processed only to generate your assessment; nothing is shared, sold, or used to train models. If you want to delete the record, contact us and we'll remove it.
What's the difference between this and a paid DDR analysis?
This wizard works from your verbal description of the system in 4 questions. A paid DDR analysis works from your DDR XML export and produces a complete architectural map: every script, every dependency, every privilege set, every business rule embedded in calculations. The wizard is for orientation; the DDR analysis is the foundation for an actual project plan.