Is there a deadline?
No hard one. Oracle continues to support Hyperion 11.2 on premises, so most organizations moving now are doing it by choice. The usual reasons are the cost of servers, patching, and specialist skills; an upgrade that would be nearly as much work as a move; and wanting the features Oracle now adds to the cloud every month.
The decision is easier with a clear view of what the current system costs to run and what the finance team actually uses. That view is also the first step of the migration itself.
What maps to what
| Hyperion (on premises) | Oracle EPM Cloud |
|---|---|
| Hyperion Planning | Planning (formerly PBCS / EPBCS) |
| Hyperion Financial Management (HFM) | Financial Consolidation and Close |
| FDMEE | Data Integration |
| Financial Reporting (HFR) | Reports |
| Data Relationship Management (DRM) | Enterprise Data Management |
| Account Reconciliation Manager (ARM) | Account Reconciliation |
| Profitability and Cost Management (HPCM) | Enterprise Profitability and Cost Management |
| Batch scripts and MaxL | EPM Automate and the REST APIs |
Smart View stays, so finance users keep working in Excel. What changes around them is that Oracle updates the platform every month, applying each update to Test on the first Friday and to Production on the third, and there are no servers to patch.
What Oracle’s migration covers
Planning. Oracle supports migrating on-premises Planning applications from releases 11.1.2.3, 11.1.2.4, and 11.2.x, with the source on the latest patch. Oracle lists two exceptions: 11.2.x applications on Essbase 21c, and on-premises Planning module applications such as Workforce and Strategic Modeling.
HFM.Hyperion Financial Management moves to Financial Consolidation and Close using Oracle’s Cloud EPM Migration Accelerator, for releases 11.1.2.3 and 11.1.2.4 on the latest patch.
A migration that runs cleanly brings the old design with it, including its workarounds. That is the right result for a well-built application, and the wrong one for an application the finance team has been working around for years.
Sources: Oracle, Supported Migration Paths; Oracle, Financial Management to Financial Consolidation and Close.
The order to do the work in
- Read the existing build first. List every application, cube, rule, data load, report, and integration, and who still uses each one. Hyperion systems that have run for a decade carry scenarios, rules, and reports nobody has opened in years.
- Decide, application by application, whether to migrate or redesign. A Planning application with a sound design can move across with Oracle's migration. One built around workarounds is usually cheaper to redesign on a current Planning module than to carry its problems into the cloud.
- Rebuild the data feeds early. Loads from the general ledger and other systems move from FDMEE and batch scripts to Data Integration and EPM Automate. They are what every later test depends on, so they come first, not last.
- Move reports straight to Reports. Financial Reporting is being removed from Oracle EPM Cloud in the February 2027 update, so Hyperion reports should land in Reports, not in Financial Reporting.
- Run old and new side by side. Keep Hyperion running until a full budget or close cycle produces the same numbers in both. A single month matching is not enough; year-end and the budget build are where differences show.
- Switch off on purpose. Set the switch-off date, archive what has to be kept, and retire the servers and licences. A Hyperion environment left running “just in case” keeps costing money and splits the source of truth.
The mistakes that cost the most time
- Treating it as a technical upgrade. The finance process changes too: monthly Oracle updates, new screens, and different ways of running loads and reports. The people who budget and close need to be part of the testing, not told about it afterwards.
- Lifting every rule and report across. Each one moved is one more to test and support. Retire what isn't used before migrating anything.
- Rebuilding HFM rule by rule. Financial Consolidation and Close has consolidation, translation, and eliminations built in, so much of a typical HFM rules file isn't needed. Start from the cloud design and add only what is genuinely specific to the business.
- Proving one month and calling it done. Run a full cycle in parallel, including the periods with the most adjustments, before anyone switches off Hyperion.
If you’d like help
A Health Check sets out what your Hyperion system costs to run, what is still used, and whether to migrate or redesign each application, before any migration work is committed.
Questions
- Do we have to move off Hyperion?
- Not yet. Oracle continues to support Hyperion 11.2 on premises; check Oracle's Lifetime Support Policy for current dates. The case for moving is usually cost and capability: servers, patching, and specialist skills on one side, monthly Oracle updates and new features on the other.
- Can Oracle migrate our Hyperion Planning application automatically?
- Often, yes. Oracle documents migration of on-premises Planning applications from releases 11.1.2.3, 11.1.2.4, and 11.2.x, with the on-premises system on the latest patch. There are exceptions: Oracle lists 11.2.x applications running on Essbase 21c, and on-premises Planning module applications such as Workforce and Strategic Modeling, as unable to migrate. Whether to migrate or redesign is a separate question from whether you can.
- How does HFM move to the cloud?
- Hyperion Financial Management moves to Financial Consolidation and Close. Oracle provides the Cloud EPM Migration Accelerator for HFM releases 11.1.2.3 and 11.1.2.4 on the latest patch. Because Financial Consolidation and Close has consolidation logic built in, much of the HFM rules file is replaced by configuration rather than copied.
- What happens to our Financial Reporting reports?
- They should move to Reports. Financial Reporting is being removed from Oracle EPM Cloud in the 27.02 update in February 2027, so there is no point landing Hyperion reports in it.
- How do we know the numbers match after the move?
- Run Hyperion and Oracle EPM Cloud side by side until a full budget or close cycle produces the same results in both, then switch off.