← Back to Epm Services
EPM SERVICES · Remain, Optimise or Migrate?

Make the EPM decision your business needs—not the one a vendor needs.

An evidence-led comparison of remaining, optimising or migrating, including risk, business fit, skills, cost and change impact.

Discuss this requirement →
SPECIALIST SERVICE

Start with the environment, risk and required outcome.

An evidence-led comparison of remaining, optimising or migrating, including risk, business fit, skills, cost and change impact. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.

RELATED CAPABILITIES

Connected expertise for the wider environment.

Remain

Best when the platform remains fit, supportable and economically sensible. Focus: resilience and governance.

Optimise

Best when core fit is strong but performance, process or maintainability is weak. Focus: measurable improvement.

Migrate

Best when constraints are structural and future requirements justify the disruption. Focus: controlled business change.

DELIVERY APPROACH

Clear steps. Visible decisions.

Discover the operating context
Baseline the environment
Deliver controlled improvements
Validate and hand over
THE DECISION

Three options, not two

Software evaluations usually start after someone has already decided that change is needed. The shortlist forms, the demos get booked, and the option of improving what already exists never enters the comparison because it does not have a vendor to present it.

That is a structural gap rather than anybody’s fault. Nobody sells “leave it alone”. There is no sales team for the status quo, no demo environment, no reference site and no commission.

So the honest framing has three options.

Remain. Keep the current platform and change nothing structural. Correct where it is genuinely the right answer, which is more often than the market suggests.

Optimise. Keep the platform and fix what is actually causing the pain. Usually cheaper than migration by an order of magnitude, and it produces a much clearer view of whether the platform is the problem.

Migrate. Move to a different application. Correct when the constraint is genuinely architectural rather than operational.

The reason to consider all three is not loyalty to old software. It is that migrating a badly-run environment produces a badly-run environment on a newer platform, plus a licence, plus an implementation cost, plus eighteen months of organisational disruption.

ORACLE’S OWN POSITION

What Oracle actually says about staying

The urgency in most migration conversations does not come from Oracle. It is worth reading Oracle’s own position before accepting anyone’s timeline, including ours.

Oracle Hyperion is one of five product families covered by Oracle Applications Unlimited, alongside E-Business Suite, JD Edwards EnterpriseOne, PeopleSoft and Siebel. Oracle’s published commitment for that programme reads:

“Get Oracle Premier Support for your Applications Unlimited products through at least 2037.”

And on the question of being moved to the cloud:

“Our commitment includes support for both on-premises and in Oracle Cloud Infrastructure. Remain on-premises or move to the cloud with the same applications and your customizations. Your choice, your schedule.”

“No forced migrations. No surprises. Receive ongoing new features and a transparent roadmap.”

That is the vendor, on its own website, saying there is no deadline and no compulsion. Under Continuous Innovation, new functionality arrives through patch sets rather than through major upgrades, which is why Oracle describes major upgrades as eliminated for these products.

Two qualifications, because we would rather you heard them from us.

The 2037 commitment carries an exclusion for named individual products that Oracle has not extended beyond their existing dates, so confirm your specific products and release against Oracle’s Lifetime Support Policy rather than assuming the headline covers everything you run. And a release that has already passed Premier Support, such as Hyperion 11.1.2.4, is a different situation entirely. Applications Unlimited protects the product family, not every release of it.

Sources: Oracle Applications Unlimited · Applications Unlimited letter (PDF) · Oracle Lifetime Support Policy: Applications (PDF)

THE REAL CHOICE

What you are actually choosing between

Oracle Hyperion (on-premises) HFM for consolidation, running on your infrastructure. Premier Support through at least 2037 under Oracle Applications Unlimited. Highest customisation ceiling of the three. You own the infrastructure, the patching and the recovery position.

Oracle EPM Cloud (FCCS) Oracle’s SaaS consolidation application. No infrastructure to own, quarterly updates applied by Oracle, a materially lower customisation ceiling and a subscription cost that continues indefinitely. Update cadence is not optional.

OneStream, CCH Tagetik and others Unified platforms covering consolidation and planning in one application. Strong where the current estate is fragmented across several tools. Full reimplementation, so the cost and disruption profile resembles a migration rather than an upgrade.

HOW TO SEPARATE THEM

The criteria that actually separate them

Criterion Question to answer Where it usually points
Functional fit Does the current platform do what finance needs, or only what it was configured for years ago? Configuration gaps favour optimise. Genuine functional gaps favour migrate.
Customisation ceiling How much of your logic is bespoke rules that a SaaS product cannot reproduce? Heavy customisation favours remain or optimise.
Integration cost How many source systems feed the consolidation, and what would rebuilding and revalidating them cost? High integration counts favour remain. This is the cost most often underestimated.
Control and audit What would your auditors need to re-test after a platform change? Heavily controlled environments favour a staged approach.
Internal skills Can you sustain the platform, and is the skill available in your market? Thin internal skill favours a supported arrangement, on either platform.
Total cost over horizon Compare over the planning period, not year one. Include implementation, parallel run, retraining and support. Longer horizons often favour remain. Shorter ones favour subscription.
Update cadence Can you absorb quarterly mandatory updates and the regression testing they require? Low tolerance for imposed change favours on-premises.
Exit cost What does it cost to leave whatever you choose? Rarely modelled. Should be.
WHEN TO REMAIN

Remain is the right answer when

  • The consolidation completes reliably and the pain is elsewhere, usually in data quality upstream or in reporting downstream
  • Customisation is heavy and reproduces business logic that a SaaS product would not accommodate
  • The integration estate is large and stable, and rebuilding it would cost more than the platform change saves
  • The organisation faces a merger, a restructure or an ERP programme in the same window, and adding a consolidation migration would create unmanageable concurrent risk
  • The environment is on 11.2 and under Premier Support, and the driver for change is a renewal conversation rather than a business requirement
WHEN TO OPTIMISE

Optimise is the right answer when

  • The close is slow but completes, and nobody has established why it is slow
  • The environment has not been assessed in several years
  • Support depends on one person
  • Manual steps have accumulated around the system rather than inside it
  • A migration business case is being built on the current environment’s performance, which means the baseline is wrong

Optimise is also the right answer when you genuinely intend to migrate. Understanding the current environment properly before moving it is the difference between a migration and a re-implementation.

WHEN TO MIGRATE

Migrate is the right answer when

  • The platform genuinely cannot meet a current requirement, and configuration has been ruled out rather than assumed
  • The organisation has made a strategic decision to exit self-managed infrastructure entirely, and consolidation is part of that programme
  • The estate is fragmented across several tools and a unified platform would remove real duplication
  • The release is out of Premier Support and upgrading in place is not viable
  • The skill required to run the platform is not available and cannot be bought

We will tell you when this applies. A partner that never recommends migration is as unreliable as one that always does.

OUR POSITION

Evidence before recommendation

  1. Establish the baseline. What the current environment actually does, how long it takes, where it fails and what it costs to run. Measured, not estimated.
  2. Separate operational from architectural. Distinguish problems caused by how the platform is run from problems caused by what the platform is. This is the step that usually gets skipped, and it is the one that determines the answer.
  3. Model all three options. Cost, effort, risk and disruption over your planning horizon, including the option to change nothing.
  4. Test the assumptions. Particularly integration rebuild cost, parallel run duration and control revalidation, which are the three items most consistently underestimated.
  5. Recommend, with the reasoning visible. You receive the working, not just the conclusion. If you disagree with an assumption you can see exactly which one and what it changes.

The output is a decision document your finance leadership and your auditors can both read.

Discuss your Remain, Optimise or Migrate decision with a senior specialist.

Start a conversation →
QUESTIONS ANSWERED

Questions answered

Does Namandla only recommend staying on Hyperion?

No. The purpose is to make the decision evidence-led. Migration may be appropriate where business and technical constraints justify it.

Can this compare Oracle EPM Cloud and OneStream?

The assessment can frame requirements and trade-offs across plausible target platforms. Detailed product selection scope is agreed separately.

Who should attend the decision workshop?

Typically the CFO or finance sponsor, Finance Systems owner, IT representative and key process owners.

Can Oracle EPM Cloud integrate with ERP systems?

Yes, where the application is properly designed, integrated, governed and supported. Suitability should be confirmed through the organisation’s requirements, environment, risks, users, data and expected operational value.

Can Oracle EPM Cloud integrate with Oracle EPM applications?

Yes, where the application is properly designed, integrated, governed and supported. Suitability should be confirmed through the organisation’s requirements, environment, risks, users, data and expected operational value.

How does Oracle EPM Cloud improve business decision-making?

Oracle EPM Cloud supports this outcome by replacing fragmented manual work with controlled workflows, shared data, validation, automation and traceable reporting. The design must reflect the organisation’s process, controls, users and integration landscape.

Is Oracle Hyperion still supported?

Yes. Oracle provides Premier Support for Hyperion EPM 11.2 through at least 2037 under Oracle Applications Unlimited, and it has extended that date more than once. There is no forced migration and no announced end-of-life event for 11.2.

Release 11.1.2.4 is different. It has passed Premier Support, so error correction is no longer provided. Organisations on that release do face a genuine decision, but the lowest-cost answer is frequently an in-place upgrade to 11.2 rather than a cloud migration.

What is Oracle Applications Unlimited and does Hyperion qualify?

Applications Unlimited is Oracle’s commitment to continue supporting and enhancing its on-premises application families. Oracle Hyperion is one of the five covered families, alongside E-Business Suite, JD Edwards EnterpriseOne, PeopleSoft and Siebel. Oracle commits to Premier Support for these products through at least 2037.

The programme also carries Oracle’s position on migration, in Oracle’s own words: “No forced migrations. No surprises.” And on deployment: “Remain on-premises or move to the cloud with the same applications and your customizations. Your choice, your schedule.”

One qualification worth knowing. The commitment excludes specified individual products that Oracle has not extended beyond their existing dates, so check your particular products and release against the Lifetime Support Policy rather than assuming the headline date covers everything you run.

Is Hyperion end of life?

No. Hyperion 11.2 is a current, supported release under Continuous Innovation, which means Oracle delivers fixes and new functionality through patch sets rather than through major version upgrades. The “end of life” framing usually refers to 11.1.2.4, which has passed Premier Support.

The phrase gets used loosely in sales conversations because urgency helps close deals. It is worth asking anyone who uses it which release they mean and what date they are citing.

What is the best financial consolidation software?

There is no single answer, and any vendor giving you one is describing their product rather than your requirement. The right consolidation platform depends on customisation depth, integration count, control requirements, internal skills and how long a horizon you are planning over.

A useful test: ask each vendor under what conditions their product would be the wrong choice. A credible answer exists for every product on the market. An inability to produce one tells you what kind of conversation you are in.

How much does migrating from HFM to FCCS cost?

Licence is rarely the significant number. The costs that determine the total are integration rebuild, parallel run, control revalidation, retraining and the internal finance time consumed across the programme. On a mid-sized environment these routinely exceed the software cost several times over.

The specific item most often missing from business cases is the parallel run. Running two consolidations for two or three cycles while proving the numbers agree consumes substantial finance capacity at exactly the time of month when that capacity is scarcest.

Will we save money by moving to the cloud?

Sometimes, and over a shorter horizon than most business cases assume. Removing infrastructure, patching and upgrade effort is a real saving. It is offset by a subscription that continues indefinitely, mandatory quarterly regression testing and the cost of reproducing customisation that no longer fits.

Model it over your actual planning horizon rather than three years. On-premises costs are front-loaded and subscription costs are level, so the crossover point matters enormously and it moves depending on the horizon you choose.

Should we migrate before Premier Support ends?

Support end dates are a valid input, not a deadline to organise a programme around. Premier Support for 11.2 currently runs through at least 2037, and Oracle has extended it repeatedly. Planning a migration for 2027 against a 2037 date means paying early for a benefit you do not yet need.

Where the date genuinely matters is capacity planning. If a migration would take eighteen months and you want it complete well before support ends, the decision point is earlier than the date suggests. That is a scheduling argument rather than an urgency argument.

Can we optimise now and migrate later?

Yes, and it is frequently the strongest sequence. Optimisation reduces immediate pain at a fraction of migration cost, and it produces documented understanding of the environment that makes any later migration substantially cheaper and lower risk.

The objection is that optimisation spend is wasted if you migrate anyway. In practice it usually is not, because the largest part of the work is understanding and documenting metadata, rules and integrations. That understanding transfers directly into a migration and is otherwise rebuilt at consulting rates during the programme.

How do we know if our problem is the platform or how we run it?

Measure before concluding. A slow close caused by metadata that has never been retired, audit tables that have never been purged, or a load that starts late is an operational problem. It will follow you to a new platform.

An architectural problem looks different: a requirement the platform genuinely cannot meet, a scale ceiling you have actually reached, or a version you cannot upgrade. In our assessments, operational causes outnumber architectural ones considerably. That is not an argument for never migrating, it is an argument for finding out first.

Are you independent, or do you have a product to sell?

We do not resell Oracle licences and we are not compensated on migration outcomes. Our work is weighted toward supporting and improving existing environments, so recommending that you leave a working environment alone costs us nothing.

That does not make us automatically right. It means our incentive does not point in one direction before we have looked. Ask the same question of everyone advising you, and ask specifically how they are paid.

What happens if we do nothing?

If you are on 11.2, running reliably and meeting requirements, nothing happens. It remains supported and it keeps working. Doing nothing is a legitimate outcome of an evaluation and it should be on the comparison sheet.

If you are on 11.1.2.4, or the close is failing, or the environment depends entirely on one person, doing nothing carries real and growing risk. The distinction is worth establishing before treating inaction as either safe or reckless.

What is third-party Oracle support and should we consider it?

Third-party support means taking your Hyperion maintenance from a specialist provider rather than from Oracle, typically at lower cost. It suits stable environments on a supported release where you value responsiveness and predictable cost over access to Oracle’s patch stream.

The trade-off is real and worth stating plainly. You give up Oracle error correction, new patch sets and the ability to raise a Service Request. For a stable 11.2 environment that is rarely patched anyway, that may cost you little. For an environment mid-upgrade, or one that regularly needs Oracle-supplied fixes, it costs you a great deal.

We support Hyperion environments on either basis and we do not have a licensing position that favours one. What we would push back on is treating third-party support as purely a cost decision. Establish what you actually consume from Oracle support first, then price the alternative against that rather than against the invoice.

How do we start?

With an assessment that establishes your baseline and models all three options against your criteria. It typically takes a few weeks and it produces a decision document rather than a proposal.