Manufacturing IT lives with a split that most other industries do not have. The systems that plan the business, the ERP that owns orders, inventory, costing, and procurement, sit in a data centre or a regional hub, while the systems that run the business minute to minute, MES, quality, historians, and the control layer beneath them, sit inside the plant and cannot move. The ERP side is usually Oracle: EBS or JD Edwards running the order to cash and procure to pay cycles for the whole company, often on hardware now overdue for a refresh. The plant side is a patchwork of vendors and versions accumulated site by site through acquisitions and local decisions.
When the hardware refresh bill arrives, the cloud question follows, and for an Oracle heavy ERP estate OCI deserves a closer look than the default shortlist suggests. EBS and JD Edwards are Oracle products end to end; they run certified and fully supported on OCI with tooling built specifically for them, the database tier can land on Exadata, and bring your own license terms let the existing investment carry over instead of being repurchased. Across the engagements we have run, manufacturers moving Oracle ERP to OCI with a clean BYOL position and honest sizing have averaged around 40% lower infrastructure spend than the estate they left, before counting the hardware they no longer have to refresh. This article is part of our OCI by industry series, and it covers the manufacturing case specifically: why the estate looks the way it does, how EBS and JD Edwards land on OCI in practice, where the boundary between cloud and plant has to sit, and how to build plant analytics that replace the spreadsheets rather than adding to them.
Why manufacturing estates look the way they do
The centre of gravity is the ERP. Whether it is EBS running full financials, manufacturing, and supply chain, or JD Edwards doing the same for a business with a heavier distribution profile, the ERP is the system of record for what to make, what to buy, what it costs, and what shipped. It carries a nightly planning run, MRP or a fuller supply chain planning engine, that turns demand into a schedule, and every plant, supplier, and warehouse downstream works from its output. The planning window is the manufacturing equivalent of a bank's overnight batch: if it does not finish on time, the morning shift starts the day on yesterday's plan.
Below the ERP sits the plant layer, and it obeys different physics. MES tracks work orders and operations as they move down the line. Quality systems hold inspection plans and results. Historians ingest sensor readings from thousands of tags. Label printers, scales, scanners, and vision systems talk to all of it, and beneath everything sits the control layer of PLCs and SCADA. These systems are latency sensitive in a way the ERP is not: an operator scanning a completion expects a response before the next part arrives, and a line that stops because a remote system blinked is measured in lost output per minute. Just as important, the plant must keep running when the wide area network does not. Any architecture that puts a WAN hop inside the line's critical path has already failed its first design review.
Analytics is where the split hurts the most. The data that would answer the questions plant managers actually ask, why yield dropped on line three, which shift produces the most scrap, whether overall equipment effectiveness improved after the maintenance programme changed, lives in three places that do not talk to each other: the ERP, the MES, and the historian. So the answers live in spreadsheets, assembled by hand, a week late, and differently at every site. Most manufacturers do not have an analytics tooling problem; they have a data gravity problem, and solving it is one of the better reasons to put the ERP and the analytical store on the same cloud.
Running EBS and JD Edwards on OCI
EBS on OCI
EBS remains certified and fully supported on OCI, and the practical tooling matters as much as the certification. EBS Cloud Manager automates provisioning, cloning, backup, and restore of complete EBS environments, which turns the most painful routine in EBS operations, standing up a fresh clone for a project or a patch cycle, from a multiday DBA exercise into a scheduled job. The database tier can run on Base Database Service for midsize estates or on Exadata Database Service where the planning run and the month end close need the throughput, and the application tier scales on flexible compute shapes sized to actual load rather than to the peak guess made at the last hardware purchase. For manufacturers, the workload that decides the database platform is almost always the planning run: MRP against a large item master with deep bills of material is exactly the mixed batch profile that Exadata's storage offload was built to absorb.
JD Edwards on OCI
JD Edwards estates are typically leaner than EBS estates and even better suited to the move. Oracle ships One Click Provisioning for EnterpriseOne on OCI, which stands up a complete, patched JDE environment in hours, and the 9.2 release line with its continuous delivery model removes the big bang upgrade as a reason to wait. The architecture questions that matter are manufacturing specific: where the plants sit relative to the OCI region, because shop floor transactions such as work order completions, backflush, and inventory moves run against the central instance; how the interfaces to MES and warehouse systems are sequenced during cutover; and how the development, test, and prototype environments are scheduled so they stop costing money at night and on weekends. We cover the sizing, the tools release strategy, and the migration sequencing in detail in our dedicated guide to JD Edwards on OCI.
The licensing and economics side
The money case rests on three legs. First, BYOL: the database and middleware licenses already owned under the ERP carry over to OCI, so the move is an infrastructure decision rather than a repurchase, provided the entitlements are actually clean. Second, right sizing: most on premises ERP estates were sized for a peak that occurs a handful of days each month, and flexible shapes let the steady state be small while the peak is temporary. Third, the nonproduction estate: development, test, training, and project environments routinely outnumber production three to one in ERP land, and scheduling them to run business hours only is the single fastest saving available anywhere in the programme. Those three levers together are where the 40% average reduction comes from, and none of them requires heroics.
| Manufacturing workload | OCI service fit | Key constraint |
|---|---|---|
| ERP production (EBS or JD Edwards) | Exadata or Base Database Service plus flexible compute | Planning run window, month end close, BYOL coverage |
| ERP development and test | Compute and database services scheduled on demand | Clone automation, data masking, business hours scheduling |
| MES and plant execution | Stays at the plant, integrates over FastConnect | Line must survive WAN loss, latency to operators |
| Historian and sensor ingest | Streaming into Object Storage, edge buffering at site | Tag volume, store and forward during outages |
| Plant analytics and OEE reporting | Autonomous Data Warehouse over an Object Storage lake | Conformed model across ERP, MES, and historian data |
| Planning and scheduling engines | Flexible compute scaled to the planning calendar | Throughput inside a fixed overnight window |
| EDI and B2B integration | OCI Integration and OKE across availability domains | Partner SLAs, message ordering, always on availability |
MES integration and the plant boundary
The most important architectural decision in a manufacturing cloud programme is also the least glamorous: drawing the line between what moves and what stays. The control layer never moves; PLCs, SCADA, and anything in the safety path belong to the plant. MES is the judgement call, and the judgement usually lands on keeping execution at the site. A line that must keep producing through a WAN outage needs its work order state, its routings for the current shift, and its quality checks available locally. What moves to OCI is everything above that: the ERP the MES reports into, the integration layer between them, the analytical copies of plant data, and the planning engines that decide what each site builds next week.
Once the boundary is drawn, connectivity becomes an engineering problem with numbers attached. FastConnect provides private, deterministic links between OCI and the plants or the hub sites that front them, and the design work is in the latency budgets: which transactions cross the boundary synchronously, which queue and forward, and what the operator experience is in each failure mode. The honest pattern is to make every interaction in the line's critical path asynchronous or local, so the scan succeeds against the site system and the ERP catches up seconds later. Manufacturers who skip this analysis discover where the synchronous calls are hiding on the first afternoon the circuit flaps.
For sites where data residency, defence contracts, or sheer remoteness make a public region awkward, OCI has hardware answers as well as network ones. Roving Edge Infrastructure puts OCI compute and storage in a portable, plant friendly form factor for ingest and local processing, and Compute Cloud@Customer or a full Dedicated Region brings OCI services inside the company's own walls when the data genuinely cannot leave. Most manufacturers need none of this; a well designed FastConnect topology with local buffering covers the overwhelming majority of plants. But the escalation path matters, because one regulated site should not dictate the architecture for thirty ordinary ones.
Plant analytics without the spreadsheet swamp
The analytics opportunity is the part of the programme that pays for the rest of it politically. The pattern that works is unromantic: land everything in one place first, model it second, dashboard it last. Historian extracts, MES transactions, and ERP cost and order data flow into Object Storage as the cheap, durable lake; Autonomous Data Warehouse sits on top as the conformed layer where a work order means the same thing whether it came from the ERP or the MES; and the analytical tools read from that layer instead of from seventeen local extracts. Because the ERP is already on OCI, its data arrives by replication rather than by nightly file gymnastics, and the lineage from a number on a dashboard back to a transaction in the ERP is short enough to defend in a production meeting.
What changes for the plants is the time axis. Overall equipment effectiveness stops being a monthly argument about whose spreadsheet is right and becomes a daily number computed the same way at every site. Scrap and yield analysis can correlate quality results with the machine conditions the historian recorded at the moment the part was made, which is the analysis every quality engineer wants. And once the conformed layer exists, the more ambitious work, predictive maintenance models on GPU shapes, demand sensing feeding the planning run, becomes an incremental project instead of a moonshot. The order matters: manufacturers who buy the machine learning platform before they have conformed data buy a very expensive way to discover their site naming conventions disagree.
Operationally, the analytics estate is also the right place to start. It carries no production risk, it shows value to plant managers in weeks, and it exercises the landing zone, the network, and the operating model before the ERP moves. The estates we run under 24/7/365 monitoring almost always grew this way: analytics first, nonproduction ERP second, production last.
A six step path for a manufacturer adopting OCI
- Inventory the ERP estate and its licenses. Every database, edition, option, and middleware component, mapped to entitlements, because the BYOL position sets the economics of the whole programme.
- Draw the plant boundary explicitly. Decide per system what moves, what stays at the site, and what the line does during a WAN outage, and write the failure behaviour down before anyone draws a target architecture.
- Size the region and the network around the planning run. Pick the OCI region against plant and hub latency, size FastConnect for the nightly load, and treat the planning window as the constraint the design must protect.
- Build the landing zone and land analytics first. Compartments, identity, logging, and the data lake, proven on a workload that cannot stop a production line.
- Move the ERP in rehearsed stages. Nonproduction first to validate the clone and patch automation, then production with a rehearsed cutover timed against the manufacturing calendar, never against a quarter close or a seasonal peak.
- Industrialise the run state. Monitoring, batch and planning run alerting, DR rehearsals, and a monthly cost review, because the 40% number erodes quietly if nobody owns it after go live.
Where manufacturing sits in the wider industry picture
Manufacturing shares its core pattern, a heavy Oracle ERP at the centre and unmovable operational systems at the edge, with several neighbouring industries, and reading the cases together sharpens all of them. Utilities run the same split with higher stakes, where SCADA and outage management take the place of MES and the regulator audits the boundary, covered in OCI for utilities. Logistics operators run JD Edwards and transport systems against networks of depots that look a lot like plants, covered in OCI for logistics. And energy companies pair enormous ERP estates with field operations whose data volumes dwarf most factories, covered in OCI for energy. In every case the ERP moves, the operational layer stays, and the value concentrates in how carefully the boundary between them is engineered.
For a manufacturer, the practical conclusion is straightforward. OCI does not need to win the plant floor, and it should not try; the plant floor was never going to a cloud anyway. It needs to win the ERP, the planning engines, and the analytical estate, which is where the refresh money, the licensing leverage, and the unanswered questions about yield all live. Plan the move around the planning window, the plant boundary, and the manufacturing calendar, and the programme is a sequence of controlled, reversible steps. Plan it around a slideware target architecture instead, and the first schedule miss becomes the most expensive design review the company has ever attended.
Free white paper
Go deeper on this topic with The OCI Migration Playbook, a step by step framework for planning and running an OCI migration with less risk. An independent analyst style report with comparison tables and recommendations, free with a work email. Prefer a monthly summary instead? The OCI Brief delivers one practical OCI briefing a month.
Part of a series
This guide is part of OCI by Industry — our complete pillar guide on the topic.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings.