Oracle HFM: What the VBScript-to-BSL Switch Means for Your Consolidation Rules

Richard Philipson
General Manager — Technology Operations

If you run Oracle Hyperion Financial Management for your group consolidation, there’s a change coming that your finance and IT teams need to plan for. Oracle is replacing VBScript — the scripting language that has powered HFM business rules for over two decades — with a new native engine called Business Script Language, or BSL.

This isn’t a rumour or a roadmap slide. BSL shipped in HFM Platform Independent Release 11.2.21 in April 2025, and there are hard dates attached to the VBScript phase-out.

Why is this happening?

The short answer: Microsoft is deprecating VBScript across Windows. It’s being moved to a “Feature on Demand” component now, will be disabled by default around 2027, and eventually removed from Windows altogether.

Oracle can’t build the future of HFM on a scripting engine that the operating system vendor is pulling out from underneath it. So they’ve built their own — BSL — and embedded it directly into the HFM platform. No external dependency on Microsoft’s scripting host.

It’s worth noting what this tells us about Oracle’s commitment to HFM on-premise. They’ve extended Premier Support through at least 2036 and invested in building an entirely new scripting engine. If your organisation has been wondering whether Oracle would quietly let Hyperion die, this is a fairly clear signal in the other direction.

What’s the timeline?

Two dates matter, with a third already in the rear-view mirror:

Those dates could shift slightly depending on Microsoft’s own deprecation schedule, but the direction is locked in.

How different is BSL from VBScript?

Less different than you might expect. Oracle has deliberately designed BSL to use the same syntax as VBScript. The control flow structures are the same (If…Then…Else, For…Next, Do…Loop, Select Case). The data types, string functions, date functions, and math operations all carry across. BSL supports CreateObject for common objects like ADODB.Connection, FileSystemObject, RegExp, and Dictionary.

If you’ve written HFM rules in VBScript — calculation rules, translation rules, consolidation rules, dynamic member lists — the logic and structure of your code won’t need a wholesale rewrite. Most of it will port with minimal changes.

That said, “minimal” is not “zero.” BSL operates within a defined scope, and there are edge cases where VBScript code that relied on behaviours outside that scope will need adjustment. Oracle’s own documentation recommends that if something falls outside the BSL scope, you log it as a bug and they’ll provide guidance — whether that’s a future implementation, a workaround, or an alternative approach.

The area most likely to trip people up is array handling. Functions that return arrays — List, AttributeList, and similar — may behave differently at the boundaries. Oracle’s release notes specifically call out that you should avoid hardcoding array bounds and instead use LBound() and UBound() to reference array indices. If your rules have hardcoded bounds, those will need to be updated.

Concretely, this is the pattern that breaks:

' VBScript — old pattern with hardcoded bounds.
' Works on VBScript today, fragile on BSL.
Dim entityList
entityList = HS.Entity.List("EntityHierarchy", "[Base]")

For i = 0 To 50
    Dim entity
    entity = entityList(i)
    ' ... do something with entity
Next

And this is the corrected version:

' BSL-safe — bounds resolved from the array itself.
Dim entityList
entityList = HS.Entity.List("EntityHierarchy", "[Base]")

For i = LBound(entityList) To UBound(entityList)
    Dim entity
    entity = entityList(i)
    ' ... do something with entity
Next

The corrected version also runs cleanly on VBScript, so you can apply the change in your existing environment before the cutover — no need to wait for the BSL switch to fix it.

What should you do now?

Oracle provides a straightforward migration procedure, and the earlier you start, the less pressure you’ll be under when October 2026 arrives. A practical approach in four steps:

1Inventory every VBScript file

Take an inventory of every VBScript file in your HFM application — calculation rules, translation rules, consolidation rules, member lists, any custom logic. Know what you have and what it does. Plenty of HFM environments carry rules that were written years ago by people who have since moved on. Now is the time to document them.

If you want a quick first-pass risk assessment as you go, paste any rule file into the free BSL checker further down this page — it’ll flag the most common patterns that need adjustment.

2Set up a test environment

Duplicate your application, set the engine type to BSL (ScriptEngineType=0), and open the application. If it loads cleanly, you’re in good shape. If it throws errors on load, those errors will tell you which rules need adjustment.

3Validate consolidation output

Don’t stop at a clean load. Run your actual consolidation processes — consolidation, on-demand calculations, dynamic member lists — and validate the output. Compare the results against your VBScript environment. The goal is to confirm that the numbers are identical, not just that the application opens without errors.

4Roll out to remaining environments

Once you’ve resolved any issues in test, apply the updated rules to your other environments. Don’t leave this until the last quarter before the October 2026 deadline.

A few things worth keeping in mind

This transition is also a good opportunity to clean house. Many HFM applications accumulate rules over the years — workarounds that were never removed, calculation logic that duplicates what’s handled elsewhere, member lists that reference entities that no longer exist. If you’re going to touch every rule file anyway, take the time to simplify where you can.

If your team doesn’t have deep HFM scripting experience in-house — and that’s increasingly common as the platform matures — this is worth getting external help with. A rules migration where the testing isn’t thorough enough can produce consolidation differences that only surface during a reporting period, which is exactly when you don’t want to be debugging.

The bottom line

The VBScript-to-BSL transition isn’t optional, and the timeline is tighter than it might appear. If your HFM environment has significant custom rules — and most do — start the inventory and testing process now. The migration path is well-defined and the syntax is deliberately familiar, but it still requires careful validation to make sure your consolidation output stays clean.

Try the checker on your own code

Paste any HFM VBScript rule into the tool below to get a report on patterns that may need adjustment for the BSL transition. The scanner is heuristic-only and runs entirely in your browser — your code never leaves your machine.