Locked In, Left Wondering: FileMaker's Proprietary Format and Apple's Silence

Two of the most serious risks in the FileMaker ecosystem rarely appear on the same invoice — but they operate as a pair. The first is structural: your entire business system is stored in a binary format that only one vendor can read. The second is strategic: that vendor is a subsidiary of Apple, which has never publicly acknowledged its existence. Together, they create a situation where leaving is expensive and staying is uncertain.

This post covers both, with specific data on what each risk actually costs and what your options look like.

What does FileMaker vendor lock-in actually mean?

FileMaker lock-in means your business logic — the scripts, layouts, relationships, calculations, and workflows built up over years — cannot be extracted from the platform. When you export data from FileMaker, you get the records. You do not get the system.

FileMaker stores everything in a proprietary binary file format with the .fmp12 extension. Unlike a SQL database (where the schema is readable text), or a web application (where the code lives in plain files), a FileMaker solution is an opaque binary. There is no way to open it in any other tool, diff it, version it, or read its logic outside of FileMaker itself. As migration consultancy Tadabase.io notes: “Most failed migrations try to recreate FileMaker layouts. The better approach is workflow-first” — meaning you don’t migrate from FileMaker, you rebuild for something else, which is a fundamentally different (and more expensive) undertaking.¹

This affects every FileMaker user without exception. It is not a configuration choice or a tier limitation — it is the architecture.

How much business logic is actually trapped?

The answer depends on how long you’ve been on the platform, and it’s almost always more than people expect.

Consider what accumulates in a typical FileMaker solution over five to ten years: hundreds of scripts encoding business rules, calculated fields that implement pricing or validation logic, layouts that represent months of UX iteration, relationship graphs connecting dozens of tables, and custom privilege sets defining who can see what. None of this is exportable. None of it transfers.

InterSoft Associates, a technology consulting firm, has documented the consequence directly: in a proprietary binary format, “the business logic — often representing years of accumulated development — cannot be extracted or ported.”² The practical implication is that any migration off FileMaker is not a technical conversion but a full rebuild. For a mid-complexity solution, that rebuild typically costs between €50,000 and €200,000 and takes six to eighteen months.

The lock-in also operates in a subtler way: it raises the perceived cost of leaving at every decision point. Each year you stay, the gap between “what the system does” and “what you’d have to rebuild” widens. This is not an accident of design. It is the economics of proprietary platforms.

Is there any way to version-control or document a FileMaker solution?

No — not in any meaningful sense, and this compounds the lock-in significantly.

Standard software development practice uses Git or similar tools to track changes, enable collaboration, and provide an audit trail of what changed and why. FileMaker’s binary format makes this impossible. You cannot diff two versions of an .fmp12 file, merge parallel development branches, or roll back to a previous state with any precision. As a moderator on FMSoup — the FileMaker developer community — stated plainly: “Short answer: no, unfortunately not. There is zero integration of the FileMaker IDE with Git.”³

The only partial workaround is exporting the Database Design Report (DDR) — an XML snapshot of your solution’s structure — and storing that in Git. But the DDR is read-only. It documents the solution; it cannot regenerate it. Meaning you have a record of what existed, but no way to restore it programmatically.

Third-party tools like Devin.fm have built GitHub-style diff views for FileMaker scripts. They acknowledge the limitation directly in their documentation: “traditional merging isn’t currently possible.”⁴ These tools start at $6,000+ per year — an additional cost on top of FileMaker licensing, for a partial solution to a problem that most modern databases don’t have at all.

The practical effect on lock-in: an undocumented, unversioned FileMaker solution is even harder to migrate, because nobody can fully account for what it does. Every hour of accumulated complexity is another hour of rebuild cost on the other side.

What is the risk that FileMaker gets discontinued?

This is the question that FileMaker developer communities have been wrestling with since 2019 — and the honest answer is: we don’t know, and neither does Claris.

Claris International is a wholly owned subsidiary of Apple. Apple has never mentioned FileMaker or Claris at WWDC, in earnings calls, in product announcements, or in any public strategic communication.⁵ The product has run profitably for 80+ consecutive quarters, which suggests Apple sees no reason to shut it down — but profitability and strategic importance are different things. Apple could divest or discontinue Claris with no warning, as it has done with other subsidiary products.

The anxiety is real enough that major Claris partners address it directly in their client-facing content. Soliant Consulting — one of the largest FileMaker consultancies in North America — published a post specifically titled “Is FileMaker Being Discontinued?” to answer the question they receive from anxious clients.⁶ The fact that a top-tier partner has to write this post at all is itself a signal.

Recent events have amplified the concern. The 2019 rebrand from “FileMaker Inc.” to “Claris International” was accompanied by an ambitious growth plan and the launch of Claris Pro — a new product direction that was subsequently abandoned.⁷ Claris Engage 2026, the annual developer conference, was cancelled. These aren’t conclusive evidence of platform decline, but they are the kinds of signals that rational business owners notice.

How does Apple’s ownership structure affect FileMaker’s roadmap?

Apple’s ownership means FileMaker’s roadmap is set inside a private company that reports to a parent organization for which this product is a rounding error in revenue terms.

Apple’s annual revenue exceeds $380 billion.⁸ Claris, by any public estimate, generates a fraction of a percent of that. This isn’t an argument that Apple will shut Claris down — it’s an argument that Claris’s strategic priorities, investment level, and long-term direction are invisible to the market in a way that no independent software company’s would be. There are no earnings calls, no investor days, no public product roadmaps.

Compare this to the transparency available with open-source alternatives (where the roadmap is public and contributors are distributed) or with modern SaaS platforms (where roadmaps are published, funding rounds are announced, and executive communication is regular). FileMaker businesses are making multi-year infrastructure decisions based on the assumption that a privately held Apple subsidiary will continue to exist and invest in its product — with essentially no public evidence either way.

What happens to your business if FileMaker is discontinued?

You would retain your data but lose your system — and the rebuild cost would fall entirely on you, under time pressure.

If Claris were to announce end-of-life for FileMaker (or simply stop issuing security updates), businesses would face a forced migration on an externally imposed timeline. They could export their data to CSV or Excel. The business logic, the scripts, the layouts, the calculated fields — none of it would transfer. They would need to rebuild from scratch, paying the same €50,000–€200,000+ in rebuild costs, but without the option of a phased, strategically timed transition.

FileMaker Server 21.x, released in 2024, introduced documented data loss bugs serious enough that Claris extended support for the older v20.x “until we have found a resolution for the data loss issue.”⁹ Multiple major FileMaker consultancies reverted client installations to the previous version. This isn’t a prediction of platform discontinuation — but it illustrates the operational reality of depending on a platform where critical decisions happen inside a closed organization with no public accountability.

What is the compounding effect of lock-in and platform uncertainty together?

Each risk amplifies the other. Lock-in makes platform uncertainty more dangerous; platform uncertainty makes lock-in more expensive.

If FileMaker were entirely open — if the business logic could be exported, versioned, and ported — platform uncertainty would be manageable. You could migrate incrementally, test alternatives in parallel, or rebuild at a pace that suits your business. The binary format eliminates this flexibility.

Conversely, if the platform were under independent, publicly accountable ownership with a published roadmap, lock-in would be less alarming. You’d have visibility into the investment horizon and could plan accordingly. Apple’s silence on Claris means you’re making that plan in the dark.

The result, as InterSoft Associates summarizes, is that businesses are caught “between modernization pressure and migration cost.”¹⁰ The longer they stay, the more complex the solution becomes and the higher the rebuild cost. But the longer they stay, the more they’re exposed to a discontinuation event they’d have no warning of and no quick response to.

Frequently asked questions

Can I export my FileMaker business logic to another database?

No. FileMaker’s export functions cover data (records) only. Scripts, layouts, calculated fields, relationships, and business rules are stored in the binary .fmp12 format and cannot be exported in any form that another platform can use. Any migration requires rebuilding the business logic from scratch.

How much would it cost to migrate off FileMaker today?

For a mid-complexity FileMaker solution, independent estimates put migration cost at €50,000–€200,000 depending on solution complexity, data volume, and the target platform. The cost driver is not data migration — it’s business logic reconstruction. This is also why delaying migration increases cost: complexity accumulates annually.

Has Apple ever publicly commented on FileMaker’s future?

Apple has not mentioned FileMaker or Claris in any public communications including WWDC, earnings calls, or investor materials. Claris operates as a fully private subsidiary. There is no public roadmap, no public revenue disclosure, and no formal commitment to any continuity timeline.

What should I do if I’m concerned about these risks?

The practical first step is a solution audit: documenting what your FileMaker system actually does at the business logic level, independent of the FileMaker interface. This documentation has value regardless of what you decide — it reduces bus-factor risk, helps onboard developers, and forms the basis of any future migration plan. The second step is modelling the actual cost of migration against the compounding cost of staying, using the full cost framework (licensing, developer premium, integration tax, opportunity cost) rather than the licensing number alone.

The honest summary

FileMaker’s proprietary binary format is not a minor inconvenience — it is a structural constraint that affects every business decision you make about the platform. You cannot freely evaluate alternatives, because the cost of switching is artificially high. You cannot build in the open, because the format is closed. And you cannot make a fully informed long-term bet on the platform, because the parent company that controls its destiny doesn’t discuss it publicly.

These two risks — lock-in and platform uncertainty — are the ones that compound most viciously with time. Every year of continued development on an undocumented, unversioned FileMaker solution is another year of distance between where you are and where you could be.

The businesses that manage this well are the ones that name these risks explicitly, put a number on them, and make a deliberate choice — rather than defaulting to inertia because migration feels expensive. It may well be expensive. But inertia has a cost too, and unlike migration, it’s recurring.