Best Of

How to Properly Execute an Annual Rollover in Anaplan

An annual rollover in Anaplan doesn’t have to be a stressful, high-risk process. When approached with structure, foresight, and automation in mind, it becomes a predictable and controlled operation. The key is not just what you do during the rollover, but how well you’ve prepared throughout the year.

Below is a practical framework, based on real-world best practices that I have developed over the past 13 years in Anaplan, and it really helps ensure your rollover runs smoothly every time.

1. Maintain a Living Rollover Checklist

One of the most effective ways to de-risk your annual rollover is to maintain a centralized, sequential checklist, ideally within each model or in a dedicated administrator model.

This checklist should include:

• Time settings updates (model calendar changes)
• Time range adjustments
• Version updates
• Required actions and processes
• Pre- and post-rollover validation reports

The most important part: keep it updated continuously.

As models evolve, small enhancements often introduce new dependencies - especially ones that impact time, versions, or data structures. These changes are easy to overlook during rollover preparation and can cause unexpected failures or data inconsistencies.

A well-maintained checklist ensures:

• Nothing gets missed
• New dependencies are documented as they’re introduced
• The rollover process becomes repeatable and scalable

2. Automate the Rollover Process (Especially Data Cleanup)

Automation is where you move from a reactive to a proactive rollover strategy.

Whenever you design data flows into your model, think in three dimensions:

1. How do I load this data?
2. How do I structure it?
3. When (or if) should I delete it?

That third question is often overlooked, but it’s critical.

Smart Data Retention Strategy

Not all data should be treated equally:

• Metadata → typically retained indefinitely
• Transactional data (e.g., FP&A actuals) → often only needed for active planning horizons.

For example, you likely don’t need to store detailed income statement transactions for years that no longer exist in your model calendar.

Implementing Delete Logic

To handle this cleanly:

• Add a boolean flag in your SYS modules that identifies records with no associated time period
• Use this flag to drive delete actions

You can then:

• Run deletes individually (for initial validation), or
• Bundle them into a single automated process once confidence is established

Make It Visible

Surface this logic in a dashboard (or UX page) that includes:

• Your rollover checklist
• A preview of records flagged for deletion
• Controls to execute cleanup actions

This transparency builds trust and allows stakeholders to validate what will happen before the rollover is executed.

3. Perform Critical Sanity Checks

Even well-designed models can behave unexpectedly when time shifts. A few targeted checks can prevent major issues.

Watch for PREVIOUS() Dependencies

Formulas using PREVIOUS() can produce incorrect results when the input source periods no longer exist.

Recommended approach:

• Create an import action that overrides the first period of the new model calendar
• Populate it with values from the last period being removed

This ensures continuity in calculations and avoids gaps in logic.

4. Always Backup Before You Begin

Before initiating any rollover steps:

• Copy or archive the model

Best practice:

• Keep a copy within the same workspace for easy comparison

This allows you to:

• Run side-by-side validations
• Compare pre- and post-rollover outputs
• Quickly recover if something goes wrong

Think of this as your safety net—it’s simple, but absolutely essential.

5. Validate Before and After the Rollover

A proper rollover isn’t complete without validation.

Pre-Rollover

• Confirm current data integrity
• Snapshot key reports
• Validate totals and balances

Post-Rollover

• Re-run the same reports
• Compare results against pre-rollover snapshots
• Confirm:
  • Time settings updated correctly
  • Data cleanup behaved as expected
  • Calculations remain accurate

Final Thoughts

Annual rollovers in Anaplan shouldn’t feel risky or unpredictable. The complexity often comes from lack of documentation, missing automation, and overlooked dependencies - not the rollover itself.

If you:

• Maintain a living checklist
• Build intentional data deletion logic
• Automate repeatable steps
• Perform targeted sanity checks
• Always backup and validate

…then your rollover becomes a routine operation rather than a fire drill.

Invest the time upfront, and future you (and your stakeholders) will thank you.

Author: Chris Allen is a Certified Master Anaplanner and Manager at Allitix part of Accenture.

Hi Anaplan Community!

This ‘How I Built It’ video shares a dynamic feature to toggle between different planning methodologies corresponding to different lines on the P&L for driver-based planning.
It's a feature that can be applied to many different scenarios where a list item has unique line items related to it than its peers in the same list — to only show the related line items per the list item selected. The upside is decluttering a dashboard and allowing a good fit on one screen without much searching or scrolling.

Check it out and leave a comment with questions!

……………

Check out my other ‘How I Built It’ videos:

• How I Built It: Replacing list items
  
• How I Built It: Flagging new list items

Author: Tyler Beck is a Certified Master Anaplanner at TBLB LLC, and is currently a Team Lead at CVS Health.

Use case

An end user needs to export a template from Anaplan using Months as the time period in columns, and qualitative data in rows. When the template is exported as a CSV file the years in the dates turn to days instead of years in the Excel file. The import will result in error when mapping back to native time in Anaplan due to the date change.

Use case example

The module below is exported from Anaplan as a CSV file:

The CSV file is opened and the dates show the years as days, and the years are recognized as the current year DATE() in Excel as a default setting:

The dates in the CSV file will show a format of MM-DD-YYYY instead of the Anaplan format of MMM-YY. This is a major issue for clients who need to export a template to lookup the most recent data when manually inputting data is not feasible due to large data sets. When the CSV file is loaded back into Anaplan, the module will import the data into the wrong months or result in an error all together:

The import shows the error for “Invalid date or timescale identifier” because the expected native time years are shown as days in the CVS file.

Solution

Create a “Dynamic Time” production list in Anaplan apply it to the columns in a new export module as a template. Then import the template back into the input module’s native time using the custom fixed position pattern in the import configuration.

Solution example

1. Create “Dynamic Time” as a production list so the dates can be changed in the Production environment: The list should include a special character in front of the MMM-YY month format that Anaplan uses for native time. The list in this example will use an apostrophe as the special character, and two years are applied to the list. More than two years can be applied to the list, and subsets can be made for forecast and plan months as well.
2. Apply Dynamic Time list to module and export the template for users to update values: The export template should have all mapping qualitative data fields in rows and Dynamic Time in columns, and include empty rows so end users can create lookups for the data: Also, remember to include the labels and update the “Name” to “Code” for the dimension in the rows: Using codes will not only make using lookups easier in Excel, but is also more efficient for loading back into Anaplan by mapping codes to the dimensions. Placing a special character in front of the native time period format will prevent the CSV file from defaulting to Excel’s MM-DD-YYYY format and now can be mapped to Anaplan’s native time.
3. Create an import for the template using a custom fixed position pattern: Map the codes to the correct dimensions, time as column headers, and the amount as a fixed line item.
   Next, select the Time tab in the import configuration and select Periods for the timescale, then navigate to the custom fixed position pattern section and enter ?MMM-YY. Placing a “?” in front of the MMM-YY format will tell Anaplan to ignore the special character so the format will map back to native time.
4. Run Import with new configuration to import the template into native time: The import is now successful, importing all fields with no errors. All values have been mapped to the correct dimensions in the correct native time period.

Conclusion

Creating an export template using a production flat list can allow end users to export a template to populate data to import back into Anaplan by placing a special character in front of the month names. This will allow end users to bulk upload large data sets when manually inputting the values is time consuming and tedious. Remember to always export the template to include all rows and to show labels, as well as changing the “Name” in the label to “Code” so numbered lists can be mapped seamlessly.