Oracle Hyperion Planning is in extended support. Oracle’s development investment, security patching priority, and product roadmap have moved entirely to Oracle Cloud EPM. For the hundreds of organisations across Egypt, Saudi Arabia, the UAE, Qatar, Kuwait, and Bahrain that built their financial planning and budgeting on Hyperion Planning — in many cases running implementations that have been in production for eight to fourteen years — the migration question is no longer whether. It is when, how, and what the migration will actually cost and require.
The honest answer is that a Hyperion to Oracle Cloud EPM migration in the GCC and Egypt is not the straightforward technical project that vendor documentation suggests. The regional context — Arabic-language planning models, ZATCA and ETA regulatory integration, GCC organisational structures, local ERP systems, complex dimension designs accumulated over years of customisation — adds a layer of complexity that most generic migration guides do not address and that most implementation teams without direct regional experience underestimate.
This guide is the most complete resource available in the region on what the migration actually involves. It covers what changes between Hyperion and Cloud EPM at the component level, what the migration phases look like in practice, what the cost and timeline realities are for GCC and Egyptian organisations, what the most common migration failures are and why they happen, and what the questions are that every CFO and CIO should be asking before they commit to a migration scope and partner.
Why the Migration Decision Cannot Be Deferred
The Extended Support Trap
Oracle’s extended support for Hyperion Planning carries a premium maintenance fee — typically 20 percent above standard support rates — for a product that is receiving no new feature development. Every quarter that an organisation remains on Hyperion Planning, it is paying more for less: higher maintenance costs, no access to the capabilities that Oracle is developing exclusively for Cloud EPM, and an increasing gap between the planning environment and the Oracle ecosystem that surrounds it.
The practical consequences are already visible in many GCC Hyperion environments. Oracle Fusion integrations that would be straightforward in Cloud EPM require custom connectors in Hyperion. Narrative reporting capabilities available in Cloud EPM are not available in Hyperion. The quarterly update cadence that Cloud EPM customers receive automatically requires a managed upgrade project on-premises — a project that most GCC IT teams have deferred for several cycles, creating an increasing gap between the installed version and the current one.
The cost of staying on Hyperion is not only the premium maintenance fee. It is the accumulated opportunity cost of capabilities that are not available, integrations that require workarounds, and a planning environment that is increasingly disconnected from the Oracle platform direction.
The IFRS 18 Acceleration
IFRS 18 is effective for annual periods beginning on or after 1 January 2027. Its requirements — mandatory income statement categories, management performance measure disclosure, comparative period restatement — need to be produced by the EPM environment as part of the standard close output. Cloud EPM has been designed and updated to support IFRS 18 natively; Hyperion Planning has not. Organisations planning their first IFRS 18 close in early 2028 and still running Hyperion Planning will need to produce IFRS 18 compliant outputs through a combination of offline calculation and manual adjustment — a process that is manageable once and unsustainable as a repeating close activity.
For GCC and Egyptian organisations planning a Hyperion migration, the IFRS 18 timeline creates a practical deadline: a migration that is well-designed and goes live in 2026 gives the finance team a full planning and close cycle to stabilise the Cloud EPM environment before the first IFRS 18 reporting period arrives.
What Oracle Cloud EPM Is — and How It Differs From Hyperion Planning
Oracle Cloud EPM is not a single product. It is a suite of cloud-based financial performance management modules, each serving a specific function and each replaceable separately or in combination. Understanding the product map is essential before scoping a migration.
| Hyperion Product | Cloud EPM Successor | Primary Function |
|---|---|---|
| Hyperion Planning | Oracle PBCS / EPBCS | Financial planning, budgeting, driver-based forecasting, workforce planning |
| Hyperion Financial Management (HFM) | Oracle FCCS | Multi-entity group consolidation, intercompany elimination, multi-GAAP reporting |
| Hyperion Financial Data Quality Management (FDM / FDMEE) | Oracle Data Management / EPM Integration Agent | Data integration and mapping from ERP to EPM |
| Hyperion Financial Reporting (FR) | Oracle Cloud Financial Reporting Studio | Formatted financial report output |
| Hyperion SmartView | Oracle SmartView for Cloud | Excel-based EPM data access and analysis |
| Hyperion Tax Provision | Oracle Tax Reporting Cloud (TRCS) | Tax provisioning, deferred tax, country-by-country reporting |
| Hyperion Profitability and Cost Management | Oracle PCMCS | Cost allocation, activity-based costing, margin analysis |
| Hyperion Strategic Finance | Oracle Cloud EPM Strategic Modelling | Long-range financial modelling |
The most common migration scope for GCC organisations is Hyperion Planning to PBCS or EPBCS — the planning module. HFM migrations to FCCS are a separate programme with a different scope profile (covered in our FCCS guide). Both can be done simultaneously or sequenced; the sequencing decision depends on which platform is under the most immediate pressure and which migration carries the higher design complexity.
What Migrates, What Does Not, and What Must Be Redesigned
This is the section that most vendor migration guides handle inadequately — and where the most expensive migration surprises originate.
| Hyperion Planning Component | Migrate Directly? | What Actually Happens |
|---|---|---|
| Dimension metadata (accounts, entities, scenarios, periods, custom dims) | Partially | Exportable but requires remapping — PBCS dimension types differ from Hyperion; member properties and aliases need review and often redesign |
| Planning unit hierarchy | No | Must be rebuilt in PBCS process management — Hyperion’s planning unit concept does not map directly |
| Business rules (Calculation Manager scripts) | No | Must be rewritten in Groovy or PBCS Calculation Manager — logic can be reused but the language and architecture differ |
| Custom VBScript / MaxL scripts | No | Must be fully rewritten; these do not exist in Cloud EPM |
| Data forms and dashboards | No | Must be rebuilt in PBCS Form Designer; the design can reference existing forms but cannot be imported |
| FDMEE / FDM data integration mappings | Partially | EPM Integration Agent replaces FDMEE; mapping logic is reusable but the tooling and connectivity model differ |
| SmartView reports and templates | Mostly | SmartView for Cloud is broadly compatible but some advanced functionality requires adjustment |
| Financial Reports (Hyperion FR) | No | Must be rebuilt in Cloud Reporting Studio; the logic is transferable but not the files |
| Workforce planning models | Partially | EPBCS includes native workforce planning frameworks that may replace custom Hyperion workforce models; comparison required |
| Capital planning models | Partially | As above — EPBCS capital framework vs custom Hyperion approach |
| Historical data (actuals, budgets, forecasts) | Yes | Exportable from Hyperion and loadable into PBCS with validated period and entity mapping |
| Arabic-language metadata | N/A | If Arabic metadata existed in Hyperion, it must be rebuilt in Cloud EPM; if it did not exist, the migration is the opportunity to create it |
The table above makes clear why a lift-and-shift migration is not a viable approach for most GCC Hyperion environments. The components that cannot be directly migrated — business rules, data forms, financial reports, planning unit hierarchy — represent the majority of the custom implementation work that was done in Hyperion over years. These need to be rebuilt, not transferred.
Rebuilt, however, does not mean recreated identically. A business rule that was written in Hyperion to compensate for a dimension structure limitation may not need to exist in Cloud EPM where the architecture addresses the underlying problem differently. A data form that required complex workarounds in Hyperion may be achievable straightforwardly in PBCS. The migration assessment phase should distinguish between customisations that were necessary and customisations that were workarounds — because the former need to be reproduced in Cloud EPM and the latter do not.
The Migration Phases: What Realistic Delivery Looks Like in the GCC
Phase 1 — Migration Assessment (5–8 weeks)
The assessment phase is the most important and most frequently compressed phase of a Hyperion to Cloud EPM migration. Its output is not a migration plan — it is a Cloud EPM design specification that happens to be informed by what Hyperion was doing.
The assessment covers: a complete inventory of the current Hyperion environment — dimensions, business rules, data forms, integration mappings, reports, and SmartView templates — categorised by whether each component is in active use; a classification of each customisation as required (serving a genuine business requirement) versus accumulated (compensating for a platform limitation or historical design decision that no longer needs to exist in Cloud EPM); a mapping of the Arabic-language and regional regulatory requirements (ZATCA, ETA, Hijri calendar, IFRS 18) that must be built into the Cloud EPM environment from day one; and an assessment of the ERP integration landscape and what needs to change to connect source systems to Cloud EPM through the EPM Integration Agent.
The output is a Cloud EPM design document — scoped, costed, and agreed by finance — that the build phase works from.
Phase 2 — Cloud EPM Build (12–20 weeks)
The build phase configures the PBCS or EPBCS environment to the design specification: dimension build, business rule development in Groovy and Calculation Manager, EPM Integration Agent configuration and data mapping validation, form and dashboard build, financial report construction in Reporting Studio, Arabic-language metadata build, ZATCA data flow validation, IFRS 18 category structure, and SmartView template creation.
The most time-consuming components in GCC environments are business rule development (complex workforce and capital planning logic takes significant time to rebuild correctly and test against expected outputs) and Arabic-language configuration (if this is being built into the environment for the first time, the bilingual dimension metadata and Arabic-language report templates require structured work that is not complex but is time-intensive to get right).
Phase 3 — Integration Testing and Data Migration (6–10 weeks)
This phase validates the complete data flow from each source ERP to Cloud EPM: that the EPM Integration Agent is extracting, transforming, and loading data correctly; that the account mapping is producing the expected results against known historical data; that data volumes are loading within acceptable performance parameters; and that the actuals appearing in PBCS match the source ERP figures at every level of the hierarchy that the planning model uses.
Historical data migration — loading prior year actuals, prior year budget, and prior year forecasts into the Cloud EPM environment — is done during this phase and validated against the Hyperion historical data to confirm consistency.
Phase 4 — Parallel Run and User Acceptance (4–8 weeks)
The parallel run phase runs the first live planning cycle or close process on Cloud EPM in parallel with Hyperion, comparing outputs and resolving differences before the cut-over. This phase consistently surfaces issues that the test scripts did not anticipate — edge cases in the business rules, data volumes that behave differently in production than in test, user experience issues that emerge when the finance team is running the process under real time pressure rather than in a structured test environment.
This phase should not be compressed to meet a project timeline. The parallel run is what builds the finance team’s confidence in the Cloud EPM environment. Cut-over before that confidence is established produces a go-live on time and an adoption problem for the following six months.
Phase 5 — Cut-Over and Post-Migration Stabilisation (4–8 weeks)
Hyperion is decommissioned. The finance team runs their first fully live planning cycle or close on Cloud EPM without a Hyperion parallel. This is when the implementation team’s availability matters most — the questions that arise during the first live process are the ones that determine whether the finance team’s confidence in the system grows or erodes.
Post-migration stabilisation is not the same as support. It is active partnership — the implementation team available to resolve issues the same day they arise, to tune business rule performance under live data volumes, and to adapt the environment where the live process reveals that a design decision made during the build phase needs adjustment.
Regional-Specific Considerations That Determine Migration Complexity
Arabic-Language Planning Environments
Many Hyperion Planning environments in the GCC were implemented by teams without Arabic-language EPM experience and are running in English, despite the finance team’s primary working language being Arabic. The migration is the opportunity to build Arabic-language operation into the Cloud EPM environment correctly: bilingual dimension metadata with Arabic aliases for every account, entity, cost centre, and scenario; Arabic-language data entry forms with right-to-left rendering; Hijri calendar period support for Saudi entities; and Arabic-language user guides and training materials.
Organisations that treat the migration as a pure technical transfer and do not include Arabic-language configuration in the scope produce a Cloud EPM environment with the same English-language limitations as the Hyperion environment it replaced — and miss the single best opportunity to close the gap between how the finance team works and how the system operates.
ZATCA Integration and the ERP Data Flow
Saudi organisations operating under ZATCA Phase 2 need to validate that the EPM Integration Agent connection between the ERP and PBCS correctly reflects the post-ZATCA state of the ERP data. ZATCA Phase 2 changed how invoice data is structured and validated in the ERP; an FDMEE integration that was built before ZATCA Phase 2 was implemented may be mapping data from ERP structures that no longer exist in their original form.
The migration assessment phase should explicitly include a ZATCA data flow validation: confirming that the account structures, entity assignments, and VAT coding in the post-ZATCA ERP map correctly to the PBCS dimension structure, and that the actuals data arriving in PBCS after migration reflects the current ERP state rather than a historical mapping.
IFRS 18 — Build It In, Not On
Every Hyperion to Cloud EPM migration that goes live in 2026 or 2027 is building for an organisation that will need to produce IFRS 18 compliant financial outputs by early 2028. The PBCS environment — specifically the account dimension and the planning model’s output structure — should be designed with the IFRS 18 mandatory income statement categories in scope from the migration build phase.
Retrofitting IFRS 18 into a Cloud EPM environment after go-live is not technically complex, but it requires dimension changes and business rule modifications that create a period of instability in the planning model. Designing for IFRS 18 from the start adds two to three weeks to the build phase and eliminates a post-go-live restructuring project.
Non-Oracle ERP Integration
Not every GCC enterprise runs Oracle EBS or Fusion. SAP is common in Saudi Arabia across large corporates, government-linked entities, and multinationals. Microsoft Dynamics is prevalent in mid-market Egyptian enterprises. Local ERP systems — including Arabic-native accounting platforms — are used across the region.
The EPM Integration Agent in Oracle Cloud EPM connects to a wide range of source systems, but the integration design for each non-Oracle ERP is specific: the data extraction mechanism, the transformation logic, and the connection testing process differ from Oracle-to-Oracle connections. Organisations migrating from Hyperion with non-Oracle ERP integrations should budget for dedicated integration design and testing time for each source system, not assume that the existing FDMEE mapping will transfer to the EPM Integration Agent without redesign.
Migration Timeline and Cost Reality
| Organisation Profile | Timeline | Professional Services (USD) | Oracle Subscription (Annual, USD) |
|---|---|---|---|
| Single-country, single ERP (Oracle Fusion/EBS), PBCS only, no Arabic config, <500 users | 5–8 months | 80,000–150,000 | 40,000–90,000 |
| Single-country, single ERP, PBCS + FCCS combined, no Arabic config | 8–12 months | 160,000–280,000 | 80,000–160,000 |
| Multi-country GCC, Oracle ERP, PBCS + FCCS, with Arabic-language config | 10–14 months | 220,000–360,000 | 100,000–200,000 |
| Multi-country GCC, mixed ERP (Oracle + SAP or local), PBCS + FCCS, Arabic config, ZATCA integration | 12–18 months | 280,000–480,000 | 120,000–250,000 |
| Full Cloud EPM suite (PBCS + FCCS + ARCS + PCMCS + TRCS), multi-country, mixed ERP, Arabic config | 16–24 months | 400,000–700,000+ | 180,000–350,000+ |
Notes on these figures:
- Timeline starts from requirements sign-off and design completion — not from contract signature.
- Arabic-language configuration, ZATCA data flow validation, IFRS 18 category design, and Hijri calendar support each add to scope and should be line-itemed explicitly in the statement of work.
- Oracle subscription costs are indicative; Oracle’s commercial terms vary by geography, organisation size, and negotiation. GCC organisations should request quotes that explicitly include all modules in scope.
- The most consistent cause of cost and timeline overrun is undiscovered complexity in the existing Hyperion environment: business rules that were more complex than the design documentation suggested, data quality issues in the ERP integration that were being compensated for manually in Hyperion, or Arabic-language requirements that were not surfaced during the scope assessment because the assessment was conducted in English.
The Five Most Common Hyperion Migration Failures in the GCC and Egypt
1. The Migration Was Scoped as a Technical Transfer, Not a Business Redesign
The project was defined as “migrating Hyperion to Cloud EPM” rather than “building a Cloud EPM planning environment informed by what Hyperion was doing.” The implementation team replicated the Hyperion dimension structure, rebuilt the business rules to match Hyperion’s logic exactly, and recreated the data forms in Cloud EPM’s form builder. The migration was completed on time. The finance team has a Cloud EPM environment that does everything Hyperion did — including the design problems and workarounds that had accumulated over a decade.
2. Business Rules Were Rebuilt Without Being Understood
The Hyperion business rules were handed to the Cloud EPM development team as documentation (if they were documented at all) or as source code (if they were not). The team rebuilt them faithfully. Several rules contained logic that compensated for dimension structure limitations in Hyperion that no longer exist in Cloud EPM. The compensating logic now produces incorrect results in the Cloud EPM architecture. The errors surface at the first live planning cycle and take three months to diagnose and correct.
3. The FDMEE-to-EPM Integration Agent Transition Was Underestimated
The existing FDMEE data integration between the ERP and Hyperion was assumed to transfer to the EPM Integration Agent with minimal work. The project allocated two weeks for integration cutover. The actual work took eight weeks, because the FDMEE mapping was partially undocumented, some source ERP structures had changed since ZATCA implementation without the mapping being updated, and the EPM Integration Agent’s connectivity model for the organisation’s non-Oracle ERP required a custom connector that had not been scoped.
4. Arabic-Language Configuration Was Left Out of Scope
The migration assessment was conducted by an English-language implementation team. The Arabic-language requirements — used by 80 percent of the finance team’s daily planning activities — were not surfaced during the assessment. Arabic-language configuration was listed as a future enhancement. The Cloud EPM environment went live in English. Finance team adoption among Arabic-speaking users is partial. Three years after the migration, the Arabic-language configuration has still not been completed because no budget has been allocated to a project that was supposed to have been done at migration time.
5. The Parallel Run Was Compressed to Meet the Go-Live Date
The project was running two weeks behind schedule entering the parallel run phase. The decision was made to compress the parallel run from six weeks to three weeks to recover the timeline. The three-week parallel run did not surface two significant business rule errors and a data integration timing issue that only appeared when the full month-end data load ran under live conditions. These issues were discovered during the first fully live close cycle, after Hyperion had been decommissioned. Resolving them in production, without the Hyperion parallel available for comparison, took five weeks and required manual intervention in the first two post-migration close cycles.
What CFOs and CIOs Should Demand Before Committing to a Migration Partner
“Show us a Hyperion to Cloud EPM migration you have delivered in the GCC or Egypt — specifically for an organisation with a comparable complexity profile to ours.” The migration experience that matters is regional migration experience: with Arabic-language configuration, ZATCA data flow requirements, GCC organisational structures, and the specific ERP systems in use in the region. A migration partner whose GCC track record consists of straightforward single-country, single-ERP, English-language migrations is not the same as one whose track record includes the complexity your environment contains.
“Walk us through how you assess which of our Hyperion business rules need to be redesigned rather than rebuilt.” This question reveals whether the migration team understands the architectural differences between Hyperion and Cloud EPM at a depth that allows them to distinguish between rules that are still necessary and rules that were compensating for Hyperion limitations. A team that rebuilds every rule identically will deliver a Cloud EPM environment with Hyperion’s problems; a team that distinguishes between the two will deliver a Cloud EPM environment that improves on Hyperion.
“How do you handle the Arabic-language configuration — specifically, bilingual dimension metadata, Hijri calendar periods, and Arabic-language report templates — and at what phase of the project does this work happen?” The answer to the last part of this question is revealing. Arabic-language configuration that happens in the build phase is designed into the environment. Arabic-language configuration that happens post-go-live is deferred — and in practice, is frequently never completed.
“What is your process for validating the EPM Integration Agent data flow against our post-ZATCA ERP state before the migration goes live?” A credible answer describes a specific validation methodology: a set of reconciliation checks between the source ERP and the Cloud EPM actuals at every level of the hierarchy, run against multiple periods of historical data before the cut-over. An answer that relies on the integration loading without errors as the validation criterion is not a validation methodology.
“What does the parallel run look like — specifically, what is the minimum parallel run period you recommend, what reconciliation checks run during it, and under what conditions would you extend it?” Any credible migration team will push back against a compressed parallel run. A team that accepts a one or two-week parallel run without expressing concern about the risk is either inexperienced or is prioritising schedule over delivery quality.
Frequently Asked Questions
Q: Is Oracle Hyperion Planning being discontinued? Oracle Hyperion Planning is not discontinued — it is in extended support, which means Oracle continues to provide security patches and critical fixes but is no longer developing new features for the on-premises product. Oracle’s official position is that Cloud EPM is the strategic direction for all EPM customers. Extended support carries a premium maintenance fee (typically 20 percent above standard support rates), and the long-term trajectory toward end-of-support is clear even if a firm end date has not been announced. For organisations planning a multi-year EPM investment, Hyperion Planning is not a viable long-term platform.
Q: How long does a Hyperion to Oracle Cloud EPM migration take in the GCC? A realistic range is five to eight months for a focused single-country, single-ERP migration with standard English-language configuration, and twelve to eighteen months for a complex multi-country GCC migration including Arabic-language configuration, ZATCA integration, FCCS migration alongside Planning, and multiple ERP source systems. Timeline starts from when the migration design is signed off — not from contract signature. The assessment phase alone takes five to eight weeks for a complex GCC environment. Organisations that compress the assessment phase consistently discover the consequences during the build phase, when it is more expensive to address them.
Q: What is the difference between PBCS and EPBCS, and which one should we migrate to? Oracle Planning and Budgeting Cloud (PBCS) covers core financial planning: multi-dimensional budgeting, rolling forecasts, variance analysis, and financial reporting. Oracle Enterprise Planning and Budgeting Cloud (EPBCS) extends PBCS with pre-built frameworks for workforce planning, capital expenditure planning, project planning, and financials — reducing the custom configuration required for these common planning use cases. For organisations currently running custom workforce or capital planning models in Hyperion Planning, EPBCS is worth evaluating as the migration destination, because the pre-built frameworks may replace a significant portion of the custom rule development required in a PBCS implementation. For organisations with straightforward financial planning requirements, PBCS is the appropriate scope.
Q: Can we migrate from Hyperion Planning to Cloud EPM without rebuilding everything? Some elements migrate with limited rework — dimension metadata and historical data are the primary examples. The majority of implementation-specific work — business rules, data entry forms, financial reports, data integration mappings, and planning unit hierarchy — needs to be rebuilt rather than migrated. The good news is that rebuilding in the migration context is typically faster than the original build, because the requirements are understood, the design decisions can be made with the benefit of years of operating the Hyperion environment, and the Cloud EPM architecture resolves several problems that required complex workarounds in Hyperion. A well-managed migration typically delivers a better planning environment than the Hyperion environment it replaces — not just the same environment on a different platform.
Q: How does the Hyperion to Cloud EPM migration interact with IFRS 18? IFRS 18 is effective for annual periods beginning on or after 1 January 2027, which means most GCC and Egyptian organisations will need to produce their first IFRS 18 compliant consolidated accounts in early 2028. A Cloud EPM migration that goes live in 2026 should include IFRS 18 category design in the build phase — mapping the account dimension to the five mandatory income statement categories, designing the management performance measure disclosure framework within the reporting layer, and building the comparative period restatement capability into the consolidation model. Organisations that defer IFRS 18 to post-migration will need to return to the Cloud EPM environment for structural changes before their first IFRS 18 close.
Q: How much does a Hyperion to Cloud EPM migration cost in Saudi Arabia or the UAE? Professional services for a Hyperion to Cloud EPM migration in the GCC range from approximately USD 80,000 for a focused single-country, single-module migration to USD 480,000 or more for a complex multi-country migration covering Planning and FCCS, with Arabic-language configuration, ZATCA integration, and multiple ERP source systems. Oracle’s annual Cloud EPM subscription is additional and ranges from approximately USD 40,000 to USD 250,000 depending on module scope and user count. The most reliable cost estimate comes from a detailed migration assessment — a scoping exercise that inventories the existing Hyperion environment, maps the migration requirements, and produces a costed plan before any implementation work begins.
About Loop Wise Solutions
Loop Wise Solutions is an enterprise performance consultancy based in Cairo, serving medium and large enterprises across Egypt, Saudi Arabia, the UAE, Qatar, and the broader Arab world. We deliver Hyperion to Oracle Cloud EPM migrations for organisations in the region — with direct experience in Arabic-language EPM configuration, ZATCA Tax Reporting integration, GCC multi-entity consolidation, and the complex business rule landscapes that regional Hyperion environments have accumulated over years of operation.
Every migration engagement we take on is led by senior Oracle EPM practitioners throughout — the people who design the migration are the people who build the Cloud EPM environment. We work with a defined number of clients at any given time, which is how we maintain the depth that a migration of this complexity requires.
If you are planning a Hyperion to Cloud EPM migration or trying to understand what it will realistically involve for your specific environment, we are happy to have a direct conversation — starting with an honest assessment of your Hyperion environment before any project scope is committed.
Contact: Contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
