Ask three vendors how long it takes to move from Oracle E-Business Suite to Fusion Cloud Applications and you'll get three confident numbers, all of them shorter than reality. The gap isn't dishonesty so much as optimism: the demo-able parts of a migration are quick, and the parts that actually consume the calendar rarely make it onto a sales slide.
For a mid-sized UK organisation — a few hundred to a few thousand users, a couple of decades of EBS customisation, and the usual tangle of integrations — a realistic end-to-end programme runs closer to twelve to eighteen months than the six you may have been quoted. Here's where the time actually goes.
The phases, and the honest durations
Assessment & readiness
Cataloguing customisations, integrations, reports and the extensions you forgot existed. This is where you discover how much "standard" EBS was quietly bent to fit the business.
Design & fit-gap
Mapping current processes to Fusion's model. Every gap is a decision: adopt the standard way, or rebuild the bespoke one. The decisions are quick; the stakeholder agreement is not.
Build, configure & integrate
Configuration, data conversion routines, and reconnecting the integrations. Data migration alone — cleansing, mapping, reconciling — is routinely underestimated by half.
Test cycles
Multiple conversion test runs, system and integration testing, and the one everyone shortchanges: user acceptance testing. Plan for at least two full mock conversions before go-live.
Cutover & hypercare
The migration weekend is the visible part. The fortnight of hypercare afterwards — month-end close on a new system, fixing what only production reveals — is the part that earns trust.
Where the hidden months hide
Data quality. EBS has been accumulating data for years, and some of it is wrong in ways nobody noticed because the old reports tolerated it. Fusion is less forgiving. Cleansing is a project in itself, and it's almost always discovered too late.
Integrations. The headline interfaces are planned for. The quiet ones — a spreadsheet macro that pulls a nightly extract, a bank file in a format from 2009 — surface during testing and stop the line.
Decisions. Fusion rewards organisations willing to adopt standard processes. The technical work of changing a process is small; getting finance, procurement and HR to agree to change it is where weeks evaporate. The programmes that finish on time are the ones that resolve this in design, not during UAT.
Reporting. Users don't experience the new ERP through its architecture — they experience it through their reports. Rebuilding and re-validating reporting is consistently the most underestimated workstream, and the one most likely to delay sign-off.
How to make the number smaller honestly
You can compress the timeline, but by removing scope and risk, not by wishing. Start data cleansing before the build, not during testing. Freeze the fit-gap decisions early and hold them. Run mock conversions sooner and more often. And resist the temptation to "lift and shift" customisations that Fusion now does as standard — every one you carry forward is a future upgrade you'll pay for again.
None of this is a reason to avoid the move. EBS extended support has a horizon, and Fusion's continuous-update model is genuinely better once you're on it. It is simply a reason to plan against the real timeline, so the programme is judged a success rather than a slip.
Timelines above are typical ranges for a mid-sized organisation and will vary with scope, data quality and decision-making capacity. We're happy to pressure-test a specific plan against your estate.