How to Modernise Business Central Without Replacing It

If you are reading this, you have probably already run the numbers on replacing Microsoft Dynamics 365 Business Central. And the numbers do not make pleasant reading.

A full ERP replacement costs £300,000–£400,000 for a mid-market UK manufacturer. Gartner reports that more than 55% of these projects fail to meet their objectives. Panorama Consulting puts the figure closer to 60%. And even if your replacement succeeds, you are looking at 9–18 months of operational disruption, data migration headaches, and retraining.

But the interface is driving your team mad. So what else can you do?

Here is the third option: build a modern interface layer over Business Central without replacing it. Keep BC as your system of record. Keep your data, your workflows, your integrations, your licensing. Replace only the interface — the part your team interacts with every single day.

This guide explains exactly how that works: the architecture, the tech stack, the implementation approach, and what it costs. No fluff. No vague marketing.

The Problem: Business Central Is a Powerful Engine with a Frustrating Dashboard

Let us be clear about something upfront: Business Central is a capable ERP. It handles financial management, supply chain, manufacturing, inventory, and sales order processing. The data model is solid. The integrations with Microsoft 365 and Power Platform are valuable. We are not suggesting you rip it out.

The problem is the user interface.

BC’s web client, for all Microsoft’s investment in modernisation, still carries the DNA of its Dynamics NAV heritage. Users face:

• Role centres crammed with tiles, lists, and fact boxes that fight for attention
• Navigation that requires 6–12 clicks to reach a frequently used function
• Search that is functional but not intuitive for task-oriented workflows
• A data-entry experience built for accountants, not warehouse operators
• Mobile access via BC’s mobile app that shrinks the desktop UI rather than rethinking the workflow

The academic research backs this up. A 2020 study in MDPI Applied Sciences identified 27 distinct usability problems in ERP systems, including interface complexity, excessive navigation steps, and poor error feedback. Industry surveys put the numbers even higher: 68% of ERP users report poor navigation, 54% cite clunky dashboards requiring too many clicks, and 42% struggle with slow performance.

The symptom you feel most is your team exporting data to Excel to do their actual work. BC becomes a “system of record” while the real work happens in spreadsheets. Your data is in BC. Your decisions are made in Excel. That gap is costing you.

At Sysgraft, we hear this from almost every manufacturer we talk to. Your team is not lazy or resistant to technology. They have simply found that BC’s interface is not designed for the way they actually work — and they have adapted by building workarounds. Those workarounds are costing you money, time, and data integrity.

The Solution: An Interface Layer, Not a Replacement

Sysgraft builds a modern web application layer that sits on top of your existing Business Central instance. It connects via BC’s built-in REST API v2.0 — no database access, no custom modifications to BC itself, no risk to your upgrade path.

Here is the architecture at a glance:

Your Existing Business Central Instance
         │
         │  REST API v2.0 (OData) — read + write
         │  OAuth 2.0 (Microsoft Entra ID)
         ▼
Sysgraft Interface Layer
React · Next.js · TypeScript
         │
         ├── Staff Operations Portal
         │   · Live order tracking
         │   · Role-specific dashboards
         │   · Real-time stock visibility
         │
         ├── Customer Self-Service Portal
         │   · Order status 24/7
         │   · Invoice and statement download
         │   · Live stock and pricing
         │
         └── Management Dashboard
             · Live revenue and pipeline KPIs
             · Production status
             · Stock health indicators

Key principle: The interface layer reads and writes data through BC’s API in real time. There is no data migration. No duplicate database. Your data stays in Business Central — the interface just makes it accessible in a way that makes sense for each role.

Business Central’s API: What Is Available

If you are an IT manager evaluating this approach, your first question is probably: “Does BC’s API actually support what we need?”

The short answer is yes. Business Central exposes a comprehensive REST API (v2.0) that covers the full suite of standard objects. Microsoft maintains it as a first-class integration surface for connecting apps to BC.

Standard API endpoints (out of the box):

If you need an endpoint that is not in the standard API, Microsoft supports API pages — custom API surfaces that you (or a partner) can expose from BC’s AL language. These become first-class REST endpoints with the same authentication and rate-limiting as the standard API.

The discovery sprint we run includes a live API audit against your actual BC tenant. We authenticate with your credentials, enumerate every available endpoint, test read operations against your real data, and validate write-back against your business logic. If something is missing, we tell you before any build price is issued.

Authentication and Security Architecture

Business Central’s REST API authenticates via OAuth 2.0 with Microsoft Entra ID (formerly Azure AD). Here is how the security model works:

1. Staff access: Your team authenticates via Microsoft Entra ID SSO — they use their existing Microsoft 365 credentials. No separate login.
2. Customer access: Customer portal users authenticate via separate secure accounts managed through BC’s customer record.
3. API calls: The interface layer uses the OAuth 2.0 client credentials flow (service-to-service). Short-lived access tokens, full audit trail.
4. Data residency: All application infrastructure is hosted in UK-region cloud (Azure UK South or AWS London).
5. Field-level security: Customer portal users see only their own data — enforced at both the API and application level.

Comparing the Options

The 80/20 rule: An interface layer delivers roughly 80% of the benefit of a full replacement at about 20% of the cost. The 80% is the part your team sees and feels every day — the interface.

The Build Process: How It Works for Business Central

Phase 1: Discovery Sprint (3–5 days)

We come to you. Two to three days on-site, observing how your team actually works — not how the process document says they work. We watch your sales team navigate BC to find order status. We see your warehouse staff export data to Excel. We identify the workflows that cause the most friction.

Then we authenticate against your live BC tenant. We enumerate the API v2.0 endpoints, test reads and writes against your real data, and validate coverage for the scope you need.

At the end of the sprint, you receive a detailed pain-point map, a live API audit report, wireframes and UX concepts, and a fixed-price build proposal.

Phase 2: Fixed-Price Build (4–12 weeks)

Against the scope defined in discovery, we build your interface layer using React, Next.js, and TypeScript. Weekly sprint check-ins. No scope creep.

Build timeline depends on scope: staff dashboard (4–6 weeks), customer portal read-only (6–8 weeks), customer portal with write-back (8–12 weeks), full platform (10–12 weeks). Payment: 50% on signature, 50% on go-live.

Phase 3: Monthly Subscription (ongoing)

Hosting, security patching, maintenance, and feature evolution. 12-month minimum term, then 30 days’ notice. IP transfers on go-live. You own the code.

Technical Architecture Deep Dive

For the technical decision-makers reading this, here is the actual architecture of a BC interface layer:

Dynamics 365 Business Central
         │
         │ REST API v2.0 (HTTPS)
         │ OAuth 2.0 / Microsoft Entra ID
         ▼
API Adapter Layer (isolated)
  · BC API client (auto-generated)
  · Request/response mapping
  · Caching layer (Redis)
  · Idempotency for write operations
         │
         ▼
Application Layer (Next.js)
  · Server-side rendering
  · React Server Components
  · TypeScript, strict mode
         │
   ┌─────┴─────┐
   ▼           ▼
Staff      Customer
Portal     Portal

Why an API adapter layer matters

The adapter layer isolates your BC API integration in a single place. If an endpoint changes (BC API versioning), only the adapter needs updating — not the entire application. If you ever decide to change your ERP, only the adapter layer needs rewriting. The frontend applications do not change at all.

Write-back pattern

When your staff perform actions in the interface, the request goes through: validation → idempotency check → BC API call → confirmation. If BC rejects the write, the error is surfaced immediately with a clear message.

Real-World Example: What This Looks Like for a Manufacturer

Consider a UK manufacturer running Business Central for financials, inventory, and sales order processing.

The current reality:

• Customer calls for order status → salesperson navigates five BC screens → 2–4 minutes per call → 2–3 hours of sales time lost daily
• Warehouse operator wants pick list → exports BC data to Excel → stale by 10am
• MD wants weekly revenue → finance runs BC report → exports to Excel → formats → emails → 45 minutes for a snapshot already 20 minutes old

With an interface layer:

• Customer logs into branded portal → sees order status, carrier tracking, invoices → zero salesperson time, 24/7
• Warehouse operator opens portal → sees live pick list, barcode scanning → two clicks, no Excel
• MD opens dashboard → live revenue, order pipeline, stock health → updated every 30 seconds

Power Apps vs Custom React Frontend: An Honest Comparison

A common question from BC users is: “Can we not just use Power Apps to do this?”

The honest answer: it depends on what you need. Power Apps works well for simple internal dashboards (5–10 users), basic approval workflows, and quick prototypes. It struggles with complex business logic (BOM explosions, multi-tier pricing), high-volume transactional interfaces, customer-facing portals with complex auth, and performance at scale.

A custom React frontend excels at production-grade customer-facing applications, complex data entry workflows, high-performance real-time dashboards, and full control over UX and branding. If you need a customer-facing portal for 50+ users, a custom React frontend is the difference between a configured tool and a production-grade application.

Read our full comparison of Power Apps vs custom React frontends for ERP.

---