Upgrading To FileMaker 2026 Won't Fix Your Bad Data Model

Overview

A client called us in March because their FileMaker solution was taking 40 seconds to open a customer record. Their plan was to wait for the next version.

We looked at the file first.

One table had 62 fields, 18 of which were unstored calculations referencing three related tables. The customer list layout showed 14 of them in list view. Every scroll recalculated the lot.

There were also four separate scripts named some variation of “Update Records”, written by three different people over nine years. Nobody at the company knew which one was still in use, so all four stayed.

None of that gets faster with a new engine. It gets faster when you stop asking the engine to do impossible work.

We moved the calculations to stored fields updated on commit, cut the list layout to five columns, and deleted three of the four scripts after tracing what actually called them.

Record opens went from 40 seconds to under two. Same FileMaker version. Same server. Same hardware.

The upgrade conversation is easier to have. It has a date, a price, and a release note. Architecture work has none of that, which is why it keeps getting pushed.

But a faster platform running a broken data model just gets you to the wrong answer sooner.

What is the oldest performance problem in your solution that everyone has quietly agreed to live with?