ERP Integration Architecture: How Overlay Software Connects Modern Interfaces to Legacy Systems

Every ERP implementation over five years old shares the same tension: the back-end is solid, but the front-end experience lags behind what staff and customers expect. You cannot replace the ERP every time a better interface paradigm arrives. That is where ERP overlay architecture comes in.

Overlay software (sometimes called an experience layer or integration fabric) sits between your ERP and your users. It consumes ERP data through APIs, presents it in purpose-built interfaces, and writes data back through the same channels. It does not modify the ERP itself. It does not fork the codebase. It does not create upgrade risk. It is an independent architectural layer that translates between the ERP’s world and the modern application world.

Products in this space include Betty Blocks (low-code application platform for business), Jmix (Java-based rapid application development), NEXr Prism (integration and portal platform), Lumina ERP (modular ERP with overlay capabilities), and Neuron ERP (service-oriented ERP architecture). Each takes a slightly different approach, but the architectural principles are consistent across all of them.

What Is an ERP Overlay / Experience Layer?

An ERP overlay is a distinct software layer that:

• Reads data from the ERP via its public API, ODBC connection, or direct database views
• Transforms that data into structures suited for modern front-end consumption
• Presents it through web, mobile, or portal interfaces that the ERP does not provide natively
• Writes data back through validated, audited channels

This is not ERP customisation. Customisation means modifying the ERP’s own code, screens, or logic. Extension means adding modules that run inside the ERP’s runtime environment. An overlay runs independently. It is a separate application that happens to use the ERP as its primary data source and transactional engine.

The distinction matters because each approach carries different risk profiles:

The overlay pattern has accelerated over the past five years because ERP vendors have invested heavily in API coverage. Dynamics 365 Business Central, Sage 200, SAP, IFS, and even older on-premise systems like Sage 50 and OrderWise now expose REST APIs that cover the core entities needed for UI development. Where no API exists, an ODBC or direct-database adapter can fill the gap without touching the ERP schema.

Core Architecture Patterns

Four patterns recur in well-architected ERP overlay systems. They can be used independently or composed together.

a) API Adapter / Isolation Layer

This is the most fundamental pattern. An adapter layer wraps the ERP’s API surface and presents a clean, unified interface to the overlay’s front-end and business logic components.

Peer Network’s “Advanced Integration Layer” is a commercial example of this pattern. The adapter handles:

• Authentication translation — converting from the overlay’s OAuth 2.0 model to whatever the ERP uses (NTLM, API key, basic auth, OAuth)
• Data normalisation — mapping ERP entity names and field structures to consistent domain models
• Rate limiting — queuing requests to stay within ERP API throttling limits
• Error standardisation — converting ERP-specific error codes into consistent HTTP responses
• Offline buffering — storing writes when the ERP is unreachable and replaying them

The adapter isolates the rest of the overlay from the ERP. If you replace the ERP, you rewrite only the adapter — the front-end, business logic, and data caches remain untouched.

b) Strangler Fig for Gradual Migration

Named after the tropical fig that grows around a host tree, the Strangler Fig pattern enables incremental replacement of ERP functionality. Instead of a big-bang migration, you route specific operations through the overlay one at a time.

In practice:

1. A customer portal overlay starts by handling order status enquiries only — read-only, low risk
2. Once stable, it adds self-service returns — write operations with clear business logic
3. Next, it takes over sales order entry for a subset of customers
4. Over months, the overlay absorbs more and more of the user workload
5. The ERP remains the system of record, but the overlay becomes the primary user interface

The Strangler Fig pattern is particularly valuable when you know you will eventually replace the ERP but cannot justify the cost, risk, or disruption of doing so in one go. The overlay becomes the new face of the system; the old ERP screens become fallbacks for exceptions and administration.

c) Event-Driven Sync Using CDC or Webhooks

An overlay that polls the ERP for changes on a timer introduces latency and load. Event-driven synchronisation is more responsive and more efficient.

Two mechanisms dominate:

Change Data Capture (CDC). The ERP’s database transaction log is read by a process that publishes change events. This works with any ERP that uses a relational database (SQL Server, Oracle, PostgreSQL). Tools like Debezium or AWS DMS can stream CDC events into Kafka or RabbitMQ. The overlay subscribes to the relevant topics and updates its local cache or search index in near-real-time.

Webhooks. Some ERP platforms (Dynamics 365 BC, SAP BTP, IFS Cloud) can push notifications when specified entities change. The overlay exposes a webhook endpoint, and the ERP calls it. This is simpler than CDC but limited to what the ERP exposes. Business Central webhooks cover Sales Orders, Items, Customers, and most major entities.

Whichever mechanism you use, the fundamental architecture is the same: the ERP emits events, the overlay consumes them, and read-side caches stay synchronised without polling overhead.

d) CQRS Pattern (Separate Read/Write Paths Through ERP)

Command Query Responsibility Segregation is particularly well-suited to ERP overlays because ERP and UI workloads have fundamentally different shapes.

In a CQRS architecture:

• Commands (writes) go directly to the ERP through its transactional API. Each command is validated, authorised, and idempotent.
• Queries (reads) hit a local cache, search index, or read-optimised store that is synchronised from the ERP via CDC or webhooks.

The benefit is that the read side can be shaped for exactly how users need to consume data — fast searches, aggregated views, cross-entity queries — without worrying about transactional integrity (the ERP handles that). The write side stays close to the ERP’s transaction model.

This separation also avoids the classic problem where complex UI queries hammer the ERP’s transaction processing engine, degrading performance for every other user.

Architecture Deep-Dive: The Full Data Path

Below is the data flow for a typical ERP overlay implementation, traced from the ERP core to the end user’s browser or mobile device.

 ERP Integration Architecture — Data Flow
 ========================================

  LEGEND:
  [BC]  = Dynamics 365 Business Central (or other ERP)
  [AD]  = Adapter / Isolation Layer
  [CA]  = Cache Layer (Redis / in-memory)
  [GW]  = API Gateway
  [FE]  = Front-end Applications (Web / Mobile / Portal)


  ┌─────────────────────────────────────────────────────────────┐
  │                    ERP CORE [BC]                           │
  │   Sales Orders. Items. Customers. Invoices. Stock.          │
  │   ↓                     ↓                     ↓            │
  │  REST API              CDC Log               Webhook       │
  └─────────┬───────────────┬───────────────────┬──────────────┘
            │               │                   │
            ▼               ▼                   ▼
  ┌─────────────────────────────────────────────────────────────┐
  │               ADAPTER / ISOLATION LAYER [AD]               │
  │                                                           │
  │  • Auth translation (OAuth → NTLM / API key)              │
  │  • Data normalisation                                    │
  │  • Rate limiting & request queuing                       │
  │  • Error mapping                                         │
  │  • Idempotency keys for write operations                  │
  └─────────────────────┬───────────────────────────────────────┘
                        │
                        ▼
  ┌─────────────────────────────────────────────────────────────┐
  │                  CACHE LAYER [CA]                          │
  │  ┌──────────────┐  ┌──────────────┐  ┌────────────────┐  │
  │  │  Redis Cache  │  │ Search Index │  │  Read Store    │  │
  │  │ (low-latency) │  │ (Elasticsearch)│  │ (Materialised)│  │
  │  └──────────────┘  └──────────────┘  └────────────────┘  │
  └─────────────────────┬───────────────────────────────────────┘
                        │
                        ▼
  ┌─────────────────────────────────────────────────────────────┐
  │                   API GATEWAY [GW]                         │
  │                                                           │
  │  • Request authentication & authorisation (OAuth 2.0)     │
  │  • Rate limiting (per client / per user)                  │
  │  • Request routing (cache-hit → cache, miss → ERP)       │
  │  • Response caching                                      │
  └──────┬──────────────┬──────────────┬───────────────────────┘
         │              │              │
         ▼              ▼              ▼
  ┌──────────┐  ┌──────────┐  ┌──────────────┐
  │ Web App  │  │ Mobile   │  │ Customer     │
  │ (React)  │  │ (PWA)    │  │ Portal       │
  └──────────┘  └──────────┘  └──────────────┘
         │              │              │
         ▼              ▼              ▼
   ┌─────────────────────────────────────────┐
   │      USER EXPERIENCE LAYER [FE]        │
   │  Role-specific dashboards. Live data.  │
   │  Purpose-built workflows. SSO login.   │
   └─────────────────────────────────────────┘
          

Every read request hits the API Gateway first. If the data is in the cache and is within its TTL, it is served from there — typically in under 10ms. If not, the adapter fetches it from the ERP, the cache is updated, and the response is returned. Writes always go through to the ERP to maintain transactional integrity, with the cache invalidated or updated after a successful write.

This architecture means the ERP is never queried directly by user-facing code. The ERP sees traffic from the adapter layer only. You can cache aggressively, shape responses for each front-end, and add new front-ends without any ERP changes.

Integration Concerns

Building an overlay that works reliably in production requires addressing several integration-level concerns that are easy to overlook in a proof of concept.

Rate Limiting

Every ERP vendor imposes rate limits on API calls. Dynamics 365 Business Central applies per-environment throttling based on licensing tier. Sage 200 API uses request weighting. SAP Gateway has concurrent request limits. Your overlay must track these limits and queue or back off accordingly. A token-bucket algorithm per API route is the standard approach, with priority queuing for synchronous user-facing requests versus background sync tasks.

Idempotency

Network failures happen. When the overlay sends a create-order request and gets a timeout, did the ERP process it or not? Without idempotency, retrying risks duplicate orders, duplicate payments, or duplicate shipments.

The overlay should generate a unique idempotency key for every write operation (typically a UUID), include it in the request header, and the ERP (or the adapter) should detect and reject duplicates. Not all ERP platforms support idempotency keys natively, in which case the adapter must implement its own deduplication layer using a local idempotency store.

Error Handling

ERP API error responses vary wildly. One might return HTTP 500 with a structured JSON body containing error codes. Another might return HTTP 200 with a “failed” flag in the payload. Another might return a SOAP fault wrapped in an HTTP 200 response. The adapter must normalise these into consistent error objects that the overlay can handle programmatically.

A useful pattern is the “retry with backoff” strategy for transient errors (rate limits, timeouts, database deadlocks) and immediate escalation for permanent errors (validation failures, authorisation denials, missing entity references). The overlay should log every error with enough context to diagnose without reproducing the exact system state.

Data Consistency

Because the overlay uses a local cache for reads, there is always a window where the cache is stale. For most use cases — order status, product catalogues, customer lists — eventual consistency within seconds is acceptable. For inventory availability during order entry, you may need read-through semantics that bypass the cache and fetch directly from the ERP.

Write operations that depend on fresh reads (for example, checking stock before creating a sales order) should use a “read from ERP, write to ERP” flow within a single operation context to avoid race conditions. Optimistic concurrency control with row version tokens can catch conflicts at write time.

Security: OAuth 2.0 Flows for Overlay Applications

An ERP overlay introduces a third-party application layer that handles sensitive business data. The security model must satisfy both the ERP vendor’s authentication requirements and the overlay’s need to authenticate its own users.

The standard pattern uses OAuth 2.0 with the authorisation code flow plus PKCE (Proof Key for Code Exchange). Here is the interaction sequence:

 OAuth 2.0 Authorisation Code Flow + PKCE
 ===========================================

  User Browser       Overlay Frontend      API Gateway         IdP (Entra ID)      ERP
      │                    │                   │                   │               │
      │— 1. Login click ──→│                   │                   │               │
      │                    │— 2. Authz req ───→│                   │               │
      │                    │     (+ PKCE       │                   │               │
      │                    │      challenge)   │                   │               │
      │                    │                   │— 3. Redirect ───→│               │
      │←—— 4. Login page ——│                   │                   │               │
      │— 5. Credentials ──→│                   │                   │               │
      │                    │                   │                   │               │
      │                    │                   │←—— 6. Auth code ——│               │
      │                    │←—— 7. Auth code —│                   │               │
      │                    │                   │                   │               │
      │                    │— 8. Exchange ────→│                   │               │
      │                    │     code +        │                   │               │
      │                    │     PKCE verifier │— 9. Validate ───→│               │
      │                    │                   │←— 10. Token —───│               │
      │                    │←—— 11. Token —───│                   │               │
      │                    │                   │                   │               │
      │←—— 12. App loads —│                   │                   │               │
      │                    │                   │                   │               │
      │— 13. API call ────→│  (access_token)   │                   │               │
      │  (Bearer token)    │— 14. Forward ───→│                   │               │
      │                    │     + token       │                   │               │
      │                    │                   │— 15. Introspect →│               │
      │                    │                   │←— 16. Valid —───│               │
      │                    │                   │                   │               │
      │                    │                   │— 17. Adapter ───→│               │
      │                    │                   │     + ERP auth   │— 18. Query ──→│
      │                    │                   │                   │←— 19. Data ──│
      │                    │                   │←—— 20. Response —│               │
      │←—— 21. Response —│                   │                   │               │
          

Key security decisions when implementing this:

• Never expose ERP credentials to the front-end. The adapter holds all ERP authentication. The front-end only authenticates to the overlay itself.
• Use short-lived access tokens (15–30 minutes) with refresh tokens for session continuity. Do not issue tokens that last longer than a working day.
• Scope tokens to the minimum set of ERP operations that each user role needs. A customer service agent should not have access to the purchase-order endpoint.
• Rotate API secrets. The overlay’s client credentials for the ERP should be rotated automatically every 90 days.
• Audit every write operation. Log which overlay user performed which write, with the original request and the ERP response.

Comparison of Overlay Approaches

There are three main routes to building an ERP overlay, and the right choice depends on your team, timeline, and requirements.

Custom adapter layer

Build your own adapter, API gateway, and front-end. Full control over architecture, data model, and user experience. No platform licensing cost beyond your infrastructure.

Best for: Organisations with in-house development capability, specific or unusual ERP integrations, or long-term commitment to a bespoke interface strategy.

Trade-offs: You own the maintenance, including adapter updates when the ERP API changes. You handle caching, rate limiting, error handling, and security yourself. Typical build time for a production-grade overlay: 4–9 months for a first release.

iPaaS (Integration Platform as a Service)

Platforms such as MuleSoft, Boomi, and Workato provide drag-and-drop integration pipelines, pre-built ERP connectors, and governance tooling. They handle adapter maintenance, rate limiting, and monitoring.

Best for: Enterprises with multiple integration projects across dozens of systems, where the platform cost is justified by volume. Typical total cost of ownership starts around £50,000–100,000 per year for a moderate deployment.

Trade-offs: Vendor lock-in. iPaaS pipelines run on the vendor’s infrastructure — you cannot take them elsewhere without rewriting. The front-end experience still needs building separately. Pricing scales with transaction volume and can become hard to predict.

Low-code platforms (Betty Blocks, Jmix, OutSystems)

These platforms provide visual development environments, built-in data modelling, and integrated front-end components. They bridge the gap between custom development and iPaaS.

Best for: Teams that want to build and iterate quickly without a large engineering team. Betty Blocks, for example, includes connectors for Microsoft Dynamics, SAP, and Salesforce out of the box.

Trade-offs: Platform dependency. You build inside the low-code environment and are tied to its capabilities and roadmap. Complex business logic or unusual ERP structures may require workarounds. Licensing costs range from £15,000–80,000 per year depending on users and connectors.

When the Overlay Pattern Does Not Work

The overlay pattern is not a universal solution. It fails in several specific circumstances:

Your ERP has no usable API. If the ERP exposes no API and you are reduced to screen-scraping or direct database writes, the overlay becomes fragile and dangerous. Every ERP update can break the integration. In this scenario, seriously evaluate replacement before committing to an overlay. That said, some on-premise ERPs can be bridged via ODBC for reads and scheduled exports for writes — workable, but not ideal.

You need real-time transactional consistency across the full dataset. If your use case requires that every user sees exactly the same data within milliseconds of every change — across the ERP and multiple external systems — an overlay introduces too much latency and complexity. A tightly coupled integration or a monolithic replacement would be architecturally simpler.

The ERP is already being replaced within 12 months. Building an overlay for a system you are actively migrating away from rarely makes financial sense, unless the overlay itself is part of the migration strategy (for example, serving as the replacement front-end while the back-end changes underneath).

Your ERP licensing prohibits third-party API access. Some on-premise and legacy ERP licences restrict external API consumption to specific partner modules. Always check the licensing terms before building an overlay. A compliance risk at deployment is the worst time to discover this.

You have no one to maintain the adapter. The adapter layer requires attention. When the ERP vendor updates their API, the adapter may need changes. When you upgrade the ERP, the adapter must be re-validated. If your organisation lacks the internal or contracted capability to maintain this integration, the overlay will degrade over time.

Frequently Asked Questions

What is an ERP experience layer?

An experience layer (or overlay) is an independent software layer that sits between the ERP and the user. It consumes ERP data through APIs and presents it in purpose-built interfaces. It does not modify the ERP itself. The term “experience layer” emphasises the user-facing purpose: better UX without changing the system of record.

How is an ERP overlay different from an ERP add-on?

An add-on runs inside the ERP environment — it is an extension of the ERP’s own runtime. An overlay runs as a completely separate application that communicates with the ERP via its API. Add-ons create upgrade risk and are tied to the ERP’s technology stack. Overlays are independent and can be replaced, updated, or scaled without touching the ERP.

Does an overlay require changes to my ERP?

No. That is the defining characteristic of the overlay pattern. The ERP is unchanged. All integration happens through the ERP’s existing API surface, database views (read-only), or event stream. This eliminates the upgrade risk that comes with customisation.

Can an overlay work with an on-premise ERP?

Yes, provided the ERP exposes a usable API or you can read from the database via ODBC. On-premise systems often require an API adapter or a middleware bridge to translate between the on-premise network and the overlay’s cloud or on-premise runtime. Many on-premise ERPs (Sage 200, OrderWise, SAP ECC, IFS Applications) support this with the right adapter configuration.

What happens to the overlay when I upgrade my ERP?

If the ERP API remains stable (backward-compatible), the overlay continues working. If the API changes, only the adapter layer needs updating. The front-end and business logic are unaffected. This is the key advantage over customisations, which typically require re-validation with every ERP update.

How does an overlay handle real-time data?

Most overlays use event-driven synchronisation (CDC or webhooks) to keep a local cache close to real-time. The window of staleness is typically 1–5 seconds. For operations that require absolute freshness (for example, checking stock before booking an order), the overlay can bypass the cache and read directly from the ERP.

Is an overlay secure for customer-facing portals?

Yes, when properly architected. The overlay should use OAuth 2.0 with the authorisation code flow, short-lived access tokens, and role-based scoping. The ERP credentials remain in the adapter layer and are never exposed to the browser. All writes should be idempotent and audited. A well-built overlay is more secure than a customisation that exposes ERP screens externally.

How long does it take to build an ERP overlay?

A focused discovery sprint takes 3–5 days and produces a live API audit, architecture plan, and fixed-price proposal. The first production release of a typical overlay (customer portal, role-specific dashboards) takes 6–12 weeks with a specialist team. Full-feature overlays with multiple front-ends, complex business logic, and deep integrations take 4–9 months.