Someone showed you Ninox — a salesperson, a consultant, a friend who "moved off FileMaker and never looked back" — and it looked good enough that you started thinking about your own system.

This page is for that moment. It's the answer I'd give if you called me on the phone.

I don't sell Ninox migrations. I also don't need you to stay on FileMaker. Both of those matter for what follows.

What Ninox actually is.

Ninox is a newer database platform, much like FileMaker. It runs in the cloud, or on your own server if you prefer. Aimed at the same small-and-mid-size business market FileMaker built itself on — the business that needs custom software but can't justify a Salesforce implementation.

Compared to FileMaker: cleaner web interface, better mobile out of the box, more modern feel. Compared to Airtable: more real database, less spreadsheet-with-relationships. It has scripting, it has forms, it has views, it has permissions. It is a genuine product, not a toy.

If you were starting from zero today and asked me "FileMaker or Ninox for a new build," Ninox would be a defensible answer. That's the honest version.

When leaving FileMaker for Ninox is the right call.

There are cases where it fits.

Your FileMaker system is small — a handful of tables, a couple hundred fields, two or three users. Migration is measured in weeks, not months.

The people using it live on phones and tablets, not desktops. FileMaker Go works, but Ninox was designed for the browser from day one.

Your custom logic is thin. If the system is mostly forms, lists, and a few calculations, most of it moves over without much trouble.

Nothing in it holds know-how worth saving. The person who built it is long gone, the documentation is a Post-it note, and the system is more of a burden than an asset.

In those cases, Ninox is a reasonable landing spot. I've said so on the phone before.

What the salesperson didn't tell you.

You're not leaving vendor lock-in. You're changing vendors. Ninox belongs to one company and charges per user, per month. If Ninox gets acquired, changes pricing, or shifts direction, you have the same problem you have with Claris today — a system running on someone else's rails.

Nothing carries over automatically. Not layouts, not scripts, not calculations, not relationships. Every business rule your system enforces has to be rewritten. The demo showed you the tool. It didn't rebuild your system.

The interesting part of your system isn't a feature list. It's the accumulation of "we don't do it that way" decisions your bookkeeper, your warehouse guy, and your salespeople wove in over a decade. That knowledge lives in the scripts, in the field triggers, in the specific way a status change fires a follow-up email. A Ninox salesperson cannot tell you whether their platform will hold your process, because they don't know your process. Neither do you, entirely — you know the parts you touch daily. The parts that quietly work are invisible until they don't.

Speed with many people working at once, and heavy automation, are the two places FileMaker veterans tend to hit walls in Ninox. Not immediately, not fatally. But if your system has thousands of records, many people editing at the same time, or a lot of automation running on the server, budget for surprises.

The Ninox developer pool is smaller than FileMaker's. Which is already small. Finding your next developer, when you need one, will be harder than finding your next FileMaker developer. That's a hidden cost of switching to any platform outside the big three.

The five-year cost picture.

The number the salesperson shows you is the monthly subscription. The number that actually matters is what you'll spend over five years — because that's how long you'll be on whichever platform you pick.

Ninox subscriptions for a fifteen-user shop, over five years, run into the low tens of thousands. Migration itself, done properly, runs somewhere between thirty and a hundred and fifty thousand depending on how much system there is to move — most of it in the first year. Add a developer on retainer, add training, add the productivity hit while people learn the new interface.

Total five-year cost of a Ninox migration, for a mid-size FileMaker system, typically lands somewhere north of what you'd spend keeping the current system running and maintained.

The switch isn't cheaper. It might be worth it anyway — but it isn't cheaper, and any pitch that implies it is has left something out.

Two forks from here.

If you've decided to leave, do it cleanly. Get your data out first, before anything else — FileMaker exports well; make sure you have a complete, structured copy of everything. Then plan the migration in phases, one piece at a time, with the old system running alongside the new one until each piece is proven. Switching everything at once fails. Moving in stages works. Whichever consultant you hire — Ninox specialist or otherwise — should be talking to you about phases, not deadlines. Here's the leave path.

If the answer isn't clear, the extend-instead path is worth a look. Most of what drives an owner to consider migration is a specific pain: a screen that's too slow, a workflow that doesn't work on phones, a report nobody can run without help. Those problems can be solved without leaving FileMaker. Web screens next to your existing system, built from common pieces you can look inside and replace, tend to cost a fraction of a migration and keep the rules your system already runs on, which you've already paid for. Details on the how it works page.

That's not a pitch. It's the shape of what I do. 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.