BOTTOM LINE UPFRONT
Oracle is changing the rules engine inside HFM on a fixed timeline, with full cutover by October 2027. Finance teams that wait risk compressed timelines and undetected changes to consolidation outputs — the kind that don’t trigger errors, they just produce different numbers. The time to assess exposure is now, not eighteen months from now.
Oracle Hyperion Financial Management (HFM) is moving away from VBScript. For finance teams that rely on HFM for consolidation, this is a rules migration with real reporting risk. It shouldn’t be treated as a routine technical patch.
Oracle introduced Business Script Language, or BSL, in April 2025 as the new scripting engine for HFM business rules. VBScript support will be phased out over the next two years. Organizations need to start assessing their rules now.
The 5 things they need to know:
1. VBScript is going away because Microsoft is retiring it
HFM rules have relied on VBScript for more than 20 years. In August 2024, Microsoft formally deprecated VBScript and announced it will be removed from future Windows releases entirely. Oracle cannot keep HFM dependent on a language the operating system will no longer support, so it built BSL directly into HFM rather than waiting for the floor to drop out.
Oracle has also extended Premier Support for HFM through at least 2036. HFM is not going away, but the rules engine underneath it is changing.
2. The key dates are closer than they feel
In October 2026, HFM 11.2.27 makes the Native Script Engine the default and VBScript moves to critical fixes only. In October 2027, HFM 11.2.31 removes VBScript support entirely, with no option to revert.
How we got here: BSL shipped with HFM 11.2.21 in April 2025, the Native Script Engine became available in 11.2.22, and as of 11.2.23 each HFM application can run on either engine. That dual-engine window is where organizations should be doing their testing now, before October 2026 forces the decision.
3. Most rules should translate, but “most” is not “all”
Oracle designed BSL to feel familiar, and calculation rules and consolidation logic largely carry forward. The risk is in the exceptions.
Oracle says BSL supports most built-in VBScript functions, not all. Array handling is one documented area to review, particularly rules that hardcode array bounds rather than using LBound() and UBound(). A rule written as Dim arr(10) with a fixed upper bound may behave differently under BSL than one written to dynamically detect its own size. Any rule that depends on unusual or undocumented VBScript behavior should be treated as high-risk until tested.
One practical reality to factor in: Oracle does not provide an automated converter. This migration is a manual review process, with Oracle’s BSL documentation as the primary guide. You should scope the effort accordingly.
4. The real risk is not whether rules load. It is whether numbers change.
A rule file can load successfully in BSL and still produce different consolidation results. This is why the migration should not be treated as an IT syntax cleanup.
Finance teams need to validate outputs directly through side-by-side consolidation runs under both engines. Rules that drive intercompany eliminations, currency translation, or multi-step allocation sequences deserve dedicated test scenarios, since those are the areas where numeric differences are most likely to appear without triggering a load error.
This is especially true for organizations with years of accumulated custom rules, limited documentation, or rules written by people who are no longer around to explain them.
5. Start with an impact assessment, not a last-minute conversion
The migration path is straightforward in concept: duplicate the HFM application, switch the copy to BSL, fix load errors, run full consolidation testing, and compare outputs against the current VBScript environment.
In practice, duplicating a large HFM application is not a casual step. It involves metadata, security classes, journals, and data loads, and that process frequently surfaces undocumented dependencies that no one knew existed. Build that discovery time into your plan rather than treating it as a rounding error.
The migration review is also a natural moment to clean house in your HFM environment. Most HFM instances contain member lists that grew for years without pruning, logic that was copied rather than maintained, and legacy workarounds that solved a problem a decade ago and have been running quietly ever since. The review will surface them regardless – and it’s a great time to optimize for the future.
What we are seeing
We’ve seen consistent patterns emerge in our work with finance teams: Rules written by consultants who left the engagement years ago, with no internal documentation. Consolidation logic that “just works” and hasn’t been reviewed since it was built. Member lists that expanded incrementally until no one can confidently say what half of them do.
That complexity is normal. It is also why migration scope tends to be underestimated. The full picture only becomes clear when someone actually reads the rules.
The right starting point is an impact assessment: understand which HFM applications are in scope, audit what is actually in the rules, test under the Native Script Engine, and validate outputs against the scenarios that matter most to your close process. October 2026 is eighteen months out. There is time to do this properly, but not to start late.