Anaplan to Pigment migration: a practical checklist

Moving planning from Anaplan to Pigment is a chance to clean up years of workarounds. It is also a risk: a straight copy carries the workarounds across, and a rushed rebuild loses logic nobody wrote down. This checklist is the sequence I use to keep every number traceable.

1. Inventory before you design

List every module, list and line item, plus the saved views and dashboards people actually use. Tag each one: keep, redesign or retire. Helper modules that only existed to work around a limit usually go. Ask owners which outputs leadership relies on; those become your reconciliation targets.

2. Map concepts, not cells

• Lists become dimensions. Hierarchies become dimension properties, and duplicate lists created as workarounds are merged.
• Modules and line items become metrics. One Anaplan module often splits into several metrics, each with only the dimensions it needs. That is a large part of the speed gain.
• Line item formulas become metric formulas, using modifiers such as BY, REMOVE and FILTER to move between dimensionalities.
• Saved views and dashboards become views and boards, rebuilt around what each role needs rather than copied screen for screen.

3. Redesign the parts Pigment does better

Versions, scenarios and access rights are worth designing fresh. A Version dimension with a switchover month per version, and clear flags for actual and plan months, replaces many time-range and filter workarounds. Access rules should be defined by dimension, such as department and version lock, not by duplicated modules.

4. Build reconciliation in from day one

For every key output, create a check that compares the Pigment total with the Anaplan total by version, entity and month. The target is zero. Keep a register of every difference until it is explained or fixed.

5. Run both models for one full cycle

Do not cut over on a promise. Run Anaplan and Pigment side by side for at least one planning cycle, with the same inputs, and compare outputs. This is where missed logic surfaces, while you still have the old model to check against.

6. Plan the cutover like a release

• Agree a freeze window for changes in the old model.
• Rehearse the data loads.
• Train admins and planners on the new boards before go-live, not after.
• Snapshot the final Anaplan state for audit.

7. Document the trail

Record the Anaplan origin of each Pigment block. When someone asks a year later why a number changed, the answer should take minutes, not a project.

The migration blueprint shows how these steps fit together in a fictional manufacturing example.