Almadar A company in KAFD migrating a decade of Hyperion rules built up by people who've since left the business needs those rules audited, not lifted and shifted blind.
Hyperion Planning, HFM and Essbase have served Riyadh groups well for years, but Oracle's investment has moved decisively to EPM Cloud, and support horizons for on-premise versions are finite. The migration decision is usually forced by that timeline rather than chosen freely, which makes doing it deliberately rather than hurriedly the main thing within your control.
Auditing what you actually have
The first phase is an inventory: which applications are live, which business rules still execute, which reports are genuinely used versus generated and ignored, and which calculations depend on member structures that no longer reflect the business. In most Riyadh groups we find twenty to forty percent of the Hyperion estate is effectively dead weight, forms nobody opens, rules superseded years ago, and migrating it would carry cost and complexity forward for no reason.
Rebuild versus replicate
Straight replication is tempting because it feels lower risk, but it imports every historical workaround into a platform that does not need them. EPM Cloud handles multi-currency, ownership changes and intercompany elimination natively in ways Hyperion often required custom rules to achieve. We assess each significant rule and decide, with you, whether it is a genuine business requirement worth rebuilding or an artifact of the old platform that should be retired.
Data and history
How much history to migrate is a real decision with cost attached. Most Riyadh groups move three to five years of actuals plus the current budget and forecast cycles, and archive the rest in an accessible format rather than carrying it into the new application. Reconciliation is run at every level, entity, account and period, so the first close on EPM ties exactly to the last close on Hyperion.
A common Saudi scenario
A Riyadh holding company runs HFM for consolidation across eleven entities, with a set of Essbase calculations written by a consultant who left in 2016. Nobody currently on the finance team can explain two of the elimination rules. The migration audit traces both to an ownership structure that changed in 2019, meaning the rules have been producing a small, consistent error ever since. Rebuilding rather than replicating fixes a problem the group did not know it had.
Parallel running and cutover
The new EPM application runs alongside Hyperion for at least one full close and one budget cycle, with variances investigated and explained rather than accepted. Cutover happens only when both produce the same numbers and the finance team is confident operating the new platform without the old one as a safety net. This connects directly to consolidation process design, since a migration is also an opportunity to fix a close calendar that was never efficient.
Rethinking the close calendar while you migrate
A migration is the one moment when a finance team will accept changes to a close process they have run the same way for years. We use it deliberately: reviewing which reconciliations still earn their place, which approval steps add control versus delay, and whether the close can compress once manual consolidation disappears. This connects to broader process improvement and to reporting design, because moving an inefficient process onto a better platform preserves the inefficiency at higher licence cost.
Riyadh-based groups with listed subsidiaries typically migrate consolidation first to protect CMA reporting deadlines.