FileMaker to the Cloud: Approaches for Local Apps

FileMaker has been a reliable workhorse for Australian businesses for decades. It does genuinely useful things: flexible databases, layouts that non-technical staff can modify, scripts that automate repetitive work, and a development model that lets one person build a sophisticated business application without a team behind them.

The problem isn't that FileMaker doesn't work. The problem is that it was built for a world of local servers and desktop clients, and business needs have moved on. Remote work, mobile access, cloud integration, and the expectation that systems talk to each other — none of these sit comfortably with a traditional FileMaker deployment.

At some point, almost every business running a local FileMaker system arrives at the same question: how do we get this to the cloud?

There are five main approaches, ranging from a straightforward hosting change to a complete rebuild. The right one depends on how much you need to change, how much you can spend, and how much disruption you can absorb.

Why this comes up

Traditional FileMaker deployments run on a FileMaker Server sitting on a local machine or NAS, with FileMaker Pro desktop clients connecting over the network. That works reliably in a single-office environment with stable hardware and on-site IT support.

It stops working well when circumstances change:

• Remote work. Staff working from home can technically VPN in, but performance is poor and it creates IT overhead. FileMaker was never designed for sustained remote use.
• Multiple locations. A second office means WAN or VPN linking back to the main server. Latency becomes a real problem for record-locking and scripted workflows.
• Mobile access. FileMaker Go exists for iPad and iPhone, but it requires a live connection back to the server — which means VPN or WebDirect, both of which have limitations in practice.
• Cloud integrations. Connecting FileMaker to Xero, Salesforce, or any modern SaaS platform requires custom scripting and the FileMaker Data API. Possible, but not straightforward.
• Ageing hardware. The server running the database is approaching end of life, and nobody wants to invest in new on-premise equipment for a system they're uncertain about long-term.
• Key-person dependency. The person who built and maintains the system leaves. The system still works, but nobody fully understands it, and any change feels risky.

Your options at a glance

There are five main paths from local FileMaker to something cloud-accessible. They range in complexity, cost, and how much of your existing investment you preserve:

1. Claris FileMaker Cloud — Move your FileMaker Server to Claris's managed cloud hosting. Same application, different infrastructure.
2. Self-hosted on a cloud VM — Run FileMaker Server yourself on AWS, Azure, or similar. More control, lower ongoing cost at scale, but you own the infrastructure.
3. FileMaker Data API bridge — Keep FileMaker as your database but build modern web or mobile frontends that talk to it via REST API.
4. Progressive extraction — Gradually migrate modules out of FileMaker into a web platform using the strangler fig pattern. Low risk, longer timeline.
5. Full replacement — Rebuild the application entirely on a web-native stack. Highest cost and risk, but delivers the cleanest long-term result.

Option 1: Claris FileMaker Cloud

Claris FileMaker Cloud is the official hosted solution from the company that makes FileMaker. Your server moves to AWS infrastructure managed by Claris, accessed via the Claris ID login system. Desktop users still use FileMaker Pro. Mobile users use FileMaker Go. Browser users use WebDirect.

What it solves

• Eliminates the local server and the hardware refresh decision
• Enables remote access without a VPN
• Removes infrastructure maintenance — Claris handles OS updates, backups, and availability
• Straightforward migration with minimal application changes required

What it doesn't solve

• You remain on FileMaker — platform dependency continues, as does the need for FileMaker expertise to maintain and modify the system
• WebDirect (browser access) works, but it is not a native web app; performance can be sluggish and not all FileMaker features behave identically
• Licensing costs are subscription-based and per-user — for larger teams these add up quickly
• Integration with external SaaS platforms is no easier than before

When it makes sense

Claris FileMaker Cloud is the right choice when your primary problem is the local server, not the FileMaker platform itself. If the application works the way your business needs it to, and the only issue is access from anywhere, this is the simplest move with the least disruption.

Option 2: Self-hosted on a cloud VM

FileMaker Server runs on Windows Server or macOS Server. Both run on a cloud virtual machine. You provision an EC2 instance on AWS (or equivalent on Azure or Google Cloud), install the OS, install FileMaker Server, restore your database, and configure networking. The result: FileMaker Server in the cloud, under your control.

What it solves

• Same remote access benefits as Claris Cloud
• Lower per-user cost at scale compared to Claris Cloud subscriptions
• Full control over the VM, backups, networking, and security configuration
• Easier to integrate with other cloud services (S3 for container field exports, RDS for data sync, etc.) if you're already in AWS

What it doesn't solve

• Platform dependency: you're still on FileMaker
• Infrastructure responsibility: you manage OS patching, FileMaker Server updates, backups, and monitoring
• WebDirect performance limitations still apply
• FileMaker Pro client software still required on staff desktops

When it makes sense

Self-hosted VM suits teams with some internal IT capability, larger user counts where per-user pricing becomes expensive, or businesses that want the flexibility that Claris Cloud doesn't offer — custom networking, direct database access for reporting tools, or integration with other cloud services they already operate.

Option 3: FileMaker Data API bridge

FileMaker Server 17 and later includes a REST API called the FileMaker Data API. It lets any HTTP-capable application read, write, search, and delete records in your FileMaker database. You keep FileMaker as the database backend but build modern interfaces on top of it.

What this enables

• A custom web application that staff use in a browser — no FileMaker Pro client required for those users
• A native mobile app (iOS or Android) built with React Native or Flutter, reading and writing FileMaker data directly
• Automation integrations: Make.com, Zapier, or custom webhooks pulling and pushing data as events occur
• Reporting dashboards (Power BI, Metabase, custom) consuming live FileMaker data without manual exports

Limitations to be aware of

• FileMaker scripts and calculations cannot be called directly through the Data API — business logic embedded in FileMaker scripts may need replication in the new frontend or a middleware layer
• You still need FileMaker Server running (cloud or on-premise) as the backend
• Schema changes still require FileMaker expertise
• High-concurrency workloads can hit API performance limits — FileMaker's REST API was not designed for thousands of simultaneous requests

When it makes sense

The Data API bridge suits situations where your FileMaker data model is sound and the data is reliable, but the interface is the problem — desktop-only, outdated layouts, no mobile support, or difficult to integrate with modern tools. You preserve your data investment and FileMaker's scripting engine while delivering a modern face to users.

Option 4: Progressive extraction

The strangler fig pattern applied to FileMaker: instead of replacing the whole system at once, you migrate one module at a time. A new web application is built alongside FileMaker. Functionality moves across piece by piece — first reports, then data entry forms, then the most complex workflows. FileMaker continues running throughout and is only decommissioned once nothing remains in it.

How it works in practice

1. Identify natural seams. FileMaker applications usually have distinct modules: customer records, job management, invoicing, stock control, reporting. Find boundaries where functionality can be cleanly extracted.
2. Choose the target platform. Decide on the web technology stack for the replacement. A REST API backend with a React or Vue frontend is common. Pick boring, well-supported tools your team can maintain.
3. Start with low-risk modules. Reporting is often a good first target — high value for users, lower complexity than data entry, and easy to verify that outputs match.
4. Sync data during transition. While both systems run, you need a sync layer to keep data consistent across FileMaker and the new platform. This is the hardest part and needs careful design.
5. Retire FileMaker module by module. As each piece migrates and proves stable in production, disable the corresponding FileMaker layouts and scripts.

Advantages

• Lowest risk path to full modernisation — each step is small and reversible
• Delivers value incrementally: users get modern interfaces for migrated modules before the whole project is finished
• If priorities shift or budget is constrained, the partially migrated system still functions
• The team builds confidence in the new platform before the stakes are high

Disadvantages

• Slower. A full migration of a complex FileMaker system can take 12–24 months
• Data sync during transition is complex and needs active management to prevent inconsistencies
• You operate and pay for two systems simultaneously until the migration completes

Option 5: Full replacement

Rebuild the FileMaker application from scratch on a web-native platform. Start from the data model, rewrite the business logic, rebuild the user interface. FileMaker is retired when the new system goes live.

When it makes sense

• The FileMaker application is genuinely unmaintainable — the schema is a mess, years of bolt-on changes have made it brittle, and nobody understands it fully
• Business requirements have changed substantially and the existing logic isn't worth preserving
• A good off-the-shelf product now covers 80%+ of what the custom FileMaker system does
• The business has the budget, the appetite for disruption, and a clear picture of what the replacement needs to do

The risks

• Highest cost and longest initial timeline before users see anything
• Hidden business logic embedded in FileMaker layouts and scripts won't reveal itself until after go-live
• Big-bang cutover maximises disruption — if the new system isn't right on day one, there's no fallback
• Users who know the old system well often resist the new one, regardless of quality

Choosing the right approach

The most common pattern we see: businesses start with Claris Cloud or a cloud VM to solve the immediate access problem, then add a Data API layer to enable integrations they couldn't do before, and then eventually begin progressive extraction as they recognise that the FileMaker platform itself is the constraint. Planning for that trajectory from the start avoids rework.

Data and integration considerations

FileMaker's data model

FileMaker databases often have data model quirks that make migration non-trivial. Relationships in FileMaker work differently to standard relational databases — a FileMaker relationship is as much a presentation-layer concept as a data concept. If you're moving to PostgreSQL, SQL Server, or a cloud database, you'll need to rationalise and normalise these relationships as part of the migration.

Container fields — FileMaker's way of storing files, images, and documents — require special handling. They may be stored inline in the database or as file references pointing to the server filesystem. Extracting them into cloud object storage (S3, for example) needs a dedicated migration step that is separate from the record migration.

Scripts and business logic

FileMaker scripts are where a large amount of business logic lives. This logic is not easily portable — it is written in FileMaker's own scripting language, embedded in layouts and triggered by layout events that don't exist in a web context. Cataloguing this logic before any migration work starts is essential. Many businesses discover they don't fully understand what their own FileMaker system does until they try to migrate it.

Data quality

FileMaker's flexible schema means data quality is often inconsistent. Fields that should contain dates sometimes hold free text. Required fields have blank values. A single field might serve three different purposes depending on which layout a record was entered from. Budget for data cleansing as part of any migration — moving dirty data into a new system just relocates the problem to a shinier database.

Existing integrations

If your FileMaker system already connects to other platforms — through the Data API, through ESS (External SQL Sources), or through third-party plugins — document these integrations before changing anything. They are easy to break silently, and the breakage may not surface immediately.

FAQ

Can FileMaker WebDirect replace the desktop client for cloud access?

Partially. WebDirect lets users open FileMaker layouts in a browser without installing FileMaker Pro. It works, but not without limits: not all FileMaker features behave the same in WebDirect, performance is generally slower than the native client, and complex scripts or layouts can be unreliable. It's adequate for light or occasional access, but not a full replacement for power users who are in the system all day.

How much does a FileMaker-to-web migration typically cost?

It depends heavily on application complexity and the approach chosen. A Data API bridge that exposes existing FileMaker data to a simple web interface might cost $15,000–$40,000. A full replacement of a complex multi-module system can run $100,000–$300,000 or more. Progressive extraction sits in between, with costs spread over time rather than front-loaded. Claris Cloud and self-hosted VM migrations are primarily infrastructure costs, not development costs.

Do we still need FileMaker licences if we move to the cloud?

If you move to Claris Cloud or a cloud VM, yes — FileMaker Server and client licences remain a requirement. If you build a Data API bridge, you need FileMaker Server but may need fewer client licences if fewer staff use FileMaker Pro directly. If you fully replace the system, you can eventually retire all FileMaker licences — though it's worth keeping the system running in read-only mode for a period after cutover so users can reference historical data while they adjust.

Can we use no-code platforms to replace a FileMaker app?

For simpler FileMaker applications, yes. Platforms like Bubble, Glide, or Airtable can replicate basic data capture and workflow applications without custom development. The challenge is that FileMaker apps are usually custom-built to handle specific business needs — no-code platforms cover standard use cases well but tend to hit limitations on complex business logic, conditional workflows, or unusual reporting requirements. A scoping exercise will tell you quickly whether no-code fits your situation or whether you need a custom build.

What if nobody fully understands our FileMaker system?

This is more common than it should be. Start with a system audit: interview every person who uses the system, observe how they actually use it, and document what it does by watching its behaviour rather than relying on documentation that is likely years out of date. Identify the business rules embedded in scripts and calculations. This discovery phase takes longer than businesses expect, but skipping it guarantees you will miss something critical in the migration. Budget extra time for it.

Kasun Wijayamanna Founder & Lead Developer

Postgraduate Researcher (AI & RAG), Curtin University - Western Australia

View profile →