Oracle APEX + MES / ERP modernisation
Oracle APEX modernisation that finally lets the floor leave 2010.
We build the modern web, mobile and integration layers that extend an existing Oracle APEX system without forking the twenty years of business logic underneath. The Australian manufacturer we typically meet has a production scheduler keeping a spreadsheet open next to APEX, a leading hand walking back to a desktop every hour to update job status, and an office running parallel workarounds for forms designed before phones did real work on the floor. The APEX database is alive and correct: the costed BOM, the multi-level routing, the work-order spine, twenty years of edge-case PL/SQL the production manager carries in their head. What has aged out is the surface the scheduler and the leading hand and the office touch every morning. We keep the database and modernise the surface.
Where legacy APEX meets the modern stack
The APEX database holds the production spine: configured BOM, multi-level routing, work order, machine schedule, twenty years of edge cases baked into PL/SQL packages that the senior production manager carries in their head. The modern stack on top (the ERP, the ledger, the field tablet, the executive dashboard) wants to read and write against that database. The join points are specific, and each one has a recognisable failure mode.
Forms from a different decade
The UI the office quietly worked around
Reports that match the dashboard era
The APEX classic report the executive does not open
Mobile access for the floor
The phone the production team cannot use
Integration to the modern stack
The MYOB or Pronto sync that runs on hope
How we approach Oracle APEX modernisation
Discovery before anything else
We map what the APEX system already does well, what the office and the floor have built around, and where the surrounding tooling has aged out. Which APEX modules are load-bearing, which forms the staff have a workaround for, where the PL/SQL packages enforce business rules nobody has written down outside the code. Twenty years of APEX database carries twenty years of correct answers; the modernisation has to preserve them rather than re-derive them.
Model the substrate, not the new app
The database-first move. Before we build anything on top, we document the contract the APEX schema and the PL/SQL packages already enforce. The new web and mobile clients, the BI layer and the ERP integration all read against that contract rather than re-implementing pieces of it. Modernise the surface, keep the substrate. Reconcile in one place, not in the air between APEX and a half-rewritten replacement.
Reconciliation as a contract
Every new layer that reads or writes against APEX does so against an explicit API contract. The modern front-end, the BI dashboard, the ERP sync and the mobile field client share the same API surface. Retries, idempotency and dead-letter handling are specified before the integration code is written. If APEX and MYOB or Pronto disagree on a job overnight, the production manager sees it next morning against the work order and cost centre, not at month-end against an aggregate variance.
Middleware that handles vendor failures
Oracle, MYOB, Pronto and the modern client stack each misbehave in specific ways. Database connection limits, ERP rate limits, auth-token refresh quirks, scheduled APEX patching windows that knock out the integration for hours. We build the modernisation layer on real infrastructure with queues, monitoring and alerts, so a throttled vendor or a patch window raises a hand rather than quietly dropping a work-order update. When something breaks, the system tells you before the production manager does.
AI-ready as a side-effect
The APEX database the system already gives you, plus the API contract the modernisation work adds, is the data shape an AI agent would need to act on the production environment safely later. One canonical record per work order, audit trail by default, permissions modelled in the data layer, the agent reading from the source of truth rather than reconciling APEX and a half-rewritten replacement. We do not bolt agents on in this engagement, but the work leaves the business ready when the AI question lands.
We have done this since 2007. See who we are.
What this typically looks like in practice
An Australian manufacturer we worked with was running an Oracle APEX system that had carried the business for nearly twenty years. The APEX database held the configured BOM, the production schedule, the work-order spine and the costed BOM logic that nobody had ever written down outside the PL/SQL packages. The office was running parallel spreadsheets next to every APEX form to compensate for the UI; the executive sponsor was pasting CSV exports into a leadership-meeting dashboard each fortnight; the floor was updating job status by walking back to a desktop. The pattern that triggered the call was a board conversation about whether to rewrite the whole thing on a modern stack, against an estimate that came in around three million dollars and a two-year horizon. Nobody had dropped the ball. The system was correct; the experience around it had aged out.
We built a modernisation layer that kept the APEX database as the canonical record and added a modern web front-end on the highest-traffic modules, a mobile interface for the floor, a tablet-friendly executive dashboard and a clean integration to MYOB Advanced. The PL/SQL packages stayed; the API surface in front of them was new. The first visible win shipped inside the first month, with leading hands updating job status from the floor on a phone, and the rest of the program ran on demonstrated value rather than promises. The board conversation about rewriting stopped being a three-million-dollar decision and became a one-tranche-at-a-time decision.
The three-million-dollar rewrite conversation stopped being a single decision and became a one-tranche-at-a-time decision. The board approved the next tranche on demonstrated value rather than promised value.
From the Oracle APEX manufacturing modernisation case study
Pattern story, anonymised. No named manufacturer, dates or exact dollar amounts. We will publish a named case study once an Australian manufacturer engagement has consented.
Common questions about Oracle APEX manufacturing modernisation
Why not just rewrite the APEX system on a modern stack?
Sometimes the answer is rewrite. Most of the time it is not. Twenty years of APEX has twenty years of business logic baked into the database, the package PL/SQL and the workflows the floor depends on. A forklift rewrite spends two years rebuilding what the existing system already does correctly, ships with the same gaps the original had on day one, and never quite catches up to the edge cases the senior production manager carries in their head. We rewrite when the database itself is the problem; we extend when the database is fine and the surrounding tooling is the problem. The diagnostic is honest about which case applies before we quote anything.
How does extending APEX with a modern front-end actually work?
The PL/SQL packages and tables stay. We build a thin API layer on top (REST or GraphQL, whichever the rest of your stack prefers) that talks to the APEX schema with the same business rules the APEX forms enforce. Modern web and mobile clients consume that API. The APEX forms keep running where the office team prefers them; the modern client runs where mobile or modern UI matters. Nothing fights for ownership of the data because the database is still the canonical record.
What about an Oracle licence review while we are at it?
Worth doing, in parallel rather than as a precondition. Many manufacturers we see have grown the APEX system past the licence band that made sense at the start. The modernisation work and the licence-tier conversation are independent: you can extend the APEX system without re-licensing, and you can re-licence without extending it. Treat them as separate decisions and the conversation with Oracle gets cleaner. We can put you in touch with licensing specialists if you do not already have one; we do not resell licences.
How long does an APEX modernisation engagement take?
Eight to sixteen weeks for the first tranche of value, depending on the scope of the modernisation. Eight weeks for a focused modern web front-end on the highest-traffic APEX module plus the integration to Xero or MYOB. Sixteen weeks for a multi-module modernisation including mobile field access, a new reporting layer and the integration to the production-scheduling system. Most engagements ship the first visible win inside the first month so the rest of the program runs on demonstrated value, not promised value.
Does this set us up for AI agents on top later?
Yes. The AI-ready step above covers the same point. The integration leaves the business with a database it controls (which APEX has always given you), a clean API surface (which the modernisation work adds), audit trail by default and permissions modelled in the data layer. That is the shape an AI agent would need to act on the production data safely; adding agents later becomes a scoping question rather than a foundation question. We do not build the agents in this engagement.
What if our APEX system runs alongside MYOB Advanced or Pronto?
Most do. The APEX system holds the production data; the ERP holds the customer, the invoice and the GL. The integration is the same shape as the other named-platform tails. The canonical record sits in one place, the ERP reads from it for invoicing, the APEX modules read from it for production scheduling, the modern web and mobile clients read from it for everything else. Reconciliation runs overnight against the ERP so finance and operations see the same numbers without somebody re-keying production totals into MYOB Advanced or Pronto by hand each month-end.
Not sure if the APEX system needs modernisation or a sharper licence review?
Start with a conversation. We will look at what your APEX system already does well, what the office and the floor have built around, and tell you whether you need modernisation, a rewrite, or just a tighter Oracle licence.