How to prevent vendor lock-in without creating unnecessary complexity

Your ERP works — technically. But every upgrade costs a small fortune, every new integration requires a specialist who knows your specific customisations, and switching platforms feels impossible because the entire business is wired into one system. You're not trapped by bad decisions; you're trapped by success: the system grew with the business, and now the business can't grow without the system's permission.

This article explains how to break that dependency systematically — using a modular, API-first architecture with open standards — without throwing away what works or building a new layer of complexity to replace the old one.

What actually causes vendor lock-in — and why customisation makes it worse

Vendor lock-in is not just about proprietary file formats or licensing contracts. In practice, the real trap is tightly coupled architecture: your data model, your business logic, and your user interface are all baked into the same platform, often in the same file or database schema.

With a heavily customised FileMaker system, for example, the scripting layer that calculates margin percentages might live inside the same file as the layout that shows the invoice, which connects directly to the table that stores customer records. Change one element and you risk breaking the others. That coupling is what makes the system expensive to change — not FileMaker itself.

The same pattern appears in over-customised SAP environments, bespoke Salesforce orgs, or any system where years of "just add it here" decisions have created a tangled web of dependencies. The vendor becomes a problem only because the architecture makes it impossible to leave.

Why the obvious solution — rebuilding from scratch — usually fails

The instinct when a system feels unmaintainable is to replace it entirely. In practice, big-bang replacements fail at a high rate for mid-market companies. The reasons are predictable:

• Hidden business logic: rules that employees just "know" are often encoded nowhere except in the old system's scripts or calculation fields. They only surface when the new system gets them wrong.
• Data quality debt: migrating data forces you to confront years of inconsistencies that were masked by the old system's workarounds.
• Operational risk: you cannot run two complete ERP systems in parallel indefinitely, so there's always a dangerous cutover moment.
• Scope creep: once a new system is being built, every department adds requirements. The project doubles in size and time.

The better path is not a replacement — it is a gradual architectural shift that reduces coupling without stopping the business.

What does "modular, API-first" actually mean in practice?

These terms get used loosely. Here is what they mean in a concrete business software context:

Modular means each major function of your business — order management, inventory, invoicing, CRM, reporting — lives in a component that has a defined boundary. It can be built on any technology, changed independently, and replaced without touching the others.

API-first means every component exposes and consumes data through a documented interface (typically REST or GraphQL), not through direct database calls or shared file structures. Nothing reaches into another component's internals.

Open standards means the interfaces, data formats (JSON, CSV, XML), and authentication methods (OAuth 2.0, API keys) are not proprietary. Any competent developer — not just a specialist in your specific platform — can connect to them.

The result: your FileMaker system can keep running the workflows it handles well, while a new web application handles a specific process better suited to a browser. They talk to each other through an API. Neither knows — or cares — what technology the other is built on.

How do you actually make the shift? A practical step-by-step approach

This is not a one-time project. It is a series of deliberate, low-risk steps that each deliver value on their own.

Step 1: Map your current dependencies Before touching any code, document what your system actually does. Which modules depend on which tables? Where is business logic embedded in the UI (a common FileMaker pattern)? Where are data and logic mixed? This map tells you where the coupling is tightest — and where it is safe to start.

Step 2: Identify the highest-pain integration points first Don't start with the most complex module. Start with the integration that costs the most time or money right now. If an order gets entered into FileMaker and then re-typed by hand into Exact Online — every single order, every single day — that is your first target. Build an API connector there. This delivers immediate ROI and introduces the API-first pattern without disrupting core operations.

Step 3: Extract business logic from the UI layer In many legacy systems, calculation logic is embedded in layouts, form fields, or UI scripts. Move that logic into a dedicated layer — a set of server-side scripts, a middleware service, or a documented calculation module — that can be called by any interface. This is the single highest-leverage move to reduce lock-in, because it means the logic survives a UI replacement.

Step 4: Introduce a data exchange layer, not a data migration Rather than migrating everything to a new database, introduce a canonical data model: a shared representation of your core entities (customer, order, product, invoice) that all systems agree on. New systems read and write to this model. Old systems sync to it via API. You can replace individual systems over time without ever doing a full migration.

Step 5: Replace modules by function, not by platform Once the API layer is in place, you can replace individual functions when it makes sense — not because a vendor forces you. The inventory module might move to a specialised WMS. The CRM might connect to HubSpot. The core financial logic might stay in FileMaker for another five years because it works well. Each decision is made on merit, not on architectural necessity.

Step 6: Document everything as you go The reason legacy systems become unmaintainable is not age — it is undocumented decisions. Every API endpoint, every data model change, every business rule extracted from the UI should be documented in a format that doesn't live inside the platform itself (a wiki, a Git repository, an OpenAPI spec).

What about the complexity trade-off? More moving parts means more risk, doesn't it?

This is the legitimate objection to API-first architecture, and it deserves a direct answer: yes, distributing a monolithic system into modules does introduce new types of complexity — network latency, authentication between services, versioning of APIs, and the need to monitor multiple systems instead of one.

But the comparison is not "simple monolith vs. complex distributed system." The comparison is "hidden complexity you cannot manage" vs. "visible complexity you can reason about."

A heavily customised FileMaker ERP looks simple because it's one file. But try to change the customer ID field that 47 scripts and 12 layouts depend on. That hidden complexity is far more dangerous than a well-documented API boundary, because you cannot see it until something breaks.

The key to avoiding unnecessary complexity is not to distribute everything — only the boundaries that actually need to be flexible. A small company does not need microservices. They need two or three well-defined modules with clean interfaces between them. Start with the fewest possible moving parts that still give you the freedom to change one thing without breaking another.

Which open standards are worth adopting, and which are overhyped?

Worth adopting for most mid-market businesses:

• REST APIs with JSON: The lingua franca of business software integration. Every major platform supports it. Not glamorous, but reliable.
• OAuth 2.0: The standard for secure API authentication. Avoid systems that only support username/password API access.
• OpenAPI (Swagger) specs: Document your APIs in a machine-readable format. This single habit prevents more lock-in than any architectural pattern.
• Webhooks: For event-driven integrations ("when an order is created in FileMaker, trigger this action in the warehouse system"), webhooks are simpler and more reliable than polling.

Overhyped for most mid-market businesses:

• GraphQL: Powerful, but adds learning curve and tooling overhead. Worth it only if you have many consumers of the same API with very different data needs.
• Event streaming (Kafka, etc.): Built for very high data volumes. Most SME ERPs don't need it and the operational overhead is significant.
• Full microservices: Designed for large teams deploying independently. A team of 2-3 developers maintaining a business ERP will spend more time managing infrastructure than building features.

A checklist: is your current architecture heading toward lock-in?

Use this to assess where you stand today:

• Business logic is embedded in UI scripts or layout calculations, not in a separate, callable layer
• Integrations with external systems (accounting, logistics, e-commerce) are built via direct database access or file exports/imports rather than APIs
• Only one specific developer or consultancy can safely modify the system
• Upgrading the platform requires testing every custom script and layout manually
• There is no documentation of the data model outside the system itself
• Replacing one module (e.g. the invoicing flow) would require changes in five other unrelated modules
• Users re-enter data between systems because there is no integration

If you checked three or more, the architectural debt is already affecting your ability to move. It doesn't mean you need to rebuild — it means you need a plan.

FAQ

Can we keep using FileMaker while adding an API layer? Yes. FileMaker Data API (available from FileMaker 17 onwards) exposes your existing data over REST, meaning you can connect external systems, web applications, or middleware to your FileMaker database without replacing it. The platform becomes a component in a larger architecture rather than the architecture itself.

How do we handle the transition period when both old and new systems run simultaneously? Define a single system of record for each data entity during the transition. For example: FileMaker is the master for customer data; the new web app is the master for project data. The API layer syncs between them. Avoid bidirectional sync where possible — it creates conflict resolution problems. Assign ownership per entity type, not per system.

How long does this kind of architectural shift typically take? For a mid-market company with an established FileMaker ERP, a realistic timeline is 12–24 months to reach a genuinely modular state — but with tangible improvements delivered every quarter. The first API integration (e.g. eliminating manual data re-entry with Exact Online) can be live in 4–8 weeks. This is not a big-bang project; it is an ongoing programme.

What is the biggest mistake companies make when trying to reduce lock-in? Replacing one monolithic vendor dependency with another. Moving everything from FileMaker to a cloud ERP like SAP Business One does not reduce lock-in — it transfers it. The goal is to reduce coupling, not to change the logo on the box.

Do we need a full-time architect to manage this? Not necessarily. What you need is a clear architectural decision record — a living document that explains why each integration was built the way it was. That document is worth more than any individual's expertise, because expertise walks out the door; documented decisions don't.

---

If this challenge sounds familiar — a system that works but increasingly holds the business back — that is exactly where Loggix operates. Whether that means building a custom FileMaker module with a clean API boundary, developing a web application that sits alongside your existing platform, connecting your ERP to external services through purpose-built API integrations, or helping you map out an architecture that gives you genuine flexibility without overbuilding: the goal is always the same. Less dependency, more control, no unnecessary complexity.