Author: Laiza Tagumpay is a Certified Master Anaplanner with a background in Customer Success and Solution Architecture, now happily building and scaling Anaplan as a CoE Principal Engineer in a biotech company.
Migrating from Classic to Polaris is not a lift-and-shift exercise. It requires a mindset shift in how models are designed, built, tested, and governed.
This article outlines a phase-based Polaris migration strategy to help guide organizations through their Polaris migration journey.
Phase 1: Pre-migration strategy
Goal: Confirm Polaris suitability and prepare the team before any build begins.
- Assess Polaris suitability - Validate the model against Classic → Polaris migration criteria:
- Large modules with >~70% Sparsity
- Modules approaching Classic cell count limit
- Concatenated lists for dimensional workarounds
- Performance degradation in large modules
- Need access to new or AI-powered features
- Request a MAPS report from Anaplan CSBP — To identify other areas that are memory-heavy and high-effort calculations.
- Ensure team readiness
- All team members understand what to expect in a Polaris migration.
- Developers (MBs and SAs) complete all required Polaris training and read key articles.
- Capture baseline metrics and performance
- Model open time, import/export duration, populated cell count, model size.
- Align dependencies early
- Coordinate with Data Hub and other teams that integrate with or depend on the model.
Outcome: Clear go/no-go decision, informed team, and known risk areas.
Phase 2: Design strategy
Goal: Redesign the model for Polaris — not as a Classic replica.
- Redesign don’t lift and shift: Re-evaluate structure through a Polaris lens.
- Apply Polaris best practices early; avoid deferring foundational design decisions.
- Limit scope: Defer major functional enhancements until post-migration.
- Design with natural dimensionality: Avoid transaction lists, concatenated lists, and flat staging modules.
- Use SYS helper modules
- Valid Combination modules driven by import boolean flags.
- Calculation Master Switch module to control expensive logic during data loads/testing.
- Schedule design reviews for critical components.
Outcome: A Polaris-ready design that preserves sparsity and performance.
Phase 3: Build strategy
Goal: Build iteratively with continuous performance visibility.
- Build in small, testable increments to reduce rework.
- Keep DEV lean: Use small list sizes in DEV, but ensure all lists and subsets are represented (even with just one or a few members).
- Continuously monitor Polaris Blueprint Insights in DEV environment: Export Line Items within 10 minutes of model open.
- Populated cell count
- Calculation effort
- Calculation complexity
- Refactor early: Address rising effort/complexity immediately.
- Maintain modeling hygiene: Remove unused lists, modules, line items, and actions to avoid unnecessary allocation of calculation effort.
- Connect to ALM early: Sync Dev → Test early.
- Create a revision tag per story and sync daily.
Outcome: Stable build with controlled performance characteristics.
Phase 4: Testing strategy
Goal: Validate real-world performance, behavior, and integrations.
- Continuously monitor Polaris Blueprint Insights in TEST environment too while gradually loading data to full list members and datasets.
- Re-export line items and refactor as needed.
- Validate end-to-end early.
Outcome: Confidence that the model performs at scale.
Phase 5: Deployment or release strategy
Goal: Transition safely without business disruption.
- Keep Classic active until Polaris is validated, approved, and stable.
- Create revision tags for each deployed function.
- Save model copies per sprint as part of release management.
Outcome: Controlled cutover with minimal risk.
Phase 6: Post-deployment strategy
Goal: Stabilize, optimize, and continuously improve.
- Monitor performance, integration health, and adoption.
- Track recalculation trends and usage patterns.
- Perform incremental refinements based on real usage.
- Introduce deferred enhancements gradually.
Outcome: A scalable, sustainable Polaris solution.
Closing takeaway
Successful Polaris migrations are less about perfect upfront design and more about making phase-appropriate decisions, monitoring performance continuously, and working closely with the Center of Excellence, Data Hub, and dependent team.
Questions or comments?
