Business softwareMethodCustom softwareSMEsPricing
FileMaker to web app: when to migrate, which path to take, and what it really involves
11 min read
A FileMaker database should move to a web app when it outgrows what it was built for: customers or partners who need access, a user count that keeps pushing license costs up, integrations that get harder every year, or a single developer who understands the whole thing. You have three real paths: stay on the Claris platform and open the database to browsers with WebDirect, add a web application that talks to FileMaker, or rebuild completely as a web app. The hard part is rarely the screens. It is the scripts, the calculations and the files stored inside the database.
This guide is for the owner or manager who has to decide. It does not run FileMaker down: it is an excellent tool for building a business database fast, and plenty of companies have grown with it for years. The question is whether yours has reached its limits.
Why companies move off FileMaker
FileMaker, made by Claris, was often built by a capable power user inside the company, then extended as needs grew. That is its strength: the database fits the business exactly. It turns into a constraint in five situations.
- Customers or partners need access: order tracking, document upload, booking. Opening an internal database to the outside raises security and licensing questions.
- The user count grows, and the license bill grows with it, seat by seat.
- Integrations pile up: accounting, the website, an ERP, e-signature, payments. FileMaker can do them, but they require specialist skills.
- One person holds the keys, usually whoever built it. The pool of FileMaker developers is much smaller than the pool of web developers.
- The mobile and web experience feels dated: WebDirect and FileMaker Go are genuinely useful, but the ergonomics remain those of a database rather than a modern app.
What FileMaker costs today
Claris sells FileMaker by subscription. Its pricing page (checked on 7 November 2026) lists two FileMaker Cloud plans, billed annually:
| Cloud plan | Listed price | Users |
|---|---|---|
| Starter | US$22 per user per month | 5 to 10 only |
| Max | US$45 per user per month | 5 to 99, 100+ through sales |
FileMaker Server, for hosting on your own machines, is sold separately. Prices vary by region and change over time, so check your own contract. What matters for the decision is the mechanism: a cost that scales with users, every year, indefinitely. A custom application flips that logic: a development cost, then hosting and maintenance that do not depend on how many accounts you create. For a team of 15 on the Max plan, the listed price alone adds up to US$8,100 a year, before hosting or developer time.
When you should stay on FileMaker
Migration only makes sense if it solves a real problem. Stay if:
- the database serves a small internal team, with no outside access;
- a capable, available FileMaker developer keeps it evolving;
- FileMaker Go on iPad works for your field staff;
- license costs remain reasonable for the value delivered;
- nobody is asking for features FileMaker makes difficult.
In that case, invest in resilience: a current version, tested backups, documentation of the key scripts, and a second developer who knows the solution.
The paths compared
| Path | What changes | Strengths | Limits |
|---|---|---|---|
| Stay on Claris, open it with WebDirect | Browser access to existing layouts | No rewrite, fast to set up | Per-user licenses, database ergonomics, connection ceiling |
| Web app alongside FileMaker | A portal or module reads the data via API | FileMaker stays internal, the web faces outward | Two systems to maintain, Claris dependency remains |
| Custom web application | Browser, standard database, documented APIs | Access anywhere, cost independent of seats, integrations | Full rewrite, scripts and containers to migrate |
| Another low-code tool or packaged software | You switch platforms | Little or nothing to build | New dependency, your processes must fit the tool |
Open the database with WebDirect
WebDirect renders your FileMaker layouts in a browser without any rewrite. It is quick and works well for staff working from home. Claris's WebDirect documentation says a server machine generally supports up to 100 concurrent connections. For a portal open to customers, the limits show quickly: licensing, layouts designed for desktop screens, and fine-grained permissions that are harder to get right.
Add a web application that talks to FileMaker
FileMaker Server and FileMaker Cloud expose data through APIs, including the OData protocol described in Claris's OData guide. A web application can therefore read and write the database, for example to run a customer portal, while your internal team keeps its FileMaker screens. This is often the first step of a gradual migration: the web takes the outside world first, then picks up internal modules one by one.
Rebuild as a custom web application
A browser-based application, a database such as PostgreSQL, documented APIs for integrations. This path opens the most doors and removes the dependency on a proprietary platform. It is also a real development project, and it starts by understanding what the database actually does. The same reasoning applies to similar tools: see converting an MS Access database to a web app and Airtable's limits.
What migrates badly, and how to handle it
Scripts
A mature FileMaker solution often has hundreds of scripts. They chain actions on layouts: go to layout, perform find, sort, set field, print. That model does not exist as such on the web. The Database Design Report that FileMaker Pro generates lets you inventory them. Then sort them into business rules to rewrite, interface automation to rethink, and dead scripts to delete. AI tools can speed up reading the report; deciding which rules still matter remains a job for people who know the business.
Calculation fields and the relationships graph
FileMaker computes a lot on the fly: totals, statuses, summary fields. The relationships graph multiplies table occurrences so that the right data shows in the right place. In a web application, those calculations become queries or code, and the relationships a proper data model. It is the moment to clean things up rather than copy years of workarounds.
Container fields
Photos, PDFs, drawings, contracts: FileMaker often stores files inside the database, sometimes externally. Plan their extraction early, because the volume can be large and file names inconsistent.
Print layouts
Quotes, invoices, labels, work orders: each printed layout is rebuilt as a PDF generated by the application.
Access control
FileMaker privilege sets decide who sees what, sometimes down to the record. They become roles and rules in the new application, tested with every user profile.
The data itself
Duplicates, dates typed as text, value lists that changed over the years: moving the data takes cleaning and trial migrations signed off by the business. The method is in our guide to legacy data migration.
Migrate in stages
- Inventory: tables, scripts and layouts in real use, and by whom. Some are dead.
- Choose the first module: usually what FileMaker does poorly, such as a customer portal or mobile field access.
- Prototype validated by users before any development.
- Coexistence: the web module reads and writes FileMaker through the API, or a new synchronized database.
- Module-by-module cutover with a rollback plan, until the FileMaker database and its licenses can be retired.
If phones matter, see also web app vs PWA vs native app. Teams leaving other tools of the same generation can read Delphi to web migration and VB6 migration.
What a FileMaker migration costs
Cost depends on the scripts and layouts in real use, the complexity of calculations, container volume, integrations and data quality. Cost drivers and ranges are covered in software modernization cost.
To compare fairly, lay out both columns over five years. On the FileMaker side: per-user licenses, hosting, developer time. On the custom side: development, hosting, maintenance. Payment models change the equation too: a fixed price, or a subscription that avoids paying for development upfront, as explained in software subscription vs upfront build.
Common mistakes
- Cloning every FileMaker layout one to one, when some are unused and others could merge into one screen.
- Forgetting container fields, then discovering gigabytes of files at cutover.
- Underestimating scripts, which carry most of the business rules.
- Switching FileMaker off on launch day, with no coexistence period.
- Letting the database's creator leave before writing down what they know.
A checklist for decision-makers
- How many users pay for a license today, and how many in three years?
- Who outside the company should access the system?
- How many scripts and layouts are used every week?
- Where are files stored: inside the database or alongside it?
- Which integrations are essential?
- Who can sign off the business rules of the new application?
Where to start
Gather screenshots of the most used layouts, the list of important scripts and, if possible, a Database Design Report. One conversation is then enough to tell whether WebDirect, a companion web app or a full rebuild fits.
At LPR Studio, that conversation leads to a free visual prototype of the first web module, presented on a video call within 5 business days, so your team sees its future screen before anyone commits. The approach is explained in see your software before you pay for it.