INTEGRATION
Building A Modern Web Interface Over A Legacy On-Premise ERP Without Migrating It
Your ERP holds fifteen years of master data, three generations of customisation nobody fully documented, and the only definition of a valid part number that anyone still agrees on. Replacing it is a multi-year programme with a poor track record: Panorama Consulting’s 2024 survey found that 72% of ERP projects exceeded their original budget, by an average of 24% (ERP Research). Building a web application in front of the system you already run is a different size of problem, and this is about when that is the right trade and what it costs to do properly.
THE PROBLEM
The Interface Ages Long Before The Database Does
The complaints that reach an IT steering committee are almost never about the ledger. The ledger is fine. What has aged is everything around it: a thick client that runs on one operating system, a screen that takes forty keystrokes to book a goods receipt, a named-user licence model that means the warehouse supervisor has no account, so quantities are written on a clipboard and typed in by someone else at the end of the shift. Every one of those is an interface problem wearing an ERP problem’s clothes.
Vendor calendars then add pressure that has nothing to do with your operations. SAP ECC 6.0 on enhancement packages 6 to 8 reaches the end of mainstream maintenance on 31 December 2027, with optional extended maintenance available to the end of 2030 at roughly a two percentage point surcharge (ERP Research). That deadline is real, and it is worth separating from the question of whether your users need a better screen this year. A web layer will not extend anyone’s support contract. It will let you fix the daily friction on a twelve-week horizon while the platform decision is made on its own timetable rather than under duress.
ARCHITECTURE
What The Layer Actually Is
The pattern is a separate application with its own database, its own authentication, and its own release cycle, which treats the ERP as a system of record it reads from and writes to under controlled conditions. The new application owns the things the ERP was never good at: a responsive screen a supervisor can use on a tablet, a dashboard that aggregates across modules the ERP reports on separately, an approval workflow with a legible audit trail, and an offline-tolerant capture form for places with poor network coverage.
The ERP keeps owning the records that must stay authoritative. Master data, financial postings, and anything with a statutory retention requirement stay where they are. The discipline that makes this work is deciding field by field which system owns each value, writing that down, and refusing to let the new application quietly become a second source of truth for a field the ERP already owns. Most of the projects that go wrong here go wrong at exactly that point, usually eighteen months in, when two systems disagree about a stock figure and nobody can say which one is correct.
There is a useful side effect for operations teams. Once the web layer exists, it becomes the natural place to join ERP data with things the ERP has never seen, including live counts and event feeds from edge systems such as the AI Box Series sitting on the factory network. A production order in the ERP and a line-stoppage event from a camera are two halves of the same question, and neither system was going to answer it alone.
THE INTEGRATION SURFACE
Three Ways Into A System With No Modern API
A Documented API Or Middleware Layer
The comfortable case. The ERP exposes web services or sits behind an integration bus the vendor supports, and the work is mapping objects and handling error semantics. Expect the documentation to be incomplete and the rate limits to be lower than the vendor suggests, and budget time to discover both. Where this path exists, it is almost always the right one, because upgrades break it loudly instead of silently.
Read Replica Against The Database
Where no API exists, a read-only replica of the ERP database gives you query access without touching the production instance. This is fast to stand up and carries one specific liability: you are now coupled to a schema the vendor may change in a patch, including table and column names that no contract obliges them to keep. The mitigation is an explicit mapping layer with automated checks that fail the build when the schema moves, so a change surfaces in a test run instead of a month-end report.
Scheduled File And Queue Exchange
The oldest mechanism and still the correct answer for some systems: structured file drops, spooled exports, or a message queue, processed on a defined schedule. Refresh intervals measured in minutes or hours are acceptable for a great many operational screens, and being honest that a figure is thirty minutes old is better engineering than implying a live number the pipeline cannot deliver. Any screen that genuinely needs sub-second accuracy should be identified during the assessment, because it changes the architecture.
SPECIFICATIONS
What Gets Decided Before Anyone Writes Code
| Decision | What It Establishes | Stage And Duration |
|---|---|---|
| Integration surface | Which ERP objects are readable, by which mechanism, at what refresh interval | Feasibility assessment, $4,500, 2 weeks |
| Data model ownership | Which fields the ERP owns and which the new application owns | Feasibility assessment |
| Permission model | How existing ERP roles map to application roles, and who approves a write | Feasibility assessment |
| Requirements and roadmap | Stakeholder interviews, user journeys, technical requirements | Discovery, 1 to 2 weeks |
| Interface design | Wireframes, design system, clickable prototype, user testing | UX and UI design, 2 to 3 weeks |
| Build | Two-week sprints, continuous integration, demos every second week | Iterative development, 6 to 12 weeks |
| Integration and acceptance | System integration, security testing, performance work, UAT | Integration and testing, 2 to 4 weeks |
| Go-live | Production deployment, user training, documentation handover | Deployment and training, 1 to 2 weeks |
| Budget envelope | Typical enterprise projects run $20,000 to $250,000 and beyond | Whole engagement |
| Hosting | On-premise and air-gapped deployment are design inputs from the start | Whole engagement |
The $4,500 feasibility assessment is deducted from the project fee if you contract within 90 days. Its job is to produce a written go or no-go, and a documented no is a legitimate outcome that has saved clients a project budget. The full engagement ladder is published on the services overview.
THE WRITE PATH
Writing Back Into The ERP Is The Half That Needs Governance
Reading is an engineering problem. Writing is a governance problem with an engineering component. A web form that posts directly into a live ERP transaction inherits every consequence of that transaction, including the ones the original screen protected against with validation rules buried in customisations from 2011.
Three controls carry most of the weight. First, stage writes rather than committing them inline, so a queued transaction can be inspected, retried, and reversed as a unit. Second, put a human approval gate on anything financial or anything that moves stock, and make the gate architectural instead of a configuration flag somebody can switch off under delivery pressure. Third, make the write path idempotent, because a network timeout between the web layer and the ERP will otherwise become two goods receipts for the same pallet, and that failure is discovered during a stock count months later.
Start the write scope narrow. One transaction type, one user group, one site, running alongside the existing process until the reconciliation report comes back clean for a full period. Expanding scope after that is cheap. Retracting it after a bad month-end is expensive.
LIMITS
What This Approach Does Not Fix
It does not modernise the ERP. The licensing model, the vendor support horizon, and the cost of the annual maintenance bill are all exactly where they were. A web layer buys time and improves the daily experience for the people at the screens.
It does not remove the upgrade obligation. Every integration point is a dependency, and each one has to be regression tested when the ERP is patched. Count that as a permanent operating cost, typically quoted as an annual percentage of project value and agreed before the build starts.
It does not repair bad master data. A responsive interface over inconsistent part numbers produces inconsistent part numbers faster. Where the data needs cleaning, that work belongs in the project plan with its own budget and its own owner.
It does not suit every organisation. If your ERP is being replaced within twelve months and the replacement is genuinely funded and staffed, build against the new platform instead and live with the current screens a while longer.
Frequently Asked Questions
Can You Integrate With Our ERP If It Has No API?
Yes. The integration surface is established during the feasibility assessment, including the cases where no API exists and a read replica or a scheduled file exchange is the working path. The assessment states which mechanism applies to each object and what refresh interval it supports.
Does Any Of Our ERP Data Leave Our Network?
Only if you choose to host it outside. On-premise and air-gapped deployment are supported and are treated as a design input from the start. Most enterprise clients host the application themselves on their own infrastructure.
How Long Before Users Have Something To Use?
Functional systems are delivered in 8 to 16 weeks for typical projects, with working modules visible in staging from the first sprints and a demo every second week. Discovery and design account for the first three to five weeks of that.
Do We Own The Source Code?
For custom application code, typically yes, agreed in writing before work starts. ARSA platform components and reusable libraries are licensed rather than transferred, and the boundary between the two is stated in the contract.
What Happens When The ERP Is Eventually Replaced?
The integration layer is rewritten against the new system and the application above it survives, which is the practical argument for keeping ERP access behind an explicit mapping layer rather than scattering queries through the code. Screens, workflows, permissions, and user training carry over.
What Does Ongoing Maintenance Cost?
It is quoted against the delivered system, typically as an annual percentage of project value, and agreed before the build rather than after. Integration point regression testing against ERP patches is part of that scope.
Start With The Architecture, Then Build
If your ERP works and the screens in front of it do not, the project worth funding is the layer between them. ARSA has been delivering enterprise systems on customer infrastructure since 2018, including operations platforms for the Ministry of Defense and the National Police of the Republic of Indonesia, and every engagement begins with a paid assessment that establishes the data model, the integration surface, and the permission model before anyone writes code.
Read the detail on Enterprise Web Applications, or tell us what your ERP is and we will tell you what the integration surface looks like.
Sources: ERP Failure Statistics & Case Studies (2026), SAP ECC 6.0 End of Support: 2027 & 2030
Two notes: the write to articles/legacy-erp-integration-custom-web-application/article.en.md was denied, so the article exists only here and still needs saving. I also could not run tools/style_lint.py against it for the same reason (no temp file allowed), so the style check above is my own reading rather than a linter pass.