The short version.

The old FileMaker system keeps running exactly as it does today. One module at a time gets built on the new platform alongside it, tested by real users against real data, then cut over. Once that module is stable on the new side, the FileMaker equivalent goes read-only. Repeat for the next module. Eventually FileMaker is holding only archived data, and the business has been running normally the whole time.

The technical name for this is the strangler-fig pattern, borrowed from a tree that grows around a host until the host is no longer load-bearing. What it means in practice is that at no point does the business bet its operations on a new system that has not yet proven itself.

The old system keeps running exactly as it does today. That is not a bug — it is the design.

Why the big-bang rebuild fails.

The tempting alternative is to scope the whole system, build the replacement over six months, cut over on a weekend, and call it done. This is what most rebuild proposals actually describe. It is also why most rebuild projects double their budget and timeline.

The reason is not developer competence. It is that a FileMaker system that took 15 years to shape around your business has 15 years of business logic buried in it — in scripts, in calculations, in conditional formatting, in the way one user has always done a particular workflow that nobody documented. Half of those requirements exist only inside the running system. When someone tries to reproduce them in a rebuild, they surface one at a time, usually during user acceptance testing, usually after the budget has already been committed.

Staged migration surfaces those requirements one module at a time, against a specific chunk of scope, with the old system still available for the user to point at and say "no, it does this." That's a fundamentally different testing dynamic than "we're going live Monday, did we get everything?"

What gets migrated in what order.

The order matters and it is specific to each business. A rough pattern that works for most SMB operational systems:

  1. Read-only modules first. Reports, dashboards, customer-facing lookups. These can pull from FileMaker over the Data API and get replaced with a modern interface without touching the write side. Low risk, immediate visible win.
  2. Highest-pain user-facing module next. Whichever module is bleeding the most — mobile access that FileMaker Go can't quite reach, a customer portal that everyone has been asking for, a form that staff keep printing and re-typing. Building this one on the new platform proves the pattern and delivers value the whole time.
  3. Transactional modules by dependency. Quotes → orders → invoicing → payments, in whatever order the data flow makes sensible. Each one migrates as a self-contained chunk. During the migration window both sides can read the same underlying data, either by shared database or by replication.
  4. Core reference data last. Customers, products, vendors — the data everything else depends on. This is deliberately last because it needs to survive all the earlier modules being built. When the last transactional module is migrated, the reference data has been proven against every use.

What FileMaker keeps doing while migration runs.

For most of the project, FileMaker is still the system of record for the modules not yet migrated. Staff use it for those modules exactly as they always have. When a module cuts over, that specific set of layouts and scripts becomes read-only in FileMaker. Nothing forces a user to stop using FileMaker until their module has moved. Nothing surprises anyone.

Near the end of the project, FileMaker holds only the modules that no longer need active use — history, archives, audit trails. Some businesses keep FileMaker running in that mode indefinitely, purely as a read-only historical system. Others export the archives once and shut it down. That decision is not made at the start; it's made when the migration is almost complete and the picture is clear.

When leaving FileMaker is the wrong answer.

Not every FileMaker system needs to migrate. For a significant share of the customers reading this, the honest advice is stay, document the system properly, right-size the licensing, and use the money you would have spent on a rebuild for something the business actually needs. FileMaker still fits when the system is working, the staff know it, the maintenance is reasonable, and no specific business need is being blocked.

Anyone who tells you the answer is always "migrate" is selling a migration. That is not what the answer always is, and part of the point of the free triage call is to make sure the recommendation matches your situation.

When it is the right answer.

Migration makes sense when one or more of these are true. Licensing costs have become material against the operating budget and are climbing. The business has outgrown what FileMaker does easily — real-time integrations with other systems, customer-facing web experiences at scale, high concurrent user counts, mobile workflows for large field teams. Hiring or retaining FileMaker developers has become genuinely hard for your situation. An acquisition is on the horizon and clean, portable data is now part of the business's value. Or the platform is preventing a specific capability the business needs and has needed for a while.

Any one of these can be reason enough. The point is not to leave because the industry is nervous. The point is to leave when it materially serves the business.

If leaving FileMaker is going to happen, do it as a project, not as a rescue.

Roughly what it costs.

An honest range is wide because system complexity varies more than most owners realize. A small operational system with three or four clean modules might migrate for $40-80k over six to nine months. A larger, more entangled system with heavy customization and integration ends up in the $100-250k range over 12-18 months. The System Assessment is where the honest range gets narrowed to a specific number for a specific system.

Compare that number to five to ten years of forward FileMaker licensing, the cost of the ongoing modernization workarounds you would otherwise pay for, and the strategic cost of being on a platform you can't easily hire for. The decision usually comes down to which number is smaller over the horizon that matters.

What to do next.

If leaving FileMaker is on the table for your business, the free triage call is the right first step. You describe the system, the pressures, and the timeline. I tell you whether staged migration is the right shape, roughly what it would cost for a system of your size, and whether staying is actually the better answer. If it is, you will hear that too.