Move the applications that should move, in the order that makes sense.

Fit assessment first, and it is deliberately the cheapest part. Whether EPM Cloud suits your environment, which applications, in what sequence, and at what realistic cost — including the conclusion that some of your estate should stay where it is.

From there: migration delivery, greenfield implementation, ongoing support including quarterly update regression testing, and hybrid operation where on-premises and cloud run together. Delivered remotely by default, subject to agreed access, security, scope and support hours. You deal directly with the person doing the work.

Oracle EPM Cloud is Oracle’s SaaS suite for enterprise performance management, covering planning, financial consolidation, account reconciliation, master data management, profitability modelling, tax reporting and narrative reporting. Applications are licensed separately and deployed independently.

It is the successor generation to on-premises Hyperion, though both remain supported. Hyperion EPM 11.2 carries Premier Support through at least 2037 under Oracle Applications Unlimited, so this is a choice between two current options rather than a move off something obsolete.

Hyperion is on-premises, you own the infrastructure, customisation is effectively unlimited and you control when to patch. EPM Cloud is SaaS, Oracle operates it, customisation is configuration within a framework, and updates arrive on Oracle’s schedule regardless of yours.

The functional overlap is substantial. The differences that determine outcomes are customisation depth, integration rebuild cost, control revalidation effort and whether your organisation can absorb an imposed update cadence.

Depends on the application and the starting point. A single Planning application with clean integrations is a matter of months. A consolidation migration from a mature HFM environment, with historical data, parallel run and control revalidation, is considerably longer.

The variable that most often extends these programmes is not the build. It is the assessment of what the existing application genuinely does, and the parallel run that proves the new one matches.

Oracle applies updates on a fixed monthly and quarterly cadence. They land in your test environment first, with a defined window to regression test against your configuration before production. The updates themselves cannot be declined or deferred indefinitely.

Plan for this as permanent operational work rather than an occasional event. Organisations that budget the testing capacity manage it comfortably. Organisations that treat each update as a surprise find it competing with close for the same people.

Oracle operates the infrastructure and provides the platform security controls. Responsibility for access, roles, provisioning and what data is loaded remains yours. Under POPIA you remain the responsible party for any personal information regardless of where the system runs.

The questions worth asking Oracle before signing are data residency, backup and recovery commitments, the process for retrieving your data if you leave, and how access by their support staff is controlled and logged. These are answerable and the answers should be in the contract rather than in a presentation.

Yes, and most organisations do for a period. Smart View connects to both simultaneously and data can move between them. A phased adoption where Planning moves first and consolidation follows later is a common and sensible pattern.

Budget for the hybrid period being longer than planned. Keeping metadata aligned across two environments is ongoing work, and the reconciliation between them does not maintain itself.

Over a short horizon frequently yes, over a long one often not. Removing infrastructure, patching and upgrade effort is a genuine saving. It is offset by a subscription that never ends, permanent regression testing capacity and the one-off cost of rebuilding integrations and revalidating controls.

Model it over your actual planning period rather than a default three years. On-premises costs are front-loaded and subscription costs are level, so where the crossover falls determines the answer and it moves with the horizon.

Configuration is extensive: dimensions, forms, rules through Calculation Manager, business logic through Groovy in some applications, and integration through Data Management. What is not available is unrestricted custom code operating on the platform itself.

For most requirements this is sufficient. The difficulty arises where an on-premises application encodes years of bespoke logic. Separating logic that is genuine business requirement from logic that is accumulated workaround is the decisive step, and it is the step most often skipped.

Assess it rather than assume it. The strongest cases are a strategic exit from self-managed infrastructure, a genuine need for capability the on-premises stack does not have, or a release that has passed Premier Support with no viable upgrade path.

The weakest case is a support date years away being presented as urgent. See Remain, Optimise or Migrate.

With a fit assessment covering which applications suit you, in what sequence, at what realistic cost including integration rebuild and control revalidation, compared against optimising what you already run.

Call 087 188 3388 or email info@namandla.com.

Yes, for a Cloud EPM tenancy on a qualifying release. Oracle lists South Africa Central (Johannesburg) in the OC1 realm, and OC1 is one of the five realms — with OC4, OC19, OC29 and OC42 — in which Oracle publishes generative AI as available.

The remaining condition is release level: from July 2026 the functionality requires Cloud EPM 26.04 or later. So for a Johannesburg tenancy the region is not the obstacle. The release level might be, and that is within your control.