How to remove dependency on obsolete FileMaker plug-ins

You know the feeling: a critical FileMaker script calls a plug-in nobody remembers installing, the vendor's website hasn't been updated since 2016, and every time you plan a macOS or FileMaker version upgrade, someone on the team quietly asks, "wait, will the barcode plug-in still work?" That single dependency can hold an entire modernization project hostage. This article walks through how to find every plug-in dependency in your system, judge which ones are actually risky, and replace them with modern, supported alternatives — without a risky big-bang rewrite.

Why are FileMaker plug-ins a modernization risk in the first place?

Plug-ins extend FileMaker with capabilities the platform doesn't offer natively — think advanced PDF generation, barcode scanning, serial port communication, cryptography, or older HTTP/cURL libraries. For years, that was the only way to get certain jobs done, so companies bolted them on and moved on with their day.

The problem shows up later. A plug-in is usually a compiled binary built by a small vendor or a solo developer. If that vendor stops maintaining it, disappears, or simply doesn't recompile for the next macOS release or the next FileMaker/Claris Pro version, you're stuck. We've seen real cases where:

• A logistics company couldn't move to a new Mac Studio server because their label-printing plug-in was Intel-only and never got an Apple Silicon build.
• A wholesaler's invoice-PDF generation broke overnight after a FileMaker Server update, because the plug-in used a deprecated calling convention.
• A manufacturer discovered their encryption plug-in vendor had shut down entirely — meaning zero support, zero updates, and zero way to fix a bug that surfaced only under macOS Sonoma.

In every case, the plug-in itself wasn't the real problem. The real problem was that nobody had mapped where it was used, so removing or replacing it felt terrifying rather than routine.

How do you find every plug-in dependency hiding in your solution?

Before you can remove a dependency, you need a complete map of it. Skipping this step is the single biggest reason plug-in migrations go wrong — teams replace the obvious calls, ship it, and then a report that runs once a quarter breaks because nobody knew it used the old plug-in too.

1. Search every script for plug-in function calls. Use the Data Viewer, Database Design Report (DDR), or a dedicated FileMaker script/field usage tool to search for the plug-in's function prefix (e.g. BE_, MBS_, Zip_).
2. Check calculations, not just scripts. Plug-in functions often get embedded in calculated fields, custom functions, and even conditional formatting — places people forget to search.
3. Check scheduled server-side scripts. These run unattended, so a broken plug-in call here fails silently until a customer complains an invoice never arrived.
4. Look at container field configurations, script triggers, and custom menus. Plug-ins sometimes hook into these less obvious places.
5. List which plug-in versions are installed where — on FileMaker Server, on each developer's machine, and on every client workstation. Version mismatches between server and clients are a classic source of "works on my machine" bugs.
6. Note the plug-in vendor's status. Actively maintained with recent releases? Abandoned? Acquired and rebranded? This determines urgency.

A DDR export combined with a simple spreadsheet — plug-in name, function, where it's called, vendor status, replacement priority — turns a vague fear into a concrete, prioritized to-do list.

Which plug-ins should you replace first?

Not every plug-in is equally urgent. Prioritize by risk, not by how annoying the plug-in is to work with.

• High priority: vendor no longer exists, no Apple Silicon or current OS build, or the function is used in a revenue-critical process (invoicing, order processing, shipping labels).
• Medium priority: vendor still exists but updates are rare, or the plug-in is used in internal-only tools where a short outage is inconvenient but not catastrophic.
• Low priority: actively maintained, well-documented, used in a non-critical, easily reworkable area.

This is also the point to ask a harder question: does this functionality even need a plug-in anymore? FileMaker (now Claris Pro) has steadily absorbed capabilities that used to require third-party plug-ins — native JSON functions, the Insert from URL / cURL options script step, native PDF and container improvements, and built-in support for calling external APIs. A plug-in that was essential in FileMaker 14 might be entirely redundant in a current version.

What are the realistic replacement paths for an obsolete plug-in?

There's rarely a single "correct" answer — the right path depends on what the plug-in actually does.

1. Replace with native FileMaker functionality. If the plug-in only does JSON parsing, base64 encoding, or basic HTTP calls, native functions introduced in recent versions can often do the same job with zero external dependency.
2. Replace with a modern, actively maintained plug-in. Some plug-in categories (barcode generation, advanced PDF, cryptography) still genuinely need a plug-in — but choose one from a vendor with a public roadmap, recent release history, and Apple Silicon/current-OS support.
3. Move the logic out to an external service via API. For things like PDF generation, e-signatures, or address validation, a cloud API call from a FileMaker script (using native Insert from URL) can remove the plug-in entirely and often adds capabilities the old plug-in never had.
4. Build a small custom web app or middleware layer. For genuinely complex integrations — say, a legacy barcode scanner protocol or a proprietary hardware interface — a lightweight connector service can isolate the fragile part from your core FileMaker solution, so future OS or FileMaker upgrades don't touch it directly.

How do you actually migrate off a plug-in without breaking production?

1. Pick one plug-in function at a time. Don't attempt to remove three plug-ins in one release — isolate variables so you know exactly what caused an issue if one appears.
2. Build the replacement in a copy or a feature branch of the file, not directly in production.
3. Write a small test script that exercises every known use case of the old function — edge cases like empty values, special characters, or large files are where replacements usually break first.
4. Run the old and new logic side by side for a short period where possible (e.g. generate the PDF both ways and compare output) before cutting over fully.
5. Update all scripts, calculations, and scheduled jobs identified in your dependency map — not just the most visible one.
6. Remove the plug-in file from FileMaker Server and every client's Extensions folder only after you've confirmed nothing still calls it — a stale plug-in file left in place tends to get re-referenced by accident later.
7. Document the change — what was replaced, why, and where — so the next developer doesn't reinstall the old plug-in trying to "fix" something.

What if you can't fully remove a plug-in right now?

Sometimes a full replacement isn't feasible in one phase — the vendor is still viable but you simply don't have the sprint capacity yet. In that case, contain the risk instead of ignoring it:

• Pin the exact plug-in version in use and avoid "just updating everything" during an unrelated FileMaker Server upgrade.
• Keep an offline installer archive of that exact plug-in version — vendor websites and download links disappear more often than people expect.
• Wrap every call to the plug-in function inside a single custom function or script, rather than calling it directly from dozens of places. That way, when you're ready to replace it, you change the logic in one place instead of hunting through the whole solution again.
• Add this plug-in explicitly to your modernization roadmap with an owner and a target quarter, so it doesn't quietly become next year's emergency.

This kind of staged approach — map the risk, contain it, then retire it on your own schedule — is exactly the mindset covered in our broader guide on how to modernize a FileMaker system step by step, where plug-in dependency is just one of several legacy risk factors worth auditing before any major upgrade.

Quick checklist before your next FileMaker or macOS upgrade

• Full DDR-based inventory of every plug-in function call, including scripts, calculations, and scheduled jobs
• Vendor status confirmed for each plug-in (active / at-risk / abandoned)
• Risk-based priority list, not a random order
• Replacement decided per plug-in: native function, modern plug-in, API call, or custom connector
• Test cases covering edge cases, not just the happy path
• Rollback plan documented before removing any plug-in file from production
• Roadmap entry with an owner for any plug-in you can't replace yet

FAQ: obsolete FileMaker plug-ins

Can I just leave an old plug-in in place if it "still works"? You can, temporarily — but "still works" usually means "hasn't been tested against the next OS or FileMaker version yet." Treat it as borrowed time, not a stable state.

Will removing a plug-in speed up my FileMaker solution? Sometimes. Plug-ins add overhead on file open and can introduce subtle performance issues, especially older ones not optimized for 64-bit or Apple Silicon. Native replacements are often faster and more stable.

Is it safe to switch FileMaker plug-in vendors entirely? Yes, as long as you treat it as a real migration — map every usage, test thoroughly, and cut over deliberately — rather than a drop-in swap. Different vendors rarely have 100% identical function behavior.

How do I know if a plug-in vendor is actually still supporting their product? Check their release history and changelog for updates within the last 12–18 months, confirm they list current FileMaker/Claris and OS version compatibility, and test their responsiveness by asking a real support question before you commit.

Removing a stubborn plug-in dependency is rarely about the plug-in itself — it's about finally having a clear map of your system, a tested alternative, and a controlled way to switch. If that mapping feels overwhelming to do internally, or if the right fix turns out to be a custom FileMaker rebuild, an API integration to an external service, or a small dedicated connector app, Loggix can help assess the dependency, design the replacement, and guide the migration so your next platform upgrade isn't held hostage by a plug-in nobody remembers installing.