How to inventory an existing FileMaker solution

You've just inherited a FileMaker system nobody fully understands anymore. The original developer left five years ago, the file is called "Orders_FINAL_v3.fmp12," there are 40 scripts with names like "Script 2 copy," and every attempt to change something breaks a report that finance depends on. Before you can modernize it, connect it to another system, or even safely ask a developer for a quote, you need to know what's actually in there.

This article walks through exactly how to inventory an existing FileMaker solution — what to catalog, which tools to use, and how to turn what you find into a document you can actually act on.

Why do you need a formal inventory before touching anything?

Most FileMaker systems grow organically. A layout gets added for one customer request, a script gets duplicated instead of refactored because nobody had time to do it properly, and a plug-in gets installed to solve one specific problem in 2016 and never gets removed.

Ten years later you have a system that runs the business but that no single person — including the person who built it — can fully explain from memory. That's not a criticism of the original developer; it's simply what happens to any long-lived line-of-business application.

An inventory matters because:

• You can't estimate modernization work you can't see. A developer quoting a migration or rebuild without an inventory is guessing.
• Hidden dependencies cause the worst outages. A script triggered by a server schedule that nobody remembers exists is exactly the kind of thing that silently breaks during a migration.
• Compliance and security reviews need it. If you handle customer data, you need to know exactly where it lives, who can see it, and how it leaves the system.
• It protects you from a single point of failure. If the one person who understands the system leaves, an inventory is what keeps the business running.

This inventory step is also the foundation for the broader process described in how to modernize a FileMaker system step by step — you genuinely cannot plan a safe modernization path without it.

What exactly should you inventory in a FileMaker solution?

Think of the inventory in five layers. Skipping any one of them is how projects get blindsided later.

1. Files, tables, and relationships

• List every .fmp12 file involved, including ones only opened occasionally (year-end reports, an old HR module, a separate invoicing file).
• Map every table and how many records it holds — a table with 3 records is probably a leftover test; a table with 2 million records is core business data.
• Document the relationship graph. In older solutions this can be a genuine spaghetti of self-joins and cross-file relationships built up over a decade.

2. Layouts and the interfaces people actually use

• Note every layout, but flag the ones that are actually used daily versus the ones nobody has opened in years.
• Identify layouts built for specific one-off requests ("the layout Sandra needs for the Q3 export") — these often carry business logic nowhere else is documented.

3. Scripts and automation

• List every script, what triggers it (a button, a script trigger, a server schedule, a plug-in callback), and what it actually does in plain language.
• Pay special attention to server-side schedules and OnTimer/OnIdle triggers — these run without a user present and are the most commonly forgotten pieces of an inventory.
• Flag scripts that call external tools: shell scripts, AppleScript, Insert from URL, or plug-ins.

4. Integrations and data flowing in or out

• Every API connection, ODBC/JDBC link, email-sending step, webhook, and scheduled export needs to be documented — including where the data goes and who else depends on it.
• A concrete example: a nightly script exports a CSV to a shared drive that an outside accountant picks up manually every Monday. Nothing in FileMaker itself will tell you that — you find it by asking people, not just reading scripts.
• Third-party plug-ins (this is where something like FMBetterForms typically shows up — used to render richer web forms or PDF-style layouts) need their license status, version, and platform compatibility checked. A plug-in with no active vendor support is a real modernization risk.

5. AI and "smart" add-ons already in the system

• Some FileMaker solutions have already had AI features bolted on — anything from an OpenAI API call inside a script to a tool like Klai used to add conversational or AI-assisted layers on top of FileMaker.
• Document exactly what data these integrations send outside the FileMaker file, since this is often overlooked in security and compliance reviews but matters enormously once you start asking "where does our customer data actually go?"

What tools actually help you do this inventory?

You don't need to do this entirely by eye.

• The Database Design Report (DDR): built into FileMaker Pro, this exports a full XML (or HTML) report of every table, field, layout, script, and relationship in your solution. It's the single best starting point — run it before you do anything else.
• FileMaker's built-in Script Workspace search: lets you search across all scripts for a specific field, table, or plug-in function name, which is invaluable for tracing dependencies.
• Server-side logs: check FileMaker Server's Statistics and Event logs for scheduled scripts, ODBC connections, and API calls that don't show up in the file itself.
• Manual interviews: no tool replaces a 30-minute conversation with the person who uses the invoicing layout every day. They will tell you about the CSV export to the accountant that no script comment ever mentioned.

How do you turn all of this into a usable document?

A pile of DDR output is not an inventory — it's raw material. Turn it into something a decision-maker or a new developer can actually use:

1. Start with a one-page system map. Boxes for each file/module, arrows for data flow, and a short note on what each box does in plain business language.
2. Build a table of scripts with columns: script name, trigger, purpose, last modified, risk level (does it touch financial data, does it call an external system).
3. Build a table of integrations with columns: system name, direction (in/out), method (API, ODBC, CSV, email), frequency, and owner (who would notice if it broke).
4. Flag "unknowns" explicitly. If you find a script or field nobody can explain, write it down as unknown rather than guessing or deleting it. Unknowns are exactly what a modernization plan needs to investigate first.
5. Rank everything by business criticality, not by technical complexity. A simple script that generates the daily shipping manifest matters more than an elegant but rarely-used reporting layout.

What are the most common mistakes when inventorying a legacy FileMaker system?

• Only reading the code, never talking to the users. The DDR shows you what exists, not what actually matters day-to-day.
• Ignoring server schedules and background triggers because they're invisible unless you go looking for them specifically.
• Treating plug-ins as fixed infrastructure. Every plug-in needs its licensing, vendor support status, and 64-bit/Apple Silicon compatibility checked — several once-common FileMaker plug-ins have quietly stopped being maintained over the years.
• Skipping the AI layer. If a script quietly calls an external AI API, that's a data-handling and cost line item someone needs to own.
• Doing it once and filing it away. An inventory that isn't updated after every project becomes outdated within a year in an actively used system.

FAQ: inventorying a FileMaker solution

How long does a full inventory usually take? For a small solution (a handful of tables, under 50 scripts) budget 2-3 days. For a large, multi-file solution built over a decade, it can realistically take two to three weeks, mostly because of the interviews and dependency-tracing, not the DDR export itself.

Do I need a FileMaker developer to do this, or can an IT manager do it? An IT manager or technically-minded business owner can absolutely run the DDR and build the system map. Interpreting complex scripts, relationship graphs, and plug-in dependencies correctly usually benefits from someone with hands-on FileMaker development experience, especially to spot risk, not just list facts.

Should I inventory before or after deciding to modernize? Always before. You cannot responsibly decide between a phased modernization, a full rebuild, or adding an integration layer until you know exactly what the current system does and depends on.

What if the inventory reveals things that scare me? That's normal, and it's the point. Finding an unmaintained plug-in, an undocumented nightly export, or a critical script with no error handling is exactly why you inventory before you touch anything — it turns invisible risk into a manageable, prioritized list.

Checklist: is your FileMaker inventory actually complete?

• Every .fmp12 file listed, including rarely-opened ones
• Full DDR exported and archived with a date
• Every table's record count and purpose documented
• Every script's trigger and purpose documented in plain language
• Server-side schedules and OnTimer/OnIdle triggers checked
• Every plug-in listed with license and support status
• Every external integration mapped (API, ODBC, CSV, email)
• Any AI/automation add-ons and what data they send externally
• Key users interviewed, not just the code reviewed
• Everything ranked by business criticality, not technical complexity

If your inventory surfaces more risk and complexity than you expected, that's a normal outcome, not a failure — it just means the next step deserves proper planning rather than guesswork. Loggix can help turn that inventory into a concrete modernization roadmap, whether that means building a custom FileMaker solution around what still works well, connecting the system to other business tools through API integrations, adding AI capabilities where they genuinely save time, or simply sitting down together to map out the safest next step for your specific system.