When ETHX gets called into a stalled Oracle programme, we run the same five checks first. Between them, they surface most of the root causes within the first two weeks.
A stalled EBS-to-Fusion programme rarely has a single cause. More often, several smaller slips compound: scope that grew without being re-planned, data that no one owns, integrations that were assumed rather than built, a cutover that has never been timed, and a support model that no one has agreed to run. The five checks are designed to find those slips quickly, before anyone spends money on a new plan.
How do you rescue a stalled EBS-to-Fusion programme?
You rescue a stalled EBS-to-Fusion programme by establishing the real state of the programme before changing anything, then re-planning from evidence rather than from the original schedule. In practice that means five checks: re-baselining scope against what was signed off, confirming a single owner and workstream for data conversion, inventorying which integrations actually exist in code, running a timed cutover rehearsal, and naming who will own the close and day-to-day operations after go-live.
Each check produces a fact base rather than an opinion: a scope change log, a data ownership map, an integration inventory, a measured cutover duration and a support model with names against it. With those facts, the steering committee can decide whether to hold the go-live date, reduce scope, move to a phased rollout or reset the timeline, and it can make that decision knowing the consequences. A rescue that skips the diagnosis tends to become a second stalled programme.
Why EBS-to-Fusion programmes stall
Moving from E-Business Suite to Oracle Fusion Cloud is not an upgrade in the traditional sense. It is a reimplementation onto a SaaS platform with a different data model, a different approach to extension and a quarterly update cycle. Oracle's own guidance encourages customers to minimise customisations, use personalisation and configuration instead, and use the move to simplify and standardise business processes. Programmes that treat the move as a technical migration of the existing EBS estate tend to rebuild old customisations, carry over unclean data and discover late that their integrations need redesigning.
Oracle's implementation planning guidance also lists common causes of delay: unrealistic expectations for scope and timeline at the start, heavy workloads for team members juggling the programme and their day jobs, misalignment between the implementation team and leadership, and slow decision-making. A rescue has to address these conditions, not just the symptoms in the plan.
1. Is the scope still the original scope?
Scope creep is the most common stall. Re-baseline against the signed-off scope and surface every change since. Every approved change request, every informal addition and every EBS customisation that has quietly entered the Fusion design should be listed and traced back to a decision. The output is a single view of what the programme is now trying to deliver, compared with what was funded and planned.
What to look for
- EBS customisations being rebuilt in Fusion without a documented business case
- Reports and extensions added to the design but not to the plan
- Business units or geographies added to the first release without a revised timeline
- Design decisions that have been deferred rather than made
Where scope has grown, the answer is rarely to cut everything back. It is to decide explicitly what belongs in the first release and what can follow. Oracle notes that on-premises customers can integrate their existing applications with Oracle Cloud Applications and move business processes to the cloud incrementally, for example starting with a specific business unit or department. Its implementation planning guidance likewise describes a phased approach, rolling out in waves by business unit or function, as an alternative to going live all at once. A stalled big-bang programme can sometimes be recovered by resequencing into phases, provided the interim integrations between EBS and Fusion are designed and funded.
2. Is there a single owner of data?
If data conversion isn't a workstream with its own lead, your cutover is going to fail. Period.
Data conversion in an EBS-to-Fusion move means extracting from EBS, cleansing, transforming to the Fusion data model and loading through Oracle's import tools. For many ERP objects that is File-Based Data Import, which Oracle describes as useful both for initial data migrations and for ongoing bulk transfers. Oracle's implementation planning guidance recommends a dedicated data migration group that examines source data, removes redundancies and inconsistencies, maps it to the new structure and verifies the result against the source after loading. In a rescue, we check:
- Is there a named data lead with authority to make decisions on cleansing and the scope of historical data?
- Does each business object have a business owner who signs off its reconciliation?
- Have full-volume trial loads been run, with load times and errors recorded?
- Is there an agreed method for reconciling balances and open transactions from EBS to Fusion?
3. Are the integrations real or theoretical?
Most stalled programmes have integration plans that look great on slides and don't exist in code. Inventory the real state. The inventory should list every interface EBS supports today, its target design in Fusion, its build status, and whether it has been tested end to end with the real counterpart system rather than a stub. Oracle's planning guidance warns that integrations can cause unexpected delays and disrupt project timelines when they prove more complicated than expected.
Common gaps include interfaces that relied on direct EBS database access and have no equivalent in a SaaS model, integrations whose counterpart systems are owned by teams outside the programme, and interim EBS-to-Fusion interfaces needed for a phased rollout that were never scoped. Oracle positions Oracle Integration for connecting Oracle Cloud Applications with other cloud and on-premises applications, but choosing a platform is not the same as having working integrations. The only reliable status is a tested one.
4. Has anyone run a timed cutover rehearsal?
If the answer is no, the go-live isn't real. Run one — even a partial one — within two weeks of getting involved.
A cutover rehearsal should follow the real runbook: freeze EBS transactions, extract and load data in the planned sequence, move configuration, run reconciliations and work through the go/no-go checklist, with every step timed. Fusion setup is normally moved between environments rather than re-keyed; Oracle's documentation describes exporting setup data from an implementation project to a configuration package and importing it into another environment. Oracle's environment planning documentation notes that setup and extensibility can be migrated from non-production to production because all environments in a family are at the same update level.
What a first rehearsal usually tells you
- Whether the planned cutover window is realistic for the data volumes involved
- Which steps depend on a single person or on manual workarounds
- Which reconciliations cannot yet be completed
- Whether the quarterly update calendar has been factored into the go-live date
That last point is easy to miss. Oracle applies mandatory quarterly updates, with non-production environments updated about two weeks before production, so final rehearsals and the go-live weekend should be planned around the update calendar for your environments.
5. Who owns the close after go-live?
Programme handover into BAU is the second most common stall. If there's no named owner, build one before you build anything else.
The first period-end close on Fusion is where hidden problems tend to surface: unreconciled conversion balances, integrations that struggle under month-end volumes, and approval rules that were never tested with real users. Someone has to own that close, and the operations that follow it, before go-live rather than after. Oracle's planning guidance recommends keeping implementation team members committed for several months after go-live to support adoption, and treating the launch as a beginning rather than an end. In practice that means a named business owner for each process, a support model with clear escalation paths, a hypercare plan and a regression test approach for quarterly updates.
From diagnosis to recovery plan
Once the five checks are complete, the recovery plan follows from the evidence. The options usually come down to a small set: hold the date and reduce scope, hold the scope and reset the date, resequence into phases with interim integrations, or pause specific workstreams while foundations such as data ownership are fixed. What matters is that the steering committee chooses between options with known consequences rather than approving another optimistic schedule. A credible recovery plan contains:
- A re-baselined scope and release plan, with deferred items listed explicitly
- A data conversion plan with named owners, a trial load schedule and reconciliation criteria
- An integration inventory with a tested status for every interface
- A cutover runbook with timings from at least one rehearsal
- A post-go-live operating model, including hypercare and quarterly update testing
Our rescue assessments draw on our leadership's more than 15 years of Oracle delivery and a network of over 120 certified consultants across our US presence and offshore delivery centre in Pune, India. Where a recovery plan needs extra capacity, consultants for common roles can typically be shortlisted within 48 hours and deployed in 5 to 10 business days. After go-live we typically provide 4 to 8 weeks of hypercare, and optimisation sprints can follow once the system is stable.