Someone pitched you a migration. Maybe several someones — a Salesforce rep, a Ninox salesperson, a consultant who "specializes in getting people off FileMaker," a friend at Thanksgiving. The pitch is polished. The numbers look reasonable. And you're sitting there wondering whether they're right or whether they're just selling something.
This page is what you'd hear from someone who doesn't have a migration to sell.
I don't sell migrations. I also don't need you to stay on FileMaker. If leaving is the right call for your business, this page tries to help you see that clearly. If it isn't, this page tries to help you see that too.
The six questions the pitch doesn't answer.
Every migration pitch answers the questions the vendor wants to answer. Here are the ones they'd rather you didn't ask.
1. What's the total five-year cost — subscription, migration, retraining, and productivity loss?
The monthly subscription is one number. The migration cost is a second number. The retraining time is a third. The productivity loss during the transition is a fourth. Ask for all four. If the vendor can only give you the first one, they haven't thought about the others — or they don't want you to.
2. What happens to the years of institutional knowledge sitting in my current system?
Every script, every calculation, every field trigger, every quirky business rule your team wove in over the years — none of that carries over automatically. Migration means someone reads all of it, decides what it does, and rebuilds it. Some of it gets rebuilt correctly. Some of it gets missed. Some of it gets "improved" in ways nobody notices until the year-end report comes out wrong.
3. What's your migration failure rate, and what does failure look like?
Every migration vendor has failed migrations. Ask what percentage of their projects don't finish, don't finish on time, or don't finish on budget. Ask what happens to the client when that occurs. If they claim they don't have failures, they're lying or they haven't done many migrations. Neither answer helps you.
4. What does it cost to leave your platform?
You're being asked to sign up for a platform. Ask what leaving that platform later would look like. Ask for the data-export commitment in writing. If the answer is vague, you're being asked to swap FileMaker's vendor lock-in for someone else's — which isn't liberation, it's substitution.
5. What happens when I double in size, or acquire another company?
Most migration targets price per user per month. That number scales differently than FileMaker's licensing. Do the math on where your business is going, not just where it is today. A cost that looks reasonable at fifteen users can be painful at forty.
6. Who's my next developer, and what will they cost?
You've had one developer, or a small pool of them, for years. When you're on the new platform and you need help, who do you call? How many people can do that work? What do they charge? Smaller platforms have smaller developer pools, and smaller pools cost more per hour and are harder to schedule.
If the pitch didn't cover all six, you don't have enough information to sign.
What "modern" actually means.
The sales pitch usually leans on the word modern. A modern platform. A modern interface. A modern approach.
In practice, "modern" tends to reduce to five things: cloud hosting, a browser-based interface, mobile access, a way to connect other software (an API), and some form of AI capability. Those are real features, and they matter.
They're also not what you have to migrate to get. FileMaker Cloud is cloud hosting. FileMaker Go handles mobile. The FileMaker Data API is a real API. Web screens can be added next to an existing FileMaker system — that's what Extensions on this site is. AI can be added to any platform, and most vendors' AI features are the same few AI models anyone can hook up, with a new label.
Which means the pitch's implicit claim — that you need a new platform to get "modern" capabilities — often isn't true. What's true is that you need someone to add the missing pieces. That's a job. It's a much smaller job than a migration.
When migration is genuinely the right call.
There are cases where leaving FileMaker is correct.
Your system is small and ordinary. A few tables, standard workflow, no significant custom logic. Rebuilding it on any modern platform takes weeks, not months, and the migration is cheaper than the maintenance you're skipping.
Your business is changing shape fundamentally. You're pivoting from services to product, from B2B to consumer, from local to national. The system that fit the old business doesn't fit the new one, and starting fresh on a platform designed for the new shape is cheaper than retrofitting.
Your team's frustration is with the platform itself, not with specific screens or reports. This is rare. Most FileMaker frustration is about specific work sitting in front of specific people, and most of that is fixable without leaving. If someone dug into it and can show you the frustration is truly platform-level, migration is a real answer.
When it's a lateral move sold as an upgrade.
Three cases show up over and over.
The problem is one slow screen. A list view that takes ten seconds to draw. A report that stalls the whole system. Any competent developer can fix that in a week without leaving the platform. Migrating the whole system to solve one screen is the equivalent of buying a new house because the kitchen faucet drips.
The problem is mobile or remote access. People need to see or update the system from their phone, from home, from a client site. FileMaker Go exists. A web extension exists. Neither requires migration.
The problem is that "FileMaker is dying." There's truth in it. FileMaker isn't dead. It's cooked: terminal, with a few good years left. Claris still ships a release every year and has said where it's heading. Meanwhile the developer pool keeps shrinking, and Claris is cutting back to its core, starting with Claris Studio. But every subscription software platform could disappear, be acquired, or change pricing overnight. Migrating from FileMaker to another company's platform doesn't reduce that risk. It just moves it to a different vendor.
What five years actually costs.
The honest way to compare is a five-year total, because that's how long you'll be on whichever platform you pick.
For most FileMaker shops considering migration, the math runs something like this.
Staying on FileMaker. Current licensing plus current developer costs, over five years. For a mid-size shop, that lands somewhere in the forty-to-eighty thousand range. Add extensions if you're modernizing; that's a one-time cost, small next to a migration.
Migrating to a modern platform. New platform subscription over five years, plus migration cost (thirty to a hundred and fifty thousand for a real system), plus retraining and productivity loss during transition (harder to quantify but real). For the same mid-size shop, that lands somewhere between eighty and two hundred thousand.
Migration is not cheaper. It might be worth it anyway — the new platform might fit your business better, might attract talent you can't attract now, might enable capabilities you actually need. But the pitch that says "you'll save money" is almost never true.
Before you sign anything.
If you're seriously considering a migration, do these six things first.
- Get three quotes, not one. Migration pricing varies wildly.
- Ask for references from clients whose systems were similar in size and complexity to yours. "We did a migration once" doesn't tell you what you need to know.
- Ask for the migration failure rate in writing. If they won't put a number on it, that's the number.
- Get a data-export commitment in writing. You should be able to leave in thirty days with a complete, structured copy of your data.
- Insist on a phased rollout. Switching everything at once fails. One piece at a time, with the old system running alongside, gives you a way to stop if it isn't working.
- Get an independent assessment before you sign. Not from the vendor. Not from the vendor's preferred partner. From someone whose income doesn't depend on you signing.
That last one is a plug for what I do, and I'll own it. But the principle stands regardless of who does the assessment: the person selling you a thing shouldn't be the only one telling you whether to buy it.
Two forks from here.
If you've decided to leave, do it cleanly. Get your data out first. Plan the migration in phases with the old system running alongside the new one. Talk to your consultant about phases, not deadlines. Details on the Leave page.
If the answer isn't clear, or if what you actually want is to solve the specific problem that started this whole conversation without spending eighty thousand dollars to do it, the extend-instead path is worth a look. Most of what starts migration talk is one specific pain — a slow screen, a missing mobile view, a report nobody can run. Those problems can be solved without leaving FileMaker. Details on the how it works page.
If you're being pitched by a specific vendor, deeper reads on each: Ninox. Salesforce and other platforms coming.
If you're not sure which fork you're on, the assessment is where that question gets answered honestly, in writing, in a document you can use with any developer — including one who isn't me.