Why You Can't Track Changes in FileMaker — and What That Costs You

If you have ever said “something changed and now it’s broken, but I don’t know what” about your FileMaker solution — you have encountered one of the platform’s most fundamental limitations. Not a bug. Not a misconfiguration. A structural property of how FileMaker stores everything you’ve ever built.

This post covers two problems that flow from the same root: FileMaker’s binary file format makes version control impossible, and as a direct consequence, it also makes parallel development impossible. Together they mean that your system’s history is invisible, your changes are irreversible without backups, and only one person can safely work on it at a time.

What is version control and why does every other software platform use it?

Version control is the practice of tracking every change to a codebase over time — who changed what, when, and why. It is not an advanced feature. It is baseline infrastructure for any professionally maintained software.

Tools like Git — the near-universal standard in software development — allow developers to record every change as a named, timestamped commit with a description. They can compare any two versions of a file, restore the system to any prior state, and work on separate features simultaneously without interfering with each other. If a change breaks something, the fix is straightforward: find the commit that introduced the problem and revert it.

This capability is so fundamental to modern software development that it is essentially taken for granted. Web applications, SQL databases, Python scripts, Excel macros hosted in SharePoint — all of these can be version-controlled. The files are text-based, and Git can read text.

FileMaker cannot be version-controlled, because FileMaker files are not text. They are binary.

Why is version control impossible in FileMaker?

Because a FileMaker solution is stored in a single proprietary binary file — .fmp12 — that cannot be read, compared, or merged by any external tool.

When you build a FileMaker solution, everything lives in that one file: your table definitions, your layouts, your scripts, your calculations, your privilege sets, your value lists. There is no separate “source code” folder. There are no plain text files. There is nothing Git can diff.

A moderator on FMSoup — the main FileMaker developer community — stated this plainly when asked about Git integration: “Short answer: no, unfortunately not. There is zero integration of the FileMaker IDE with Git.”¹

The only partial workaround is the Database Design Report (DDR): an XML export of your solution’s structure that FileMaker can generate on demand. Some developers store the DDR in Git as a record of state. But the DDR is read-only documentation — it cannot be used to regenerate a working solution, cannot be diffed in a meaningful way for complex changes, and is not the source file.²

Third-party tools have attempted to solve this. Devin.fm offers GitHub-style diff views for FileMaker scripts — showing you what changed between two snapshots. They are explicit about the limitation in their own documentation: “traditional merging isn’t currently possible.”³ These tools start at $6,000+ per year, require ongoing subscription, and solve a fraction of the version control problem — specifically the “view diffs” part, not the “restore previous state” or “merge parallel work” parts.

What does the absence of version control mean in practice?

It means that every change to your FileMaker solution is irreversible unless you have a backup from before the change was made — and that diagnosing problems requires memory rather than records.

Consider the scenarios that version control handles trivially in any other development environment:

“Something broke after last week’s changes — what changed?” In a version-controlled system, you look at the commit log, find the change, and read the description. In FileMaker, you ask whoever made the change, hope they remember, and if they don’t, you start comparing the current broken state against a backup from before. If your backups are daily, you may not be able to isolate the change more precisely than “sometime in the last week.”

“We need to undo this new feature — it’s causing problems.” In Git, you revert the commit. In FileMaker, you restore from a backup — which means you also lose every other change made since that backup was taken. There is no selective revert. The choice is between keeping everything or losing everything since the last backup.

“Who changed this script and why?” In any version-controlled system, git blame tells you exactly who touched each line and when. In FileMaker, the answer is: nobody knows, unless the developer left a comment. Many don’t.

For a business that has been running a FileMaker solution for five or ten years, this means the solution’s history is opaque. There is no audit trail of development decisions, no record of what was tried and abandoned, no way to understand why a particular calculation was written the way it was. That knowledge either lives in the developer’s memory or it is gone.

What does “no concurrent development” mean?

It means only one person can make changes to your FileMaker solution at a time — not just in practice, but architecturally. Two developers cannot work on the same solution simultaneously.

In mainstream software development, parallel work is table stakes. One developer works on a new reporting feature while another fixes a bug in the billing workflow. They each work on their own branch of the codebase. When both are done, the changes are merged. This is how every modern development team operates, because it is the only way to maintain velocity as complexity grows.

FileMaker has no branching. No merging. One maintenance session — the mode that allows structural changes to your solution — can be open at a time. A second developer who wants to make changes must wait for the first to finish and close the file.⁴

For a business with a single in-house developer, this is an annoyance rather than an acute problem: there is only one person anyway. But it becomes visible in two situations that are more common than they appear:

When you engage an external developer for a project. If your internal developer and an external consultant both need to work on the system — one handling day-to-day maintenance while the other builds a new module — they cannot do so simultaneously. Every hour the consultant works is an hour your internal developer cannot make changes, and vice versa. Projects that would take four weeks in parallel take eight weeks sequentially.

When your developer wants to experiment safely. In a normal development environment, a developer who wants to try a structural change creates a branch — an isolated copy of the codebase where the experiment can be made and tested without touching the production system. If the experiment fails, they discard the branch. In FileMaker, the only equivalent is duplicating the entire solution file. This is slow, creates synchronisation headaches, and is rarely done consistently — so experiments tend to happen directly in the production file, where failures are immediately consequential.

InterSoft Associates, a technology consulting firm, summarises this directly: the absence of parallel development “creates inefficiencies in the development process”⁵ — a diplomatic way of describing a constraint that most modern development teams simply could not operate under.

How do FileMaker shops try to work around these limitations?

They use a combination of discipline, third-party tools, and backup-based safety nets — none of which fully replaces what version control provides.

The most common approaches in the FileMaker community:

Regular, granular backups. If you cannot revert changes precisely, the next best thing is frequent backups that narrow the window of change. Some teams run hourly FileMaker Server backups precisely because they cannot roll back a bad script change any other way. This works as a safety net but not as a development workflow — it tells you what the system looked like at a point in time, not what changed or why.

DDR-to-Git workflows. Generating the Database Design Report and committing it to a Git repository after each significant change creates a rough audit trail. Tools exist to make DDR diffs more readable. This is better than nothing, but it is documentation of state rather than control of change — you can see what is different between two DDRs, but you cannot merge branches or restore from a DDR.

Development clones. Some developers maintain a separate “development” copy of the FileMaker file, make changes there, test them, and then manually replicate the changes in production. This is the FileMaker approximation of branching. It is fragile (the two files drift apart), slow (manual replication of every change), and breaks down entirely when data migration is involved.

Third-party deployment tools. Tools like OttoFMS and 360Deploy handle the file transfer between development and production environments. They make deployment more reliable but do not add version control or branching capabilities — they are deployment infrastructure, not source control.⁶

The FileMaker community has been building workarounds for this problem for more than a decade. The fact that community members still describe merge capability as “the #1 hurdle” suggests the workarounds are not solving the underlying problem.⁷

What does this mean for a business owner who isn’t a developer?

It means you have less visibility into your own system than you might assume — and less control over what happens when changes go wrong.

If your FileMaker developer makes a change this afternoon and it introduces a subtle bug that surfaces three weeks later, you have no practical way to find out what changed, when, or why — unless the developer remembers and tells you. If they have left by then, the answer may simply be unavailable.

This is not a hypothetical risk. It is a normal consequence of operating a business-critical system without change tracking. The businesses that manage it best are the ones that invest heavily in documentation culture (writing down every significant change), maintain rigorous backup schedules, and operate on the assumption that debugging will be harder and slower than it needs to be.

The businesses that struggle are those that treat FileMaker the way they treat a modern software platform — assuming the history of changes is preserved somewhere, that rolling back is possible, that two developers can work on it simultaneously. Those assumptions are wrong, and the gap between assumption and reality tends to surface at the worst possible moment.

Frequently asked questions

Is there any FileMaker plugin that adds real version control?

No plugin currently offers true version control with branching and merging for FileMaker. Devin.fm offers script diff views — useful for seeing what changed between two saved states, but not a substitute for Git-style branching, history, or rollback. The binary format is the fundamental barrier, and no plugin can change that.

Can I use FileMaker’s built-in audit logging to track changes?

FileMaker’s audit logging tracks data changes (which records were created, modified, or deleted) but does not track structural changes (which scripts were edited, which layouts were modified, which calculations were changed). The two types of change tracking are separate, and only data-level logging is built in.

How does this compare to running a SQL database?

A SQL database schema is defined in plain text — SQL statements. These can be stored in Git, diffed, branched, merged, and rolled back like any other code. Application code sitting on top of the database is likewise plain text. The entire technical stack is version-controllable as a matter of course, without any specialised tools.

Does FileMaker’s Data Migration Tool help with this?

The Data Migration Tool helps move data between FileMaker versions during upgrades — it does not address version control or concurrent development. It is a deployment aid, not a change management tool.

The honest summary

The absence of version control in FileMaker is not a minor inconvenience. It is a foundational gap that affects how safely changes can be made, how quickly problems can be diagnosed, how effectively multiple people can work on a system, and how much of your system’s history is preserved versus lost.

Every mainstream development platform — web frameworks, SQL databases, even low-code tools like Retool and Budibase — solves this problem as a matter of course. The files are text, Git is free, and change tracking comes with the territory. FileMaker’s binary format makes this impossible, and no third-party tool has fully bridged the gap.

For a business owner, the practical implication is simple: your FileMaker system is harder to change safely, harder to debug, and harder to maintain in parallel than it would be on any modern alternative. That cost is invisible until something goes wrong — and then it is very visible indeed.