Author: Abhishek Singh, Certified Master Anaplanner & Engineering Manager at ABINBEV.
Application Lifecycle Management (ALM) is one of the most valuable governance features available in Anaplan. It allows model builders to make, test and validate structural changes in a Development model before deploying them to Production, reducing the risk of impacting business users who rely on the model every day.
Many organizations still have legacy models that were built before ALM became a standard implementation practice. Over the years, these models often grow in size and complexity with multiple developers making changes directly in the live model. While this approach may work initially, it becomes increasingly difficult to manage as the model evolves and business dependency on it increases.
Some of the common challenges seen in such models include:
- No clear separation between development and production activities
- Limited visibility into structural changes made over time
- Increased risk of accidental impact to end users
- Reduced governance and auditability
- Difficulty supporting multiple developers working on enhancements simultaneously
For these reasons, enabling ALM is often one of the most important steps in establishing a sustainable development and release process.
The approach below can be used when introducing ALM into an existing Standard Mode model that has been actively used by business users for several years.
1. Create a backup before making any changes
Before starting any ALM preparation activities, create a backup copy of the live business model.
This provides a recovery point should anything unexpected happen during cleanup activities, Production List configuration or ALM enablement. Although the process is generally straightforward, having a backup available provides additional confidence throughout the transition.
2. Perform model cleanup
Before creating separate Development and Production environments, it is a good opportunity to address any technical debt that has accumulated over time.
Typical cleanup activities may include:
- Removing unused imports and import data sources
- Renaming imports and actions using a consistent naming convention
- Deleting redundant modules, lists, line items and saved views
- Removing unused actions and processes
- Reviewing model size and identifying optimization opportunities
- In the clean-up process, provide notes to objects for better audit trail in future
Carrying unnecessary artifacts into both Development and Production models only increases complexity later. Performing cleanup upfront helps establish a cleaner foundation for ALM.
3. Review and eliminate unnecessary SELECT statements
One area that deserves special attention before enabling ALM is the use of hardcoded references in formulas.
Review formulas that use SELECT statements and identify whether they reference list members that may eventually become Production Data.
Where possible:
- Replace hardcoded member references with mapping modules and LOOKUPs
- Remove SELECT references tied to lists that will become Production Lists
- Retain SELECT references only where they are supported and appropriate, such as:
- Top Level items
- Versions
- Native Time functions and references
- YTD, YTG, Current Period and similar Time-based references
This step is particularly important because Production Lists cannot be structurally referenced through hardcoded member selections.
Note: One practical lesson learned from many implementations is that replacing a SELECT with a LOOKUP should not be treated as a simple formula change. In some cases, a direct replacement may not produce the same result. It is always worth validating outputs carefully and following a structured testing approach before making changes in bulk.
4. Identify and configure Production Lists
The next step is to review all lists and determine which ones should be managed directly by business users in Production.
Production Lists allow data maintenance without requiring structural model changes or ALM synchronizations.
When identifying Production Lists, carefully evaluate any downstream dependencies, integrations, formulas, actions and hierarchies that rely on those lists before converting them to Production Data.
A little extra analysis at this stage can help avoid rework later.
Note: If any list was unintentionally left as a standard list during the initial ALM setup, it can still be converted to a Production List later. The change can be made in the Development model and then synchronized to Production through ALM. Existing list data will be retained and once the synchronization is complete, new list members can be added and maintained directly in the Production model without requiring further structural changes.
5. Review import actions and processes
This is one of the most commonly overlooked areas when enabling ALM.
Review every import action and process to identify hardcoded mappings that may create issues after lists are converted to Production Data.
Pay particular attention to:
- Fixed list member mappings
- Hardcoded parent assignments
- Source-to-target mappings that assume specific list members will always exist
Once a list becomes Production Data, import actions should not rely on hardcoded members that may change over time.
Where required:
- Replace hardcoded mappings with mapping modules
- Use code-based matching
- Implement dynamic lookup logic
- Ensure imports remain scalable as new Production List members are introduced
The objective is to make integrations and imports as flexible as possible so they continue working without requiring structural updates.
6. Validate existing integrations
Before moving further, it is important to document the current integration landscape.
This should include:
- Inbound integrations
- Outbound integrations
- CloudWorks schedules
- API-based integrations
- Middleware jobs
- ETL processes
- Current Workspace IDs
- Current Model IDs
Having this information readily available is extremely useful during validation, troubleshooting and post-deployment support.
7. Create the initial revision tag
Once cleanup activities and Production List identification have been completed, create a Revision Tag on the existing Standard Mode model.
This Revision Tag becomes the baseline from which ALM will be established.
Think of it as the starting point for your Development and Production relationship.
8. Create the Development model
Using the baseline Revision Tag, create a new model from the revision.
This new model will become the Development environment where all future structural enhancements, fixes and testing activities will take place.
At this stage:
- Development Model = Standard Mode
- Live Business Model = Candidate Production Model
Future development activities should be directed toward the Development model rather than the live business model.
9. Temporarily pause integrations
Before converting the live model into Production Mode, it is advisable to temporarily pause scheduled integrations and automated processes.
As a precaution:
- Pause or retire scheduled integrations
- Pause CloudWorks schedules if applicable
- Ensure no structural changes are being made during the transition
Just as important as the technical activity is communication. Make sure the relevant support teams, integration owners and business stakeholders are informed beforehand so there are no surprises during the transition window.
10. Convert the live model to deployed mode
After all prerequisites have been completed, enable Deployed Mode on the existing live business model.
This model now becomes the Production environment.
In Deployed Mode:
- Structural changes are restricted
- Business users continue maintaining Production Data
- Enhancements are deployed through ALM synchronization from Development
At this point, the organization officially moves to an ALM-driven operating model.
11. Validate ALM synchronization
Before opening the environment for active development, perform a simple end-to-end synchronization test.
A typical approach would be:
- Make a small structural change in the Development model.
- Create a new Revision Tag.
- Synchronize the change to Production.
- Confirm the synchronization completes successfully.
A successful deployment provides confidence that both models are ALM compatible and correctly configured.
12. Perform end-to-end validation
After the first successful synchronization, perform a broader validation exercise.
Areas that should be reviewed include:
- UX pages and dashboards
- Imports and exports
- Integration processes
- Production Data maintenance
- Security roles
- Selective Access
- Workflow functionality, where applicable
- Model-to-model imports
Although technical validation is important, business validation is equally critical.
It is a good idea to involve model administrators, process owners or key business users and ask them to perform high-level testing. The objective is to confirm that nothing has changed from an end-user perspective and that day-to-day processes continue to work as expected.
Business sign-off should be obtained before considering the ALM setup complete.
13. Re-enable and validate integrations
Once validation activities are complete:
- Re-enable integration schedules
- Resume CloudWorks jobs
- Validate inbound and outbound data movement
- Monitor the first few execution cycles closely
In most situations, integrations continue to work without modification because the original live model remains the Production model. As a result, the Workspace ID and Model ID remain unchanged.
This is one of the biggest advantages of converting the existing live model into Production rather than replacing it with a copied model.
Important consideration when using a copy model as production
In some situations, organizations may choose to designate a copied model as the new Production environment.
While this approach is possible, it introduces additional effort because the copied model receives a different Model ID.
As a result:
- Integration scripts may require updates
- CloudWorks connections must be reconfigured
- Middleware configurations may need modification
- Model-to-model imports must be remapped
- Upstream and downstream integrations require validation
- API-based integrations need to be updated with the new model reference
For this reason, many organizations prefer converting the existing live business model into Production and creating a separate Development model from the baseline revision whenever possible.
Key success factors
Successfully enabling ALM is not just a technical exercise. It requires coordination between multiple teams, including:
- Business stakeholders
- Anaplan development teams
- Integration teams
- Platform administrators
The technical steps themselves are usually straightforward. The real success comes from planning the transition properly, validating impacts early and ensuring all stakeholders are aligned throughout the process.
Once implemented, ALM provides a strong foundation for controlled releases, improved governance, reduced production risk and a more scalable long-term operating model.
Closing thoughts
While the steps above provide a structured approach to enabling ALM on an existing live model, there is rarely a one-size-fits-all solution. Factors such as model complexity, workspace constraints, integration landscape and business operating procedures can all influence the implementation strategy.
If there are additional considerations, lessons learned or best practices that you've encountered during your own ALM implementations, please share them in the comments.
