The short version.

The old FileMaker system keeps running exactly as it does today. One piece at a time gets built on the new system alongside it, tested by real people on real data, then switched over. Once a piece is steady on the new side, FileMaker's version of it is locked so it can be looked at but not changed. Then the next piece. Eventually FileMaker is holding only old records, 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's deliberate. It's the whole point of doing it in stages.

Why rebuilding it all at once 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 rules 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 when staff first try the new system, usually after the budget has already been committed.

Moving in stages turns those up one piece at a time, with the old system still there for staff to point at and say "no, it does this." That's a very different way to test 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 small-business systems:

  1. Screens people only look at go first. Reports, dashboards, customer lookups. They can read from FileMaker and get new screens without touching anything that changes data. Low risk, and a win everyone sees right away.
  2. The piece that hurts most goes next. Whichever one 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. Then the day-to-day money work, in the order each step feeds the next. Quotes → orders → invoicing → payments. Each one moves as its own piece. While it's moving, both systems can read the same data, from one shared database or from a copy kept in step.
  4. The customer, product and vendor lists go last. Customers, products, vendors — the data everything else depends on. This is deliberately last because it needs to survive all the earlier pieces being built. When the last of the money work has moved, those lists have been proven against every use.

What FileMaker keeps doing while migration runs.

For most of the project, FileMaker still keeps the real records for the pieces not yet moved. Staff use it for those pieces exactly as they always have. When a piece moves over, its layouts and scripts in FileMaker are locked: you can look, but not change. Nothing forces a user to stop using FileMaker until their piece has moved. Nothing surprises anyone.

Near the end of the project, FileMaker holds only the pieces 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, pay only for the licenses you use, 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 takes a real bite out of the budget and keeps climbing. The business has outgrown what FileMaker does easily — connections to other software that have to happen instantly, web screens for lots of customers, many people working at once, phone work for large field crews. 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. Don't leave because the industry is nervous. Leave when it really serves the business.

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

What sets the size of a migration.

System complexity, which varies more than most owners realize. A small operational system with three or four clean pieces might migrate over six to nine months. A larger, more entangled system with heavy customization and integration takes 12-18 months. The System Assessment ends in a quote for your specific system, with good, better and best options.

Compare that number to five to ten years of future FileMaker license fees, the workarounds you'd otherwise keep paying for, and the cost of being on a platform you can't easily hire for. The decision usually comes down to which number is smaller over the years that matter to you.

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 and whether staying is actually the better answer. The System Assessment puts a number on it. If staying is the better call, I'll tell you that.