Migrating FileMaker to a modern web app

Your FileMaker solution may have served you faithfully for fifteen years, handling order management, customer administration, project planning and stock lists. Yet the signs that its future-proofing is wearing thin are growing: Claris (Apple) stopped selling new Server licences to organisations that were not already customers in 2024, developers with FileMaker experience are becoming harder to find, and mobile access via WebDirect is hitting performance limits. We guide Dutch SMEs through a calm, phased migration to a modern web application, preserving your business logic and avoiding big-bang risk.

FileMaker Pro / Claris Pro DDR export JDBC/ODBC data migration Schema mapping Parallel run Custom web app development

Discuss your migration Review the reasons

When FileMaker stops being a future-proof choice

FileMaker (continued since 2019 as Claris Pro) has long occupied a unique niche: building something quickly for one team without setting up a full software department. Many Dutch SMEs still run a FileMaker solution behind the scenes, sometimes dating back to FileMaker Pro 7 or 11. It has served them well. The question is not whether FileMaker was ever good, but whether it is still the right foundation for the next ten years.

In 2024, Claris announced that new organisations that were not previously customers could no longer purchase Claris Server. Existing customers can renew, but the intake of new users has effectively stopped. At the same time, the platform was renamed Claris Pro and Claris Studio, with a closer tie to the Apple ecosystem. For your current solution this is not an immediate problem, but it does point in a direction: the developer ecosystem is shrinking, third-party tools are disappearing, and the roadmap is becoming narrower rather than broader.

On top of that, the expectations of your employees and customers have fundamentally changed in recent years. Browser access on any device, real-time collaboration, mobile data entry in the field, and integrations with accounting, e-commerce and logistics platforms: these are requirements that every SME now faces. FileMaker WebDirect and the FileMaker Data API can do a lot, but they reach their limits once the number of concurrent users grows or the interface becomes more complex than a set of layouts allows.

We are not anti-FileMaker. In some situations, such as a small departmental tool that has run reliably for years, migrating would be overkill. But if you recognise yourself in two or more of the six reasons below, it is wise to plan the migration now, rather than waiting until the platform forces your hand.

Six practical reasons to replace your FileMaker solution

Not all pain arrives at the same time. Some organisations notice rising costs first, others get stuck finding a new developer. The six patterns below are the ones we see most often in conversations about a migration path.

📈

Rising licence costs per user

Claris charges per-user licences that scale with your team. An organisation growing from fifteen to forty staff sees its annual FileMaker bill rise in step, whereas a custom web app typically carries no per-user licence fees. For a growing business, that is a structural cost difference that repeats every year.

🧑‍💻

Shortage of FileMaker developers

The pool of FileMaker developers in the Netherlands is small and ageing. Finding a good FileMaker developer for maintenance, extensions or a script-engine issue takes longer and costs more each time. A web app built on mainstream stacks (TypeScript, PostgreSQL, REST/GraphQL) draws on a far broader talent pool, including for maintenance five or ten years from now.

📱

Mobile experience falls short

FileMaker Go on iPad works well for structured data entry, but Web Direct on smartphones feels slow and dated next to modern progressive web apps. For field engineers, sales teams on the move or customers ordering through the browser, the UX gap is now large enough to matter commercially.

🔌

Integration with external systems becomes complex

The FileMaker Data API is functional, but building robust, two-way integrations with, for example, Exact Online, Magento, Shopify, Microsoft Dynamics or a marketplace API takes a lot of work in script steps and cURL options. A web app with its own backend communicates far more directly with these external APIs, with better error handling and logging.

⚡

Performance with larger datasets

FileMaker performs well up to a few hundred thousand records, but at millions of records, with complex relationships and heavy calculation fields, we see search and sort speeds deteriorate. A PostgreSQL or MySQL back end with the right indexes can handle datasets that make FileMaker unusually slow.

☁️

On-premises deployment no longer fits

Many FileMaker environments still run on an in-house server or a hosted FileMaker Server. For remote working, ISO 27001 requirements or customers expecting SaaS-style access, a cloud-native web app (containers, automated backups, EU hosting) is a more logical foundation. Migrating is therefore an infrastructure modernisation, not just a software replacement.

How we migrate a FileMaker solution safely to a web app

A FileMaker migration is not an export and import. Your solution contains years of accumulated business logic, hidden in scripts, calculations, layouts and custom functions. We do not build a lift-and-shift copy; instead we reconstruct your solution as a modern web app, keeping what works and rethinking what had become too cumbersome in FileMaker.

The first step is always a schema extraction. Using FileMaker's Database Design Report (DDR), we export your complete table structure, field types, relationships, layouts, scripts, value lists and accounts to XML. For us, that XML serves as readable documentation of your solution and as the basis for mapping to a relational database schema (PostgreSQL or MySQL). We translate calculation fields into database functions or back-end logic, and container fields into object storage with file references in the database.

For the data export, we use three techniques depending on the volume: ExportFieldContents for binary files in container fields, JDBC/ODBC for bulk exports to staging tables, and the FileMaker Data API for incremental synchronisation during the parallel run. This allows us to validate, table by table, that the data in the new web app is identical to the source before the old solution is switched off.

The business logic in your FM scripts is usually the most time-consuming part. We analyse every script — mature solutions often contain hundreds — and group them by functional purpose: validation rules, workflow triggers, reporting and bulk operations. The relevant rules we reconstruct as services in the backend of the new web app, with unit tests where it matters most. Obsolete scripts (for example for discontinued processes) won't make the move — a natural moment for a clean-up.

Finally, we run the systems in parallel for at least a few weeks: the FileMaker solution and the new web app are both live, with daily data synchronisation. Your team first works in duplicate or tests in the new environment alongside the old one, compares reports and flags discrepancies. Only once all stakeholders have confidence in the new solution is FileMaker switched off. No big-bang go-live, and no dependency on a single migration weekend that simply has to succeed.

Replace Access database Replace legacy software Custom software development Platform migration

The four phases of a FileMaker migration

Our approach is iterative and transparent. Each phase delivers a testable deliverable, so you can steer or revisit the scope at any point — without being locked into a fixed end picture agreed in advance.

DDR analysis and scope

We export the Database Design Report from your FileMaker solution and inventory all tables, relationships, layouts, scripts and custom functions. Based on that, we jointly define the migration scope — what carries over one-to-one, what is simplified, and what is dropped.

Schema mapping and proof of concept

We map your FileMaker schema to a relational database (usually PostgreSQL) and build a proof of concept of the most critical module. You see the new UX and performance on real data, and can validate the approach before we start the full migration.

Build and parallel run

We build the complete web app module by module. During the build phase, a data pipeline from FileMaker to the new environment is already running, so we can test against production data at every iteration. Your team continues working in FileMaker; the web app grows alongside the old solution.

Cutover and decommissioning

Once all modules have been delivered and tested, we cut over. Your team then works in the web app; FileMaker remains available read-only for a few weeks as a reference. After that, the Claris Server is decommissioned and the licence costs fall away.

Technologies we use for FileMaker migrations

The choice of technology depends on your situation: the number of concurrent users, the volume of data, requirements for mobile use and existing integrations. We work with proven open-source stacks that will still be maintainable in ten years' time, and keep complexity as low as possible — where something can be built simply, we build it simply.

For data extraction from FileMaker, we use the official DDR export (XML), JDBC and ODBC connectors, ExportFieldContents for container files, and the FileMaker Data API for incremental sync during the parallel run. On the web app side, we opt for TypeScript frameworks (React, Astro, Next.js or Remix) with a Node.js or Python backend, connected to PostgreSQL or MySQL. Hosting preferably in EU data centres for GDPR compliance.

FileMaker DDR (XML) JDBC / ODBC FileMaker Data API PostgreSQL MySQL TypeScript React Node.js Python REST / GraphQL Docker PWA

Concrete use cases we have modernised from FileMaker

FileMaker is used in very different corners of a business. The three patterns below are what we see most often among SMEs that want to start a migration.

Order management and quotation tooling

A wholesaler that has managed orders, quotes and delivery notes in FileMaker for years is struggling with integrations to its webshop and accounting. We rebuild the existing workflow, from incoming order through picking to invoice, as a web app with a REST integration to the ERP. Field sales staff will work via a PWA on their phone and tablet, and the warehouse manager sees stock levels in real time.

Customer administration and CRM development

A service provider has a FileMaker CRM with customers, contact moments, contracts and invoices, built up over twelve years. The migration delivers a web app with the same data models, but with modern search, automated e-mail templating, an integration with the telephone exchange and a customer portal where customers can view their own details and invoices.

Project planning and time registration development

An engineering firm uses FileMaker for projects, tasks and hours. The new web app keeps the same structure, with projects broken into phases and tasks with estimated and logged hours, but adds a Gantt view, automatic invoicing based on contract types, and a mobile app for logging hours on the go. Reporting to clients now takes place within the web app itself.

Inventory management and logistics development

A manufacturing company runs its stock, purchasing and quality control in FileMaker. We are migrating to a web app with barcode scanning on the shop floor (a PWA on Android scanners), real-time dashboards for the production manager and API integrations with supplier portals. We rebuild the FileMaker reports as BI views in the new environment.

Why choose Appfront for your FileMaker migration

Respect for what works

Your FileMaker solution didn't come about by accident. We start by understanding why the platform was chosen at the time, and which logic is now critical to your operations. No migration where half the functionality is lost just because it had to be 'modern'.

Parallel run rather than big bang

We don't believe in migrations that hinge on a single weekend. Our approach is always parallel: the old and new solutions run side by side, with daily data sync. Your team can get comfortable, compare and adjust before FileMaker is switched off.

A maintainable stack for the long term

We build on widely used open-source frameworks for which developers will still be available next year. No niche technology, no vendor lock-in. You can change supplier in five years without panic, and we are simply confident enough that we will still be around in five years.

Schedule a no-obligation conversation Developing a proof of concept Building a web app

Frequently asked questions about FileMaker migration

Do I really need to move away from FileMaker now?

Not necessarily today. Existing Claris customers can renew their licences, and the platform will technically keep running for years. The question is rather: how long do you want to depend on a platform where Claris no longer sells new server licences to new customers, and where the pool of developers is shrinking? We advise mapping out the migration path in any case, even if you want to stay for another two to three years.

Will I lose data or history during the migration?

No. Our migration approach is always reversible up to the cutover moment. During the parallel run, FileMaker remains fully operational, and after cutover the old environment stays available read-only for several weeks. Data validation is carried out per table: we compare record counts, checksums on critical fields, and spot checks on edge cases. Only once all data is identical in the new environment does the old one go.

How long does a FileMaker migration roughly take?

That depends on the size of your solution. A small departmental tool (twenty tables, fifty scripts, one team) can take six to twelve weeks. A mature business solution (a hundred tables, five hundred scripts, several teams and integrations) typically takes six to twelve months, including a parallel run. We work in two-week iterations so you can see progress at every step.

What happens to our current FileMaker scripts and custom functions?

We analyse them via the DDR export and group them by functional purpose. The relevant logic is then rebuilt in the backend of the new web app, usually in TypeScript or Python, with unit tests for critical rules. Obsolete scripts (from retired processes, debugging routines, one-off imports) are not carried over. This often removes twenty to forty per cent of the script file.

Does the new web app perform as fast as FileMaker on the LAN?

In practice, it is almost always faster with larger datasets. FileMaker is extremely quick on small sets over a fast LAN, but it loses ground with millions of records or complex calculation fields. A well-indexed PostgreSQL database behind a modern web app continues to perform consistently well into the tens of millions of records. For mobile and remote users, a web app is generally considerably faster than FileMaker WebDirect.

Can we migrate modules one at a time rather than everything at once?

Yes, and that is often the wisest approach. For example, we can first migrate customer administration and CRM, then order processing, then reporting. During the transition, both systems run via a data sync, so customer data remains consistent between the web app and the part of the FileMaker solution still in use. This lowers the risk and spreads the investment.

What if we use third-party FileMaker plugins?

We inventory plugins such as BaseElements, MBS, 360Works or Productive Computing during the DDR phase. For each plugin, we determine whether the functionality is needed in the web app. There is usually an open-source or cloud equivalent (sending email, generating PDFs, OCR, FTP/SFTP). The plugin functionality is rebuilt in the backend, so that after migration you no longer incur plugin licence costs.

Roughly what does a FileMaker migration cost?

The investment depends on the scale of your solution and the improvements you want to make to UX and functionality. We always start with a DDR analysis and a proof of concept on a single module. This gives you a realistic picture of scope, timeline and costs before you commit to a full project. There is no fixed project price in advance, but you will receive a transparent hourly estimate per phase.

Ready to future-proof your FileMaker solution for the next ten years?

Schedule a no-obligation conversation. We will review your current FileMaker environment together, discuss a realistic migration path and, if you wish, start with a DDR analysis to make the scope and timeline clear.

Schedule a conversation