How to combine an existing back end with a modern front end

Your FileMaker system runs the business. It holds years of carefully tuned business logic, validated data, and process knowledge that nobody has fully documented anywhere else. But the interface looks like it was designed in 2008 — because it was. Users are complaining, new hires need days of training just to navigate it, and mobile access is practically non-existent.

This article explains exactly how to layer a modern front end on top of a mature FileMaker back end — without rewriting your business logic, without migrating your data, and without the six-month big-bang project that keeps getting postponed.

---

Why do businesses keep postponing this?

The hesitation is rational. Your FileMaker ERP has been running reliably for years. It calculates margins correctly, enforces stock rules, triggers the right workflows. Nobody fully understands every script and relationship anymore — certainly not well enough to recreate it from scratch in a new system. So the safest-feeling option is to do nothing.

But doing nothing has a cost too: sales reps who can't look up stock on their phone, customers expecting a self-service portal that doesn't exist, and a UI so cumbersome that data quality slowly degrades because people find workarounds.

The good news: you don't have to choose between "keep the old interface" and "rebuild everything." There is a third path.

---

What does "combining a back end with a front end" actually mean?

In architecture terms, you are decoupling the presentation layer from the data and logic layer. Instead of FileMaker's own layout engine rendering the interface, a separate application — a web app, a React front end, a mobile app — handles what the user sees and does. FileMaker continues to do what it already does well: store data, enforce business rules, run calculations, manage relationships.

The two layers talk to each other through an API — specifically FileMaker's Data API, which exposes your FileMaker database as a set of HTTP endpoints. Your modern front end calls those endpoints to read records, create new ones, trigger scripts, and apply finds and sorts — all without the user ever knowing (or caring) that FileMaker is underneath.

This approach has a proper name in software architecture: the strangler fig pattern. You grow a new system around the outside of the old one, gradually replacing what needs replacing, while the core keeps running. It is the opposite of a rewrite.

---

How does FileMaker's Data API actually work?

FileMaker Server (version 17 and later) ships with a built-in REST API called the FileMaker Data API. It lets any HTTP-capable application authenticate, query layouts, read and write records, and execute FileMaker scripts — all over standard JSON.

A simplified flow looks like this:

1. The front end sends a login request → FileMaker returns a session token.
2. The front end requests records from a named layout → FileMaker returns JSON with field values and portal rows.
3. The user fills in a form and submits → the front end sends a POST or PATCH request → FileMaker writes the record and runs any associated OnRecordCommit triggers or scripts.
4. A FileMaker script runs a complex multi-step calculation (stock reservation, invoice generation, etc.) → the front end simply calls a "run script" endpoint and waits for the result.

This means your existing FileMaker scripts keep running exactly as they always have. The business logic does not move. Only the visual layer changes.

Practical note: FileMaker layouts matter more than people expect when using the Data API. The fields and portals visible on the layout you expose determine what data is available to the front end. Designing clean "API layouts" — stripped of visual elements, containing exactly the fields you need — is one of the first things to get right.

---

What front-end technology should you use?

There is no single right answer, but here are the realistic options and when each makes sense:

Web application (React, Vue, or similar)

Best for: internal tools, customer portals, dashboards, order entry screens. Runs in any browser, no installation required. Scales well when multiple teams need different views of the same FileMaker data.

Progressive Web App (PWA)

Best for: field staff who need offline capability and a mobile-first experience without going through an app store. A PWA can cache data locally and sync when back online — useful for delivery drivers checking off items or technicians logging service calls.

Native or cross-platform mobile app (React Native, Flutter)

Best for: customer-facing apps or high-performance mobile experiences where a browser-based UI is not good enough. Higher build cost, but the FileMaker Data API back end is identical.

Low-code front-end tools (Webflow + custom code, Bubble, etc.)

Best for: simple portals where speed of delivery matters more than full flexibility. Works, but hits limits quickly once business logic gets complex.

For most FileMaker ERP modernisations, a React or Vue web application hits the right balance of flexibility, developer availability, and long-term maintainability.

---

Step-by-step: how to run a front-end modernisation project

Step 1 — Map the real pain points, not the full feature list

Before touching any code, spend time with actual users. Which screens do they use every day? Where do they lose time? A warehouse manager who has to click through five FileMaker layouts to confirm a shipment is a better starting point than a rarely-used report screen. Prioritise ruthlessly: the first version of your new front end should do less than FileMaker, not more.

Step 2 — Audit your FileMaker layouts and scripts

Identify which layouts and scripts the new front end will need to interact with. Look for:

• Scripts that mix UI logic (Go to Layout, Show Custom Dialog) with business logic (inventory updates, email triggers). You will need to split these — the UI parts move to the front end, the business logic stays in FileMaker.
• Calculated fields that are actually needed in the API response vs. those that were purely for display.
• Any logic that depends on FileMaker's current user account — you will need to think about authentication mapping.

Step 3 — Design your API layouts

Create dedicated FileMaker layouts for the Data API. These layouts should:

• Contain only the fields your front end actually needs (no decorative merge fields, no portals for UI-only purposes).
• Use consistent, descriptive field names — the JSON keys the Data API returns are the field names as they appear on the layout.
• Include portals for related data you need in a single API call (e.g., order lines on an order record).

Step 4 — Build a thin API middleware layer

Do not call the FileMaker Data API directly from the browser. Instead, build a small Node.js or Python middleware service that:

• Handles FileMaker session management (tokens expire; your front end should not deal with that).
• Translates FileMaker's JSON structure into cleaner, front-end-friendly shapes.
• Adds authentication and authorisation (your users log into the web app; the middleware maps that to a FileMaker account).
• Gives you a place to add caching, rate limiting, and logging without touching FileMaker.

This middleware is a small investment that pays for itself within weeks.

Step 5 — Build the front end in vertical slices

Do not try to replace all of FileMaker at once. Pick one workflow — say, the order entry screen — and build it end-to-end: design, front-end components, API calls, error handling, user testing. Ship it. Then move to the next slice. This keeps risk low, delivers visible value early, and lets you learn before you commit to patterns across the whole application.

Step 6 — Run both interfaces in parallel during rollout

FileMaker and the new front end can run side by side. Power users who know FileMaker can stay on it during the transition. New users onboard directly to the modern interface. This parallel period also acts as a live integration test — if something behaves differently in the new front end, you catch it before it matters.

Step 7 — Migrate users and sunset the old interface gradually

Once confidence is high, set a clear sunset date for the FileMaker interface for each user group. Avoid letting "we'll keep the old one just in case" drag on indefinitely — two interfaces mean double the maintenance.

---

What are the most common mistakes in this kind of project?

Exposing too much of the FileMaker structure directly. If your API layouts mirror your FileMaker table structure one-to-one, your front end becomes tightly coupled to your database design. Any refactoring in FileMaker breaks the front end. Design your API responses around what the front end needs, not how FileMaker stores it.

Skipping the middleware layer. It's tempting to call the Data API directly from JavaScript. This works in a prototype but creates security problems (your FileMaker credentials end up in the browser) and makes session management a nightmare.

Trying to replicate every FileMaker feature on day one. FileMaker's interface has accumulated years of features, reports, and edge cases. A modern front end that tries to match all of it on launch will take years and disappoint everyone. Ship a focused, fast v1.

Underestimating the UI/UX design work. The biggest opportunity in this project is not just moving pixels from FileMaker to a browser — it is the chance to redesign the experience entirely. Bring in UX design time. Users will notice the difference more than they notice the technology.

Forgetting about offline and connectivity. FileMaker desktop clients are tolerant of network hiccups. A web app calling a remote API is not. Design your new front end with connectivity failure in mind from the start, especially for warehouse, field, or production floor use cases.

---

Real-world example: order management modernisation

A wholesale distributor runs their entire order management process in FileMaker — customer records, product catalogue, stock levels, order entry, and invoicing. The FileMaker system is accurate and trusted. But:

• Sales reps in the field cannot place orders from their phones.
• Customers call in to ask about order status because there is no portal.
• New staff take three weeks to learn the FileMaker interface.

The solution is not to replace FileMaker. Instead:

1. A React web application is built for order entry — clean, mobile-responsive, role-specific views for sales reps vs. internal staff.
2. A customer-facing portal (separate React app, same middleware) lets customers log in, see their order history, and check delivery status.
3. A Node.js middleware layer sits between both front ends and the FileMaker Data API, handling auth, session tokens, and data shaping.
4. FileMaker continues to run all pricing logic, stock reservation, and invoice generation — unchanged.

Time to first production release: twelve weeks. FileMaker rewrite: not needed.

---

Checklist: are you ready to start a front-end modernisation?

• You have FileMaker Server (not FileMaker Go or a peer-to-peer setup) — the Data API requires it.
• Your FileMaker version is 17 or later (Data API availability).
• You have identified the 2-3 workflows that cause the most daily friction.
• You have a FileMaker developer who can create and maintain API layouts and refactor scripts.
• You have (or can access) a front-end developer with React, Vue, or similar experience.
• You have mapped which FileMaker scripts mix UI logic with business logic — and are prepared to split them.
• You have a plan for authentication: how will web app users map to FileMaker accounts?
• You have agreed on a parallel-running period before sunsetting the old FileMaker interface.
• You have stakeholder buy-in to ship a focused v1 rather than a full feature-parity release.

---

FAQ

Does this approach work with FileMaker Cloud as well as FileMaker Server? Yes. FileMaker Cloud (Claris Cloud) also exposes the Data API. Authentication differs slightly — it uses Claris ID tokens — but the endpoint structure and JSON format are the same.

Can the new front end trigger FileMaker scripts? Yes. The Data API has a "run script" endpoint that executes any FileMaker script by name and passes a parameter. This is how you keep complex business logic — multi-step inventory updates, automated emails, PDF generation — running in FileMaker while the front end simply calls a named action and waits for a result.

What happens if FileMaker goes down — does the whole front end break? Yes, if your front end depends entirely on live FileMaker data, an outage affects it. The middleware layer can add a caching strategy for read-heavy operations (product catalogues, reference data), reducing the blast radius. For write operations, you need to design graceful error states.

Is FileMaker's Data API fast enough for a production web app? For most business applications — order entry, CRM, service management, internal dashboards — yes. The Data API is not designed for high-throughput public-facing applications serving thousands of concurrent users. For a B2B web app or internal tool, performance is generally not a bottleneck if you design your API layouts well and use a caching layer.

Do we need to rewrite our FileMaker scripts? Not most of them. Scripts that are purely business logic (calculate, write, trigger workflows) run unchanged. Scripts that mix UI commands (Go to Layout, Show Custom Dialog, Set Field by Name on a specific layout) will need to be refactored — extract the business logic into a sub-script, and let the front end handle the UI side.

How long does a project like this typically take? A focused v1 — one or two core workflows, new front end, middleware layer — typically takes 8 to 16 weeks depending on the complexity of the FileMaker data model and the number of scripts that need refactoring. A full replacement of the FileMaker interface across all modules is a phased multi-month programme, not a single project.

---

If your FileMaker system is the reliable engine of your business but the interface is holding you back, the combination of FileMaker's Data API, a clean middleware layer, and a modern React or Vue front end is a proven path forward. Loggix builds exactly these kinds of layered solutions — connecting mature FileMaker back ends to modern web and mobile front ends, designing API architectures that keep your business logic intact, and taking on the front-end development work when your team doesn't have that capacity in-house. If you're mapping out the right approach for your situation, that's a good conversation to start early.