HFM to FCCS Migration: How Much Is Actually a Rebuild?

Richard Philipson
General Manager — Technology Operations

Every Hyperion Financial Management owner weighing a move to Oracle Cloud EPM eventually asks the same question, usually with a bit of dread: how much of our rules code has to be rewritten? HFM applications accumulate VBScript over years — opening balances, roll-forwards, cash flow, eliminations, overrides, the lot — and a rule file that runs to several thousand lines looks, on paper, like a multi-month redevelopment job.

That line count is what stalls the business case. It is also, almost always, the wrong number to be frightened of.

Here is the uncomfortable truth from the field: on most HFM applications, somewhere around nine-tenths of that rules code is not a rebuild at all. It is either behaviour the cloud now does for you, or configuration you click rather than code. The trick is telling those two apart from the part that genuinely needs a developer — before you put a number in front of a board.

What the HFM Analysis Program actually measures

Oracle runs a free service called the HFM Analysis Program. You send your HFM application files — the metadata plus the rule files — and a few weeks later Oracle’s EPM product management team returns a report on how the application maps to Financial Consolidation and Close (FCCS). The centrepiece of that report is a categorised breakdown of every rule routine: how many lines each one contains, and which of four buckets it falls into.

Those four buckets are the whole story. Once a routine is in the right one, you know what it costs you.

• Standard capability — the routine maps to seeded FCCS behaviour. Opening balance carry-forward, net income to the balance sheet, the cumulative translation adjustment, the foreign currency translation reserve. No rebuild at all; the cloud does it out of the box.
• Configuration, no coding — handled through the seeded Movement dimension, currency setup and configurable consolidation rules. Roll forward, copy data, translation, eliminations, override adjustments. Point-and-click, not script.
• Traditional rules writing — genuine member-formula or Groovy work with no seeded equivalent. Forecast scenario logic, bespoke ratios, allocations.
• Purpose-built business process — logic that leaves rule code entirely and moves into Task Manager, Supplemental Data, journals or validations.

What the categorisation looks like on a real application

On a consolidation application we worked through — a little over 4,000 lines of HFM rules across more than twenty routines — the split came out at roughly 27% standard capability, 63% configuration, and 10% traditional rules writing. Ninety per cent of the rule code was either seeded behaviour or configuration. The hand-written rules rebuild was a tenth of what the raw line count implied.

The table below is the part of the picture that matters: the same rule routine names you would recognise in any HFM application, mapped to where they land in the cloud.

Why so little survives as code

Two things changed between HFM and FCCS, and both shift work out of rules.

The first is that FCCS ships with a defined consolidation process. Opening balance carry-forward, proportionalisation, standard eliminations, ownership change, movement calculation, balancing the balance sheet — these run as built-in steps you review and configure, not as VBScript you author and maintain. The same close an HFM consultant once wrote by hand is, in the cloud, mostly switched on.

The second is dimensionality. FCCS introduces seeded Data Source and Movement dimensions. A typical HFM application carrying four custom dimensions often needs only two in the cloud, because the cloud’s defaults absorb the rest. A default Movement dimension shrinks the chart of accounts and removes the roll-forward logic that propped it up. Indirect cash flow comes built in, so the cash flow rules and the accounts behind them disappear. Disclosures, ageing and questionnaires move to Supplemental Data. The pattern every migration eventually confirms: less rules, more configuration.

That is also why the line count is a poor proxy for effort. A 919-line opening-balance routine and a 90-line forecast routine are not the same kind of work — the first vanishes into seeded behaviour, the second is real redevelopment. Counting lines without categorising them is how scoping conversations end up frightened of the wrong thing.

A first pass you can run in your browser

So we built one. Paste or upload your HFM rule file and the analyser below does, for the rules portion, what the Analysis Program does: it splits the file into routines, counts the lines of logic in each, and buckets every routine against the same four-tier FCCS model — then shows you the no-code share up front. Nothing is uploaded. The parsing runs entirely in your browser, so rule files never leave the machine. (No HFM file to hand? Hit Load sample to see the output on a representative application.)

It is a heuristic. It classifies on routine names rather than a full parse of what each line does, so it will not match Oracle’s report rule for rule. We tested it against the worked example above: it reproduced 19 of Oracle’s 22 category calls and put the no-code share at 87% against Oracle’s 90% — close enough to size a rebuild and frame a conversation, not a replacement for the formal assessment when you need the number that goes in front of a board.

What it deliberately does not tell you is the rest of the migration. The dimensionality mapping, the data, and the business-process redesign that turns validations into Supplemental Data and manual close steps into Task Manager — that is where the real design work lives, and it is exactly where a line count stops being useful.

What to do with the number

If the first pass says 85 to 90% of your rules are seeded or configuration — and on most HFM applications it will — then the rules rebuild was never the risk worth pricing the project around. The work that determines timeline and cost is the design, not the VBScript.

That is a far more productive conversation than “how many months to rewrite our VBScript.” Run your rules through the analyser, get the shape of it, and then scope the part that actually matters.