How to migrate a FileMaker solution to a newer version

Your FileMaker system still runs the business — invoices go out, stock gets tracked, staff log in every morning — but it's built on FileMaker 14, or 16, or even older, and every new hire asks why the interface looks like it's from another decade. Meanwhile Claris keeps shipping new versions, your hosting renewal reminds you support for the old one is ending, and nobody on the team is quite sure what will break if you just click "update." This article walks through exactly how to migrate a FileMaker solution to a newer version safely — what to check first, what usually breaks, and how to modernize the interface and integrations along the way instead of just changing the version number.

Why isn't a FileMaker version upgrade just "click update"?

Because a FileMaker file isn't just a database — it's a full application: layouts, scripts, custom functions, security settings, plug-ins, and often years of accumulated workarounds from developers who have long since left the company. Opening an old file in a new version of FileMaker Pro will usually work without complaint. The real risk isn't the file opening — it's what happens next: a script that calls a plug-in function no longer supported, a container field storing files in a way the new version handles differently, or a layout built with theme styling from FileMaker 13 that now renders with visual glitches nobody expected.

A concrete example: a wholesale distributor running FileMaker 16 with a custom barcode-scanning plug-in migrated straight to FileMaker 19 over a weekend. The file opened fine on Monday morning — but the scanning script silently failed because the 32-bit plug-in had no 64-bit equivalent. Nobody found out until the warehouse team had already mis-shipped two pallets. That's the kind of gotcha a version upgrade needs to be tested for, not assumed away.

What should you check before migrating?

Before touching the live file, audit these five areas:

1. Plug-ins. List every third-party plug-in in use (barcode scanners, PDF generation, email, encryption). Confirm each has a version compatible with your target FileMaker version — some plug-ins were abandoned by their vendors and have no upgrade path at all.
2. Custom functions and scripts using deprecated features. Search for calls to functions Claris has flagged as deprecated (certain container storage options, older ExecuteSQL quirks, legacy web viewer behavior).
3. Hosting environment. Check whether your current FileMaker Server version is compatible with the new client version, and whether your server OS itself needs an upgrade too.
4. Integrations. Map every external connection — API calls, ODBC/JDBC links, email/SMTP relays, scheduled scripts talking to accounting or webshop systems. Each one needs to be re-tested after migration, not assumed to keep working.
5. Custom UI elements. If the solution uses old-style buttons, themes, or the classic FileMaker look, decide now whether you'll modernize the interface as part of this migration or do it as a separate phase later.

What's the safest step-by-step process?

1. Duplicate the live file and do all migration work in a sandboxed clone — never touch production first.
2. Open the clone in the new FileMaker Pro version and run the built-in file conversion/upgrade process if moving across major version boundaries.
3. Run FileMaker's script debugger and Data Viewer against every major workflow: order entry, invoicing, reporting, imports/exports. Don't just click around — trigger the actual scripts real staff use daily.
4. Test every integration in the new environment: does the connector to your accounting package still authenticate? Does the scheduled nightly export still land in the right folder?
5. Load-test on a staging server with realistic data volumes, especially if you're also moving hosting infrastructure.
6. Run a parallel period. For at least a few days — ideally a full business cycle like a week or a month-end close — keep the old and new versions running side by side, comparing output, before fully cutting over.
7. Cut over during a low-activity window (a weekend, end of month) with a rollback plan documented and ready.
8. Retrain staff on anything that visibly changed, even small things like a repositioned button — users notice, and support tickets spike when they don't know what changed.

Should you modernize the interface at the same time as the version upgrade?

This is the fork in the road every migration project hits. A pure version bump keeps risk low and scope small — you're only changing the engine, not the car's dashboard. But if your interface is genuinely dated, doing the upgrade and the interface refresh as two separate projects often means redoing testing work twice.

This is where tools like FMBetterForms become relevant: it lets you rebuild FileMaker layouts with modern, responsive, web-standard interface components — without abandoning your existing FileMaker data model and scripts. In practice, this means a company migrating from FileMaker 17 can combine the version upgrade with an interface modernization pass, giving staff a genuinely current-feeling application instead of an old-looking one running on new plumbing underneath. It's not mandatory for every migration, but it's worth evaluating in the same project scope rather than as an afterthought two years later.

Is this a good moment to add AI to the workflow?

Once a solution is on a current, supported version, it also becomes realistic to layer in AI-assisted features that older FileMaker versions can't support well — think automatic document summarization on incoming PDFs, natural-language search over customer records, or AI-assisted data entry validation. Tools such as Klai are built specifically to bring AI capabilities into a FileMaker solution without ripping out the existing system. Migrating the version first is what makes this kind of addition technically possible and stable — trying to bolt AI features onto an unsupported, outdated version is a much shakier foundation.

What commonly goes wrong during a FileMaker version migration?

• Underestimating plug-in dependency risk. A single unsupported plug-in can silently break a core workflow, as in the barcode example above.
• Skipping integration testing. APIs and ODBC connections that "probably still work" are the most common source of post-migration firefighting.
• No rollback plan. If cutover goes wrong on a Friday night, you need a documented way back to the old version by Monday morning, not a scramble.
• Migrating and redesigning at the same time, untracked. If you decide to modernize the UI during the upgrade, treat it as an explicit, scoped decision — not scope creep that happens by accident mid-project.
• Forgetting server-side scripts and schedules. Server-side automations (nightly imports, scheduled reports) get missed in testing because nobody manually triggers them — but they run on their own schedule and fail silently if broken.

FAQ: FileMaker version migration

How long does a typical FileMaker migration take? For a small, single-file solution with few integrations, a few days of focused work. For a multi-file solution with plug-ins, external APIs, and heavy customization, plan for several weeks including a proper parallel-run period.

Can I skip several versions at once (e.g., FileMaker 14 straight to 21)? Technically often yes, but the more versions you skip, the more deprecated features and plug-in incompatibilities you're likely to hit at once. It's usually safer, and easier to debug, to test the jump in a sandbox first rather than assume it'll be smooth.

Do I need to upgrade FileMaker Server before the clients? Generally yes — the server version needs to support the client version you're moving to. Check Claris's compatibility matrix before planning your cutover date.

Will my custom reports and scripts still work exactly the same? Most will, but any script using deprecated functions or relying on old container storage behavior needs explicit testing — don't assume identical behavior across major versions.

Checklist before you migrate

• Inventory of all plug-ins and their compatibility with the target version
• List of all integrations and API connections to re-test
• Server and OS compatibility confirmed
• Sandbox/clone environment created
• Rollback plan documented
• Parallel-run period scheduled
• Staff communication and training plan ready
• Decision made on whether to modernize UI in the same project

A version migration is really one step in a larger modernization journey — our full guide on how to modernize a FileMaker system step by step walks through the bigger picture, from legacy audits to long-term platform strategy.

If your FileMaker solution is overdue for a version upgrade, Loggix can help map out the safest path — from a technical audit of plug-ins and integrations, to a phased migration plan, to modernizing the interface with tools like FMBetterForms or adding AI capabilities with Klai once the foundation is solid. Whether you need hands-on development, a second opinion on your migration plan, or a broader consultancy session to decide what "modern" should actually mean for your business, it's worth mapping the next step before you click update.