Migrating a Hyperblock Model to Polaris: A Step-by-Step Anaplan Tutorial

Choosing Polaris for a brand-new model is a design decision. Moving a model that already exists — one that real planners log into every Monday, that feeds the board pack, and that has nine years of formula archaeology in it — is a migration project. The two get conflated constantly, usually in a sentence that starts "we'll just switch the engine."

You cannot switch the engine. Polaris and Hyperblock are different calculation engines with different storage behaviour, different sparsity handling, and a feature surface that does not overlap perfectly. A Polaris model is built as a Polaris model. What you migrate is the design, the data, and the users — in that order, with a parallel-run period in the middle where both models produce the same numbers and you can prove it.

This tutorial is the step-by-step version of that project. It assumes you already decided Polaris is the right destination (if you have not, read our engine-selection guide first) and that you have a working Hyperblock model in production you are not allowed to break.

Step 0: Confirm the migration is actually worth doing

Polaris earns its keep on sparse, high-dimensional problems: SKU × customer × location × day, policy-level actuarial detail, transaction-grain profitability. It stores only populated cells and calculates only what it needs, so the combinatorial blow-up that forces Hyperblock builders into tortured workarounds — concatenated composite lists, numbered lists with mapping modules, nightly data-reduction imports — simply does not arise the same way.

It does not earn its keep on a dense, modest model that already runs in four seconds. Migrating that model buys you a rebuild, a regression cycle, and a retrained user base in exchange for nothing.

Write down the trigger before you start. A defensible one looks like:

• A dimensional combination you genuinely need that Hyperblock cannot hold at acceptable size.
• An existing workaround (composite codes, split models, a reduced grain) that is actively costing the business analytical fidelity.
• A size ceiling you are within sight of and cannot architect your way out of.

An indefensible one: "Polaris is newer." Put the trigger in the project charter. It becomes your scope control when someone asks for a redesign halfway through.

Step 1: Inventory the source model honestly

Before you design anything, produce a written inventory of the Hyperblock model. Do not do this from memory. Export the model's structural information and walk it.

Capture, as a table you can hand to a reviewer:

Artefact	What to record	Why it matters
Lists	Name, type (flat / hierarchy / numbered), item count, subsets, properties	Numbered lists and composite keys are the usual symptom of the problem you are migrating away from
Modules	Dimensionality, line item count, cell count, applies-to	Cell counts tell you which modules exist only to shrink other modules
Line items	Formula, format, summary method, time scale, versions flag	Formula inventory is your compatibility checklist
Actions	Imports, exports, processes, their source files and mappings	Integration rewrite scope
UX pages	Pages, cards, source modules, action buttons	The user-visible contract you must honour
ALM state	Production lists, revision tag history, deployed-mode status	Determines how you cut over

Two columns to add by hand, because no export gives them to you: "is this a workaround?" and "does anyone use this?" A surprising fraction of a long-lived Hyperblock model consists of structures that exist only to manage Hyperblock's density — staging modules that pre-aggregate so a downstream module can be smaller, numbered lists built from concatenated keys, "flat fact" modules that fake a sparse store. Those should not be migrated. They should be deleted, and the thing they were working around should be built natively.

The second column is politically harder and more valuable. Use model usage analytics and an honest conversation with the process owners. Every module you retire is one you do not have to regression-test.

Step 2: Build the compatibility checklist

This is the step teams skip and then discover in week six. Polaris does not support every Hyperblock construct, and some that it does support behave differently. The list changes with each release, so verify current behaviour against Anaplan's documentation for your target release rather than trusting a blog — including this one.

As of the current release line, the things that most often bite:

• Functions. A set of functions behaves differently or is unsupported on Polaris. Time-intelligence and text-manipulation functions, and some of the more exotic lookup patterns, are where differences cluster. Run your exported formula inventory against the supported-function list mechanically — a spreadsheet COUNTIF over the function names in your formula column will find most of it in an afternoon.
• Summary methods. Polaris handles aggregation differently, and formula-level summary behaviour that you relied on implicitly in Hyperblock deserves an explicit check on any line item whose summary is not None or Sum.
• Versions. Native versions behave differently than many builders expect on Polaris. Most modern designs are better off with a versions list anyway; if you are already on native versions, treat it as a design question during the rebuild rather than something to port blindly.
• Line item subsets. Verify support and behaviour for your target release before you design around them.
• Actions and integration. Import/export actions, CloudWorks connections, Data Orchestrator pipelines and REST API calls generally carry over conceptually, but every mapping needs retesting because your lists are changing shape.
• Selective access and DCA. The security model needs to be re-specified against the new dimensionality, not copy-pasted.

Produce a single sheet: every construct in your model, its Polaris status (supported / different / unsupported), and for the last two categories a named redesign. If that sheet has more than a handful of unsupported rows touching core calculation logic, your migration is a rebuild with a data-lift component. Price it accordingly.

Step 3: Redesign for sparsity instead of porting

The single biggest mistake in a Polaris migration is a faithful port. A faithful port carries all your Hyperblock compensations into an engine that does not need them, and you end up with a slower, stranger model than the one you started with.

Re-derive the design from the business problem:

1. Re-expand collapsed dimensions. Every composite list (PRODUCT_LOCATION, CUST_SKU_WK) goes back to being the two or three real dimensions it always was. This is the whole point. Your formulas get shorter, your lookups get direct, and your data loads stop needing a key-building step.
2. Delete the density-management layer. Staging modules whose only job was pre-aggregation, "reduced grain" copies of a fact module, scheduled imports that trim history — all candidates for removal. Keep them only if a business process depends on the intermediate output.
3. Rethink the calculation path, not just the structure. Polaris calculates on populated cells. A formula written to avoid touching a large dense block may be doing unnecessary work now. Conversely, patterns that create population where there was none — broadcasting a constant across a wide module, say — are more expensive in relative terms than they were. Keep sparse things sparse.
4. Decide the grain explicitly. Polaris makes finer grain affordable, which means someone will ask for daily, SKU-level, customer-level everything. Affordable is not free. Write down the grain each module needs and why, and make somebody sign it.
5. Keep DISCO. The data / system / calculation / output module discipline is engine-independent and still the best structural defence you have. Polaris does not excuse a spaghetti build.

Document the mapping both ways: source module → target module, and target module → source modules. You will need the reverse direction during reconciliation when a number is off and you have to find which of three old modules used to produce it.

Step 4: Stand up the target model and load reference data

Build the new model in a workspace with headroom. Order of operations:

1. Lists and hierarchies first, in dependency order, loaded from the same upstream source the Hyperblock model uses — not exported from the Hyperblock model itself. If you export from the old model you inherit its data quality problems and you never prove the new integration path works.
2. System modules: properties, mappings, time settings, filters.
3. Calculation modules in dependency order, with formulas written fresh against the new dimensionality.
4. Output and reporting modules.
5. Actions, then UX pages, then roles and selective access.

Load reference data before transaction data, and reconcile list item counts at every level against the source system before you load a single number. Hierarchy drift between the two models is the most common cause of a parallel-run variance that takes three days to find, and it is entirely preventable with a ten-minute count check.

Step 5: Build the reconciliation harness before you load history

Do not load history and then eyeball totals. Build the comparison first.

Create a dedicated reconciliation module in the target model dimensioned by the key output dimensions and a line item subset of the measures that matter — the ones that appear in the board pack, feed downstream models, or drive a payment. For each measure, three line items: Legacy Value, New Value, Variance, plus a Within Tolerance? boolean with an explicit threshold.

Feed Legacy Value by export from the Hyperblock model on a scheduled action so the comparison refreshes without anyone remembering to do it. Feed New Value natively.

Then define your tolerance honestly. Exact-to-the-cent is the right standard for anything that drives a payment or a filing. Floating-point-scale differences on a long chain of allocations are expected and acceptable; a 0.3% variance in a revenue total is not a rounding artefact, it is a bug you have not found yet. Write the tolerance per measure, in the module, where a reviewer can see it.

This is the same discipline as a regression harness before UAT, and for the same reason: a variance you can see on a page is a variance someone will fix, and a variance buried in a spreadsheet comparison nobody re-runs is a variance that ships.

Step 6: Parallel run

Run both models in production for at least one full planning cycle, and preferably two. A cycle means a complete loop: data load, planner input, review, approval, reporting, close. Monthly processes need a month. Quarterly forecast processes need a quarter, and if someone tells you that is too long, ask what the cost is of discovering the variance after cutover.

During parallel run:

• Load both models from the same upstream source on the same schedule. Never hand-sync.
• Keep the reconciliation module green and investigate every amber the day it appears. A tolerated variance compounds.
• Have real planners enter real inputs into the new model, not just a tester clicking through. Input behaviour, page responsiveness, and the feel of a large grid are things only a daily user will complain accurately about.
• Log every variance, its root cause, and its fix. The log is your acceptance evidence and, later, the answer when someone asks in month four why a number changed.
• Freeze scope. Enhancement requests during parallel run go to a backlog, not into the model. Every change invalidates the reconciliation you have already done.

Expect the first week to be ugly. Most early variances come from three places: hierarchy mismatches, time-range differences, and summary-method differences on line items where Hyperblock's implicit behaviour was doing something you never noticed.

Step 7: Cut over and decommission

Cutover is a checklist, not an event:

• Freeze the legacy model to read-only. Do not delete it.
• Final data load into the target, with the reconciliation module re-run and signed off.
• Repoint integrations — CloudWorks connections, Data Orchestrator pipelines, API clients, downstream model imports, Excel add-in and reporting connections. Every one of these is a separate owner and a separate test.
• Switch users by role, with the legacy model's UX pages retired on the same day so nobody keeps a bookmark alive.
• Establish ALM on the new model: deployed mode, production lists, a revision-tag release process. Do this at cutover, not later; a model that runs for six months without ALM discipline becomes one you cannot safely change.
• Hypercare for one cycle with a named owner and a daily variance check.
• Decommission the legacy model only after a full post-cutover cycle closes clean. Archive a copy of it and its reconciliation log for audit before you release the workspace.

What this typically costs

Honest ranges, assuming a competent builder and a model of moderate complexity — say 40 to 80 modules with a real integration footprint:

• Inventory and compatibility assessment: one to two weeks.
• Redesign and target build: the bulk of the work; comparable to a greenfield build of the same scope, minus requirements-gathering, plus the cost of matching legacy behaviour you disagree with.
• Reconciliation harness: a few days, and the highest-return days in the project.
• Parallel run: one to two planning cycles of calendar time, low effort per day but non-zero every day.
• Cutover and hypercare: two to four weeks.

The line item people forget is change management. The planners did not ask for this migration, will not see a feature they wanted, and will notice every pixel that moved. Budget for training, a side-by-side walkthrough of the new pages, and a named person who answers questions for the first cycle.

The short version

Decide on evidence, not novelty. Inventory before you design. Check compatibility mechanically against your target release. Redesign for sparsity rather than porting workarounds. Build the reconciliation harness before you load history. Parallel-run a full cycle with frozen scope. Cut over on a checklist and keep the old model until the first clean close.

Done that way, a Polaris migration is a disciplined, boring project with a predictable end date. Done as "switch the engine," it is a rebuild discovered in instalments.

If you are scoping one and want a second opinion on whether the trigger justifies the project — or you need builders who have done the parallel-run part before — get in touch. We will tell you if the answer is "stay on Hyperblock."