Moving Oracle EBS to OCI: what actually changes, and what does not

One of the most useful things a senior Oracle engineer can do in a strategy meeting is separate three questions that are routinely conflated: upgrading EBS from 12.1 to 12.2, moving Oracle EBS to OCI, and re-implementing on Oracle Fusion Cloud. They are three different decisions with three different risk profiles, three different cost profiles and three different timelines. Treating them as one decision is how good programmes go sideways.

This piece is about the middle one. What genuinely changes when you replatform EBS from an on-premise data centre onto Oracle Cloud Infrastructure. And, just as importantly, what does not.

Moving Oracle EBS to OCI is an infrastructure change. It is not an applications change. Your EBS release is still your EBS release. Your customizations are still your customizations. Your OAF pages behave the same way they did the day before. The database is the same database, running on different hardware in a different building, under a different operations model.

Oracle provides tooling to make this practical, including EBS Cloud Manager, and Bring Your Own License lets customers reuse existing EBS licences on OCI subject to the applicable licensing rules. That combination is why a lot of estates that were on aging on-premise hardware and facing a refresh cycle end up looking seriously at OCI. When the alternative is a capital purchase of new servers, storage and networking gear that will depreciate for the next five to seven years, an equivalent capacity on OCI as subscription cost changes the finance conversation. It does not by itself change the engineering conversation.

The list of things that genuinely change in an EBS lift and shift onto OCI is smaller than the marketing suggests but each item is real.

• The hardware refresh cycle disappears. You are no longer sizing storage arrays and compute for five year horizons. That is a legitimate structural saving over time and it is often what makes the initial business case work.
• Capacity becomes elastic. Non-production environments can be resized or turned off outside working hours. Test upgrade windows can be sized for the test and released afterwards. This changes how much you spend to run environments you only need occasionally.
• Disaster recovery becomes a configuration exercise rather than a second data centre. Standby databases and standby application tiers in a different OCI region are a solved pattern, and the DR test cycle becomes cheaper.
• Patching the infrastructure layer changes hands. Operating system patching, hypervisor patching, storage firmware, network gear, all of that becomes someone else's responsibility. Your team still owns the EBS technology stack, the database and the applications, but the layer below moves.

This is the part that quietly matters and that is easy to lose sight of when the conversation is dominated by a cloud pitch.

• Your customizations come with you. Every custom package, every custom form, every custom OAF page, every custom concurrent program. If it worked on-premise, it works on OCI. If it was fragile on-premise, it is fragile on OCI. A replatform does not remediate technical debt.
• Your integrations still need their network paths. Every SFTP endpoint, every SOAP or REST endpoint, every JDBC link, every database link, every file drop location, needs to be reachable from the new environment with the same certificates and the same credentials.
• Your interfaces to banks and to tax portals still need whitelisting from the other side. If a bank's payment gateway only accepts connections from a specific source IP range, that range has to be updated with the bank. If a tax authority portal is expecting your existing IP or certificate, that has to be re-established.
• Your printing arrangements still have to be solved. Physical printers, MFDs, cheque printers, label printers, they are all still on the customer's premises and they still need a print server that reaches them from the new environment.
• Your single sign on still has to be re-plumbed. If EBS was integrated with an on-premise identity provider, that integration has to be reproduced against the new topology, either against the same provider over a private connection or against a new one.
• Your technical debt is unchanged. The custom package that nobody understands is still there. The OAF page that is used by two departments is still there. The workflow that was designed for a legal entity that no longer exists is still there. OCI does not clean any of this up.

In practice, the majority of the effort in a well run EBS to OCI replatform is not the database and application move itself, which is well understood and well tooled. It is the surrounding topology.

• Network topology and latency. Anything that stays on-premise, warehouses, plants, retail sites, needs a well designed connection to the OCI region. FastConnect or a well engineered IPSec setup, sized for the traffic pattern, not just the peak throughput.
• Integrations and file transfer paths. Every SFTP source and destination reviewed, tested and switched. Nothing left pointing at the old data centre.
• Printing. A defined print architecture from the new environment back to the physical devices, with a clear owner.
• Single sign on and identity. A tested login path from the corporate identity provider to EBS in the new topology, including for administrators.
• Certificates. Every certificate the old environment presented or accepted, inventoried and reissued or renewed against the new hostnames where needed.
• Disaster recovery design. Which region is primary, which is standby, what the RPO and RTO are, and, crucially, when the first DR test will be run.

Bring Your Own License lets an organisation carry existing EBS and database licences onto OCI subject to Oracle's applicable rules. That is genuinely useful and it is often part of what makes the case, but licensing is not a topic to handle from a blog post. It should be confirmed with Oracle or a licensing specialist against your actual entitlements, your metrics and your target OCI shapes. Anyone who tells you the licensing is fine without that conversation is speaking outside their competence.

In the GCC, region choice for an EBS on OCI move is often driven less by latency and more by data residency and regulatory requirements. Saudi Arabia, the UAE and Qatar all have their own posture on where regulated data can reside, and OCI's regional footprint in the region is generally the reason a project can proceed on OCI at all. The same logic applies in the EU under GDPR and adjacent frameworks and in the UK. This is not a marketing detail. It is often the constraint that fixes the topology, and it should be established very early in the planning, not discovered late.

A replatform is not, by itself, an application modernization. It is an infrastructure move. But it is a moment when the entire estate is under test, which makes it an unusually good moment to deal with customization debt. The custom packages you were going to retire are now under a regression test anyway. The OAF pages you were going to rebuild in APEX are already going to be exercised end to end. Combining those pieces of work with the replatform sometimes makes sense, and sometimes it deliberately does not, because concentrating too many changes into one cutover raises the risk of the whole exercise. That is a judgement call for the programme, made in the open, with the trade offs written down.

Where it does make sense, our Capabilities page describes the wider Oracle scope we cover, and our OAF to APEX page describes how we retire OAF and Forms customizations without waiting for a big bang. What matters is that the decision is made deliberately, not as a byproduct of a cloud pitch.