How to prepare legacy software for web, mobile and AI

Your FileMaker ERP runs the business. It holds years of customer data, order history, pricing logic, and workflow rules that took a decade to get right. But your field team can't use it on a tablet, your web shop can't talk to it, and your competitors are already automating tasks with AI. Starting over isn't an option — but standing still isn't either.

This article walks you through exactly how to modernize a legacy desktop ERP for web, mobile, and AI — without touching the core system that keeps the lights on.

Why does your desktop ERP feel like a dead end?

Most companies in this position didn't make a bad technology choice. They made a reasonable one — ten or fifteen years ago. A FileMaker ERP was fast to build, easy to customize, and genuinely fit the business at the time. The problem isn't the system itself; it's the gap between what it was designed for (a single office, a desktop PC, a local network) and what the business now demands.

The symptoms show up in very specific, painful ways:

• A warehouse worker needs to confirm a delivery from the floor, but the system only runs on the office PC, so someone has to walk back and forth — or worse, write it on paper and enter it later.
• An order comes in through your webshop and gets re-typed by hand into FileMaker — every single order, every single day — because there's no API to connect them.
• A manager asks "what's our margin on that product category this quarter?" and the answer takes two hours of manual exports to Excel.
• A new AI tool promises to automate your quote generation, but it has no way to read or write your ERP data.

None of these are FileMaker problems specifically. They're architectural problems: the system was built as a closed desktop application, and it needs to become an open, connected platform.

What does "modernizing without replacing" actually mean?

The instinct, when a system feels outdated, is to throw it out and start over. That instinct is almost always wrong — and expensive. The business logic locked inside a mature ERP is genuinely valuable. It encodes decisions, exceptions, and hard-won rules that nobody fully documented. Rebuilding from scratch means re-learning all of that at great cost, usually while the business is still running on the old system.

Modernizing without replacing means treating your legacy system as the core engine — and building modern capabilities around it as separate, connected layers:

1. An API layer that exposes your data and business logic to the outside world.
2. A web and mobile interface layer that gives users a modern experience without rewriting the logic underneath.
3. An AI layer that reads from and writes to your data to automate tasks and surface insights.

Each layer can be built and deployed independently. You don't have to do all three at once.

This is the same philosophy described in our broader guide on how to modernize business software without starting over — and it applies directly here.

Step 1: Expose your legacy data through secure APIs

An API (Application Programming Interface) is the bridge between your existing system and everything else. Without one, your ERP is an island. With one, it becomes the authoritative data source that every other tool — your webshop, your mobile app, your AI tools — can talk to.

What this looks like in practice

FileMaker has a built-in REST API called the FileMaker Data API. It lets external systems read and write records securely over HTTPS. But simply turning it on isn't enough — you need to design the API layer thoughtfully.

Practical steps:

1. Audit your data model first. Map out which tables, fields, and relationships matter to external systems. You don't need to expose everything — just the data that mobile users, web applications, or AI tools will actually need.
2. Define clean endpoints. Rather than exposing raw FileMaker table structures (which are often messy and internal), build a thin API wrapper that presents clean, logical endpoints. For example: GET /orders/{id} instead of a raw FileMaker record dump.
3. Implement authentication and access control. Use token-based authentication (OAuth 2.0 or API keys) and define which external systems can access which data. A webshop should be able to read product stock and write new orders — but not read customer payment terms.
4. Version your API from day one. When you change your data model later, you don't want to break every connected system at once. A versioned API (/v1/orders) gives you room to evolve.
5. Log every API call. If something goes wrong — a sync fails, data gets corrupted — you need a complete audit trail. Log request timestamps, endpoints called, payloads sent, and response codes.

Common gotcha

The FileMaker Data API works well, but it has rate limits and quirks around relationships and portals. For high-volume integrations (thousands of calls per day), consider building a lightweight middleware layer — a small Node.js or Python service that sits between FileMaker and the outside world, handles caching, queuing, and error retry logic, and abstracts away FileMaker-specific behavior from your external systems.

Step 2: Add web and mobile interfaces without replacing the core

Once your data is accessible via API, you can build modern front-ends that connect to it — without touching the FileMaker logic underneath.

Web access

A web interface built on top of your FileMaker API can give office staff, remote workers, and even customers access to exactly the right data and workflows — in a browser, on any device.

This is not the same as FileMaker WebDirect (FileMaker's own browser-based access tool). WebDirect renders your existing FileMaker layouts in a browser, which is quick to set up but inherits all the limitations of the desktop design — it's not truly responsive, it doesn't work well on mobile, and it can be slow over the internet.

A purpose-built web front-end, by contrast, is designed from scratch for browser use. It calls your FileMaker API, presents data in a clean, responsive layout, and only exposes the specific workflows each user role needs.

Example: A logistics manager gets a dashboard showing today's shipments and exceptions. A warehouse worker gets a simple pick-list screen optimized for a tablet. A customer gets a self-service portal to track their orders. All three talk to the same FileMaker ERP via API — but each sees only what they need.

Mobile access

Mobile is where desktop-only ERPs fail most visibly. A field technician finishing a job on-site can't open a FileMaker client on their phone. But they can open a web app or a native mobile app that writes back to FileMaker through the API.

Practical steps:

1. Start with the highest-pain mobile workflow. Don't try to mobilize your entire ERP. Find the one workflow that costs the most time because it can't be done on mobile — delivery confirmations, on-site service reports, inventory counts — and build that first.
2. Design for intermittent connectivity. Mobile users lose signal. Build offline capability into mobile interfaces where it matters: cache the data the user needs, let them work offline, and sync when connectivity returns.
3. Use progressive web apps (PWAs) before native apps. A PWA is a web application that behaves like a native app — it can be added to the home screen, works offline, and sends push notifications. For most business workflows, a PWA is faster to build and easier to maintain than a native iOS/Android app.
4. Integrate with mobile hardware where it adds real value. Barcode scanning, camera-based document capture, GPS location tagging — these are genuinely useful in warehouse, logistics, and field service workflows. A mobile web app can access all of these through the browser.

Step 3: Add AI as a separate layer on top of your existing data

AI is the part that sounds most intimidating — and is actually the most tractable once your data is accessible via API. You don't need to rebuild your ERP to add AI. You need to give AI tools access to your data.

What kinds of AI are actually useful in a business ERP context?

• Predictive analytics: "Which orders are likely to be late based on current stock levels and supplier lead times?"
• Automated document processing: Reading supplier invoices, delivery notes, or customer purchase orders and automatically creating or matching records in FileMaker.
• Natural language querying: A manager types "show me all orders from last month where margin was below 10%" in plain English, and an AI translates that into a FileMaker query and returns the results.
• Anomaly detection: Flagging unusual patterns — a customer's order volume drops 80% suddenly, a product's cost price jumps 40% — for human review.
• AI-assisted data entry: Suggesting values, auto-completing fields, or flagging likely data entry errors before they're saved.

How to add AI without rewriting your system

The key principle: AI should be a consumer of your existing data, not a replacement for your existing logic. Your FileMaker system continues to be the source of truth. AI tools read from it, process, and write results back — but they don't replace the business rules already encoded in FileMaker.

Practical steps:

1. Choose a specific, high-value AI use case first. Don't try to "add AI" in the abstract. Pick one workflow: automated invoice matching, predictive reorder suggestions, or natural language reporting. Prove the value there before expanding.
2. Connect your AI tool to your API. Most AI platforms (OpenAI, Azure AI, Google Vertex AI) can call REST APIs directly. Your FileMaker Data API endpoint becomes a data source for the AI. For write-back operations, the AI calls your API to create or update records.
3. Keep a human in the loop for high-stakes decisions. AI suggestions for automating a routine re-order are low-risk. AI suggestions for flagging a customer as a credit risk are high-stakes. Design your AI layer so that consequential actions require human confirmation before they're committed to the ERP.
4. Build an AI middleware layer for complex workflows. If your AI use case involves multiple steps — read data from FileMaker, call an external AI model, process the response, write back to FileMaker — build a small orchestration service to manage that flow. This keeps your FileMaker system clean and avoids embedding AI logic directly in FileMaker scripts.
5. Monitor AI outputs continuously. AI models drift over time. A predictive model trained on last year's data may perform poorly after a supply chain disruption changes your patterns. Log AI outputs, compare predictions to outcomes, and schedule periodic model reviews.

A concrete example end-to-end

A distribution company uses FileMaker to manage purchasing. Every week, a buyer manually reviews stock levels, checks lead times, and creates purchase orders. The process takes half a day.

With an AI layer added:

• A scheduled job calls the FileMaker API and reads current stock levels, historical sales velocity, and open purchase orders.
• An AI model predicts which SKUs will hit reorder point within the next 14 days.
• It drafts suggested purchase orders and writes them back to FileMaker as "draft" status records.
• The buyer reviews the drafts in FileMaker — approving, adjusting, or rejecting each one — and confirms. Total time: 20 minutes instead of four hours.

The ERP didn't change. The business logic didn't change. An AI layer was added on top, using the API.

Checklist: Is your legacy system ready to modernize?

Before starting, run through this diagnostic. The more "no" answers you have, the more foundational work comes first.

• Is your FileMaker Data API (or equivalent) enabled and reachable over HTTPS?
• Is your data model documented — do you know what each key table and field actually means?
• Are your critical business workflows documented (not just the happy path — the exceptions too)?
• Do you have a test/staging environment that mirrors production? (Never build integrations against live data.)
• Is user authentication centralized (e.g., via Active Directory or SSO), or does everyone log in with shared credentials?
• Are your data quality standards acceptable? (AI and integrations amplify bad data — duplicate records, inconsistent formats, and missing values become much more painful at scale.)
• Do you have logging in place for current system activity? (You'll need a baseline to compare against after changes.)
• Is there an internal owner for this modernization project — someone with both business knowledge and technical authority?

FAQ

Can I modernize only part of the system and leave the rest alone? Yes — and that's usually the right approach. You don't need to expose every module through an API or mobilize every workflow on day one. Start with the highest-pain or highest-value area, prove the model, then expand incrementally.

Will adding a web or mobile layer make my FileMaker system slower? Not if it's designed correctly. The API layer should handle its own authentication and connection pooling. For high-volume scenarios, a caching layer (e.g., Redis) between the API and FileMaker prevents every web request from hitting the database directly.

Do I need to upgrade my version of FileMaker first? The FileMaker Data API is available from FileMaker 17 onwards. If you're on an older version, an upgrade may be a prerequisite. That said, you can also build a middleware layer that uses ODBC or legacy XML APIs as a bridge — it's more work, but it avoids forcing an immediate platform upgrade.

How long does a project like this typically take? A focused first phase — one clean API layer plus one web or mobile interface for one workflow — typically takes 6 to 12 weeks depending on data model complexity and the state of existing documentation. Adding an AI feature on top of that is another 4 to 8 weeks for a well-scoped use case.

What's the biggest risk? Data quality. Systems that have been running for years in isolation often have inconsistencies that nobody noticed because humans worked around them. When you connect external systems or AI tools, those inconsistencies surface immediately. Budget time for a data audit before building integrations.

Is this approach reversible? Yes. Because you're adding layers rather than replacing the core, you can always roll back or replace an individual layer without taking down the whole system. The FileMaker ERP continues to run regardless of what happens with the API layer or the AI tools on top of it.

---

If your business is at exactly this crossroads — a FileMaker system that's working but can't reach the web, mobile users, or modern AI tools — Loggix can help you map a practical path forward. Whether that means building a secure API layer on top of your existing ERP, developing a tailored web or mobile interface for your specific workflows, connecting your FileMaker data to external platforms through custom integrations, or adding AI automation to routine processes, the work starts with understanding your current system deeply before touching a line of code. If you'd like to think through the right first step for your situation, that's exactly the kind of conversation we're set up for.