×
Startup Support Program
Free AWS Credits · Dedicated Cloud Architect · Limited Seats
Trusted Digital Transformation Partner
Oracle EBS to OCI migration is a lift-and-shift: the same E-Business Suite application, the same customisations and the same data, moved from your data centre onto Oracle Cloud Infrastructure. It is not the same decision as moving to Fusion Cloud, which is a re-implementation typically measured in 12 to 36 months. Most organisations reach for OCI when the driver is infrastructure — hardware bought around 2020–21 now reaching end of life — rather than a need for new application capability. Oracle has committed Premier Support for EBS 12.2 through at least 2037, so moving to OCI buys you modern infrastructure without forcing an application decision you are not ready to make.
These get conflated in sales conversations. They should not be. Answer this honestly and the rest of the project follows.
These are not mutually exclusive. Moving to OCI first is a legitimate way to buy planning time — you solve the hardware deadline this year and take the Fusion decision on evidence rather than under pressure. Anyone telling you OCI is a wasted step has not priced the risk of a rushed re-implementation.
Oracle commits Premier Support for E-Business Suite 12.2 “through at least 2037” and states there are no forced migrations. Any urgency you are feeling is about the tin under it, not the application on top.
Oracle — E-Business Suite SupportIndustry analysis identifies 2026 as a pivotal year for EBS-to-OCI moves specifically because servers bought in the 2020–21 refresh cycle are now reaching end of life — forcing a buy-again-or-move decision.
DEEP — 2026, a pivotal year for EBS on OCIThe technical work is well understood — Oracle provides EBS Cloud Manager for exactly this. What determines success is the unglamorous part: knowing what your customisations do, and proving the cutover before you commit to it.
We rehearse the cutover at least once end to end. A migration plan that has never been executed is a document, not a plan.
Current release and patch level, database size and change rate, integrations, and a full CEMLI inventory — every customisation, extension and interface, including the ones nobody documented.
OCI shapes and storage sized against your real AWR data rather than a template, VCN and compartment design, Data Guard standby, and the licence position under BYOL before anything moves.
Stand up the target, run a full migration into it, and let the business test against real data. This is where the surprises surface, which is the point of doing it early.
Repeat the whole cutover to a timed script, including rollback. We measure the actual window rather than estimating it, so the business signs off on a number we have proven.
Production cutover in the agreed window, then hypercare through at least one month-end close — the first period close is the real acceptance test, not go-live day.
None of these are OCI problems. They are discovery problems, and they are cheaper to find in week two than in the cutover window.
Tell us your EBS release, database size and when your hardware runs out. We will come back with the realistic options — and if staying where you are for another year is the right answer, we will say so.
Powered by AI · Typically replies instantly