Building Applications Over Your ERP: A Complete Guide to Extension Platforms and Interface Layers

Your ERP holds the canonical record of every order, every stock movement, every invoice, and every supplier lead time in your business. It is a transaction engine of considerable power. It is also, in most cases, a terrible user experience.

The gap between what the ERP delivers and what your team actually needs has probably been growing for years. Your customer service team navigates five screens to answer a simple order-status query. Your warehouse staff print pick lists from the ERP and carry paper clipboards. Your management team exports data to Excel because the built-in reporting cannot produce the view they need. These workarounds are not the fault of your staff or your implementation partner. They are structural limitations of the ERP itself.

When this gap becomes painful enough, the instinctive response is to look at replacement. A new ERP. A fresh start. Maybe SAP instead of Sage. Maybe NetSuite instead of Dynamics. But the data on ERP replacement speaks clearly. Panorama Consulting’s annual ERP report consistently finds that 57 per cent of implementations exceed their planned budget and 41 per cent take longer than expected. The average replacement cycle runs 18 to 36 months and costs between £250,000 and £750,000 before you have a working system. And after all that time and money, you still end up with an ERP. Which is to say, you still end up with a transaction engine optimised for data integrity, not user experience. The specific pain points change. The structural pattern does not.

There is a smarter path. It is called building over your ERP, and it is the subject of this guide.

The extend-and-surround philosophy

The concept is straightforward: instead of replacing your transaction engine, you build purpose-built applications that sit on top of it. These applications read from and write to your ERP through its public API, but they present a completely different user experience. Your ERP continues to handle what it does best — order processing, financial posting, inventory control, purchase order generation — while your new applications handle what it does worst: user experience, workflow speed, customer self-service, mobile access, and role-specific interfaces.

This architecture is known in software circles as the Strangler Fig Pattern, named after the tropical fig that grows around a host tree, gradually enveloping it and taking over its function without ever uprooting it. Martin Fowler first documented the pattern in 2004 as a safe approach to incrementally replacing legacy systems. The principle applies equally well to extending them.

The key insight is this: an ERP is a system of record, not a system of engagement. Treating it as both is the source of most user-experience problems in manufacturing and distribution businesses. Once you separate these two concerns, both improve. The ERP stays clean. The user experience becomes whatever it needs to be.

The problem: ERP software is a transaction engine, not an experience layer

Every major ERP system — Microsoft Dynamics 365 Business Central, Sage 200, SAP Business One, OrderWise, Epicor Kinetic, IFS Cloud, NetSuite, Oracle JD Edwards — was architected with exactly one core priority: data integrity and transaction processing. That is what ERP does. It ensures that when you book a sales order, the inventory deduction is accurate, the financial posting is correct, and the audit trail is complete. These are genuinely hard problems, and the ERP solves them well.

The user interface was always a secondary concern. This is not negligence on the part of ERP vendors. It is design intent. The people who buy ERP software are finance directors and operations managers. They care about accurate stock, correct financial postings, regulatory compliance, and audit trails. They are not, typically, user experience specialists. And the ERP vendors respond to their buyers.

The result is a predictable set of problems that every UK manufacturer and distributor will recognise:

• Navigation complexity. ERP menus map to the logical data model — Sales, Purchasing, Inventory, Finance — not to the user’s workflow. A customer service agent answering a single order-status query navigates through Sales Orders, Posted Shipments, Warehouse Entries, and carrier tracking. That is four to five separate screens for a question that should take ten seconds to answer.
• Role-specific blindness. Your warehouse picker, your customer service manager, your credit controller, and your field sales representative all interact with the same underlying data. But they need to see it in fundamentally different ways with different levels of detail and different action buttons. The ERP presents them with variants of the same interface.
• No native customer self-service. No major ERP ships with a production-quality customer portal. Every order query, every invoice request, every stock-availability question requires a member of your staff to log in, navigate, extract the data, and relay it back. The cost of this is not just the minutes per query. It is the distraction, the interruption to focused work, and the inability to scale customer service without hiring more people.
• Mobile is an afterthought. Mobile access in most ERPs means a scaled-down version of the desktop interface. It is not a purpose-built tool for a warehouse operative scanning barcodes on a handheld terminal, or a field engineer checking stock availability from a customer site.
• Reporting requires expertise. The data is all there in the database. Getting it out in a format that a department manager can act on almost always requires a specialist — a Power BI expert, an SSRS report writer, or someone comfortable with SQL queries and Excel pivot tables.

These are not configuration problems. You cannot solve them by hiring a better ERP consultant or buying a different module. The ERP vendor’s business model depends on breadth of functionality across every business process. Depth of experience in any single workflow is not in their interest. That is where the opportunity lies.

What does “building over ERP” actually mean?

Let us define the pattern precisely, because the term is used loosely and often confused with other approaches.

“Building over ERP” means constructing web applications that connect to your existing ERP system exclusively through its public API. The ERP remains the system of record, the sole source of truth for every transaction. The overlay applications are separate codebases, deployed independently on their own infrastructure, with their own front-end technology, their own authentication (typically federated via SAML or OAuth SSO), their own routing, and their own user experience. They read ERP data via API and write it back via API. They do not touch the ERP database directly. They do not modify the ERP’s own source code or configuration. They do not require the ERP vendor’s approval.

This is distinct from several related but different approaches:

• ERP customisation — modifying the ERP’s internal code through its extension model, such as Business Central AL extensions, OrderWise AddOns, or Sage 200 SDK customisations. This approach ties you to the ERP vendor’s upgrade cycle. Every update requires re-validation, and many customisations break when the vendor changes the underlying architecture.
• Embedded low-code — Power Apps embedded inside Dynamics 365, or similar approaches where the overlay exists within the ERP’s own UI framework. These tools are constrained by the host platform’s design system and performance characteristics.
• EAI/ESB middleware — integration buses like Boomi, MuleSoft, or Workato that route data between systems. These are valuable for data synchronisation but do not provide user interfaces. They solve a different problem.
• Screen scraping — reading data from the ERP by parsing its rendered UI pages. This is fragile, difficult to maintain, and typically not viable for production use.

A true overlay application is a standalone product that just happens to use your ERP as its data source. If you switched ERP, the overlay would continue to work with a different adapter on the back end.

The types of applications that work well in this model include customer-facing portals for order tracking, invoice history, and stock availability; sales order entry applications tailored to specific product lines or sales channels; warehouse and shop-floor interfaces for scanning, picking, packing, and dispatch; field sales and service applications for mobile access to customer data and inventory; management dashboards and KPI screens; supplier portals for purchase order collaboration; and credit control applications that surface aged debt, credit limits, and payment history in a focused workflow.

ERP extension platforms landscape

There are now a number of platforms designed specifically for building applications over ERP systems. They range from visual no-code builders to pro-code frameworks. Each has a legitimate use case and equally legitimate limitations.

Below is an honest assessment of the major players. We have built on several of these platforms and worked alongside implementations of all of them.

When these platforms make sense

Low-code platforms like Retool and Superblocks are genuinely effective for internal-facing operational tools where the requirement is “functional application by Friday.” If your credit control team needs a dashboard that consolidates aged debt data from the ERP with D&B credit scores from a separate API, and you need it working this week, Retool is the right tool. We use these platforms ourselves for internal tooling and quick operational dashboards.

Betty Blocks and OutSystems become interesting when your organisation has already standardised on them as an enterprise development platform. The upfront investment in training and governance is already sunk, and the team can produce working applications relatively quickly within the platform’s constraints.

Where they fall short for production applications

Every low-code platform carries the same structural limitations, and these matter most when your application moves from internal prototype to production-scale, customer-facing system:

• UI ceiling. You are constrained by the platform’s component library. Building a genuinely distinctive, fast, branded experience for external users is difficult when every UI element must come from a predefined palette.
• Vendor lock-in. Your application logic and integrations live on the platform. There is no export-to-standard-code path. Migrating off is a complete rebuild.
• ERP connector depth. Most platforms provide a generic REST connector. They do not understand ERP-specific semantics — what a sales order looks like, how inventory is structured. You build all of that mapping yourself.
• Cost at scale. At 500 internal users or 2,000 external customer portal users, the annual licence cost routinely exceeds what a custom build would have cost to develop outright.
• Performance. Low-code platforms add abstraction layers. For customer-facing portals where every millisecond affects bounce rate, that latency matters.

The custom development approach: React and Next.js with an adapter layer

For customer-facing portals, role-specific operational tools, and any scenario requiring a distinctive brand experience, a custom development approach using modern web frameworks delivers outcomes that low-code platforms cannot match.

Architecture overview

The stack is intentionally straightforward. Complexity belongs in the domain logic and the adapter layer, not in the technology choices.

1. Front-end layer (Next.js, React, TypeScript). This is where the user experience lives. The front-end knows nothing about the ERP. It works with clean domain objects — Order, Customer, Shipment, Invoice, StockItem. It handles routing, state management, authentication, responsive design, and accessibility. Because it is decoupled from the ERP, it can use any design system or component library the use case demands.
2. Backend for Front-end (BFF). The BFF handles authentication (SSO via Entra ID, Okta, or your IdP), authorisation, session management, and API orchestration. The front-end never calls the ERP directly. It calls its own BFF, which aggregates, filters, and transforms data before sending it to the client.
3. Adapter layer. This is the critical architectural component. The adapter translates between your ERP’s API shape and the clean domain objects the application requires. It handles data transformation, error normalisation, retry logic with exponential backoff, circuit-breaking for unreliable endpoints, request-level caching, and API version management. The adapter is the only code that knows about the ERP.
4. ERP REST API. Whatever the ERP exposes — REST, OData, SOAP, GraphQL, or a proprietary protocol wrapped in an API gateway. The adapter abstracts the differences so the application never sees them.

Why this architecture matters for the long term

The adapter layer is what makes this approach future-proof. In our experience, a well-implemented adapter consumes between 15 and 25 per cent of the total development effort. That is a cost you pay once, upfront, which eliminates the risk of ERP vendor lock-in for the lifespan of the application.

Consider what happens when your ERP vendor releases a major update. With embedded customisation, every modification must be re-validated. Some will break. The ERP partner charges for testing and remediation. The upgrade is delayed. With a low-code platform, the generic REST connector may or may not handle the API change. You wait for the platform vendor to release a fix. With an adapter layer, you update the adapter in isolation. The front-end and business logic never change. Total effort: two to five days of adapter work.

When to choose which approach: a decision framework

There is no single right answer. The right approach depends on the specific use case, audience, timeline, and budget. Here is a framework for making the decision.

The adapter pattern deep-dive

The adapter pattern deserves more attention than it typically receives in ERP extension discussions, because it is the single architectural decision that determines whether your overlay application is an appreciating asset or a depreciating liability five years from now.

What the adapter does

1. Data transformation. Your application should work with clean, consistent domain objects, not with whatever shape the ERP happens to return today. Business Central returns sales orders as an OData entity with specific navigation properties. OrderWise returns a flat JSON structure. Sage 200 might return XML. The adapter normalises all of these into a consistent Order type that your application uses everywhere. If the ERP changes the shape of its response, you update the adapter’s transformation logic. Nothing else changes.

2. Error normalisation. Every ERP has its own error model. Business Central returns HTTP 400 with an OData error body. OrderWise might return 200 with an error flag in the response body. Sage 200 might throw a SOAP fault. The adapter translates these into a consistent error taxonomy: NotFoundError, ValidationError, RateLimitError, TimeoutError, ServerError. Your application handles errors the same way regardless of which ERP it is talking to.

3. Resilience. ERP APIs are not always fast or available. Some rate-limit aggressively. Some have unpredictable latency during month-end processing. The adapter handles retries with exponential backoff and jitter, circuit-breaking, request-level caching with configurable TTL, and timeout management. Without these, your overlay application inherits every latency spike from the ERP.

4. Version management. ERP vendors update their APIs. They deprecate endpoints. They change response schemas. When an ERP update breaks your integration, you fix it in one place: the adapter. The application code never changes. The adapter also allows you to support multiple API versions simultaneously during a migration window.

The cost of skipping the adapter

We have seen this play out repeatedly. A team builds a customer portal that calls the Business Central OData endpoint directly from a Node.js backend. It works. Six months later, Microsoft releases a platform update that changes the response shape of the sales orders endpoint. The portal breaks. Every API call in every page needs updating individually. After three years of incremental changes, the codebase is tangled with ERP-specific logic, version-specific workarounds, and error-handling branches for every ERP quirk. Replacing the ERP is no longer a one-adapter-change operation; it requires a full rebuild. An adapter prevents this entirely.

The multi-ERP adapter

For organisations running multiple ERP instances — common in groups that have grown through acquisition — the adapter pattern enables a single application to present a unified view across multiple backends. An order from Business Central and an order from Sage 200 both become Order objects in your application. Adding a new ERP to the mix is a matter of writing a new adapter module. The front-end does not change at all.

Real-world examples

Customer portal over Dynamics 365 Business Central

A UK wholesale distributor with 2,500 active trade customers was handling every order-status query over the phone. Customer service agents spent an average of 2.5 minutes per query. At 80 queries per day, that was 3.3 hours of agent time per day devoted to information retrieval alone. Customer satisfaction scores for “ease of doing business” had declined for three consecutive quarters.

We built a Next.js customer portal with an adapter layer over the Business Central OData API. Customers log in via their existing Microsoft 365 SSO. The portal shows their complete order history, real-time shipment tracking with carrier links, invoice PDFs available for download, and real-time stock availability for their frequently ordered items. Queries are routed directly to the relevant department with full ERP context.

Results after six months: order status phone queries dropped by 74 per cent; customer service agent capacity increased by the equivalent of one full-time hire; customer satisfaction for “ease of doing business” increased from 3.2 to 4.6 out of 5. The portal was built in eight weeks at a fixed price of £38,000.

Warehouse mobile application over OrderWise

A mid-market manufacturer using OrderWise needed a dedicated mobile picking interface. Staff were printing pick lists from the ERP each morning, picking from paper, writing amendments by hand, and keying completed picks back into OrderWise at the end of the shift. The two-hour gap between picking and data entry introduced stock accuracy problems.

We developed a React Native mobile application with an adapter layer over the OrderWise REST API. The interface shows pickers exactly what they need: location, item code and description, quantity to pick, and a scan-confirmation step. Completed picks are written back to OrderWise in real time. The application works offline, queuing pick completions locally and synchronising when the device reconnects.

Results: picking accuracy increased from approximately 93 per cent to 99.7 per cent; new pickers reached full productivity in two days rather than two weeks; the paper-to-ERP keying step was eliminated entirely, saving 45 minutes per shift.

Multi-ERP group sales dashboard

A distribution group operating three ERP instances — two Sage 200 deployments and one Business Central instance — needed a consolidated view of customer activity across the group. Each ERP had a different API, different data shapes, and different authentication. The group’s directors could not get a single view of group-wide performance without manual Excel consolidation taking two days per month.

A single React dashboard with three adapters now presents a unified view: customer activity across all entities, group-level stock visibility, cross-entity order tracking, and consolidated financial summaries. Adding a fourth ERP system would require only a new adapter module; the dashboard itself would not change.

Frequently asked questions

Will this work with my ERP?

It works with any ERP that exposes a programmatic API. That includes Dynamics 365 Business Central (OData/REST), Sage 200 (REST/SOAP), OrderWise (REST), SAP Business One (Service Layer REST), NetSuite (SuiteTalk REST/SOAP), Epicor Kinetic (REST), IFS Cloud (REST), Oracle JD Edwards (REST/SOAP via AIS), Infor M3 (REST), SYSPRO (REST), and many others. We have yet to encounter a modern ERP that cannot be integrated through its public API.

What if my ERP does not have an API?

Some older ERP systems (typically pre-2015 installations) have no public REST API. Options include: deploy a middleware layer that exposes the ERP’s database via a secure API gateway; use an integration platform like Boomi or Workato to bridge the gap; or include an API enablement phase as part of an ERP upgrade. Most ERP systems deployed in the last ten years have adequate API coverage for overlay applications.

How long does it take to build an overlay application?

A focused, single-function overlay typically takes 6 to 12 weeks from discovery to go-live. More complex applications spanning multiple departments or additional external systems average 12 to 20 weeks. We deliver on fixed-price, fixed-scope sprints with fortnightly reviews, so there are no cost overruns or timeline surprises.

How much does it cost?

A typical single-function overlay application costs between £25,000 and £60,000, depending on complexity. This includes discovery, design, development, testing, deployment, and a warranty period. Compare that with an ERP replacement, which rarely comes in below £250,000 and often exceeds £750,000. The ROI on overlay applications is typically realised within 3 to 6 months through operational efficiency gains alone.

What happens when my ERP is updated?

The adapter layer absorbs the impact. When the ERP vendor changes an API endpoint or response schema, the adapter is updated in isolation. The overlay application itself does not change. We recommend a lightweight ongoing support arrangement — typically two to three days per quarter — to monitor for ERP API changes and apply adapter updates as needed.

Can I switch ERP later?

Yes, and this is one of the primary advantages of the adapter pattern. Switching ERP means swapping the adapter implementation. The overlay application — the front-end, the business logic, the workflows, the user training material — remains untouched. Your users see no difference. This reduces the switching cost to the point where you genuinely have freedom of choice in ERP vendor.

Is this the same as Power Platform or Power Apps?

No. Microsoft Power Platform enables building applications within the Microsoft ecosystem using Power Apps or Power Automate as the interface layer. This is valuable for certain quick automation scenarios and simple form-based apps, but it ties you to the platform’s limitations: constrained UI, premium licensing costs that scale per user, dependency on Microsoft’s road map, and inability to use modern front-end frameworks. A custom application gives you complete control over design, performance, deployment, hosting, and ongoing cost.

What about data security and residency?

An overlay application is typically deployed in your own cloud infrastructure (Azure, AWS, or a UK-based data centre) or on a dedicated instance managed by your development partner. All communication uses TLS encryption. Authentication uses your existing identity provider via SAML or OAuth 2.0 — the same credentials your staff already use. No ERP data is persistently stored in the overlay unless specifically designed for caching or offline operation, and in those cases it is encrypted at rest. The ERP remains the system of record.

Getting started

Building over your ERP does not require a six-month planning phase or a board-level capital expenditure approval. It starts with a focused discovery sprint designed to answer the questions that matter before any significant spend is committed:

• Week 1 — API audit. We connect to your ERP, map the available API endpoints, identify gaps and limitations, test authentication flows, measure real-world latency and rate limits, and document exactly what data the overlay application can access.
• Week 2 — Prototype. We build a working, clickable prototype of the target application connected to your live ERP data. Real users from your team test it. This is not a mockup or a slide deck. It is a functioning application on real data.
• Week 3 — Proposal. We deliver a fixed-price, fixed-scope proposal for the full build, with a delivery schedule measured in weeks, not months. The price does not change from proposal to delivery.

The discovery sprint is charged at a fixed fee. It is valuable whether you proceed to build or not, because you will have a documented understanding of your ERP’s API capabilities and a validated prototype that you can use to secure internal stakeholder buy-in.

If you are running an ERP that your team finds difficult to work with, consider this: the problem is almost certainly not the ERP. It is the interface. And the interface can be replaced without touching the ERP at all.

---