Most Anaplan teams get away without a real release process for about a year. Then a formula change made in production during close breaks a report, a "quick fix" is lost when the next deployment overwrites it, and someone asks how a number changed. Anaplan's Application Lifecycle Management (ALM) exists to prevent all of that, but ALM only works if you use it as a process, not as a button.
This tutorial covers the model roles, what structural and production data actually mean, revision tags, sync, deployed mode, and a release process you can run every two weeks without drama.
The mental model: structure travels, data does not
ALM splits everything in a model into two categories:
- Structural information — lists (their existence and properties), modules, line items, formulas, actions, views, dashboards and UX pages, roles, versions, time settings. This is what ALM promotes between models.
- Production data — the contents of lists you designate as production lists, plus the data in modules dimensioned by them, plus user access assignments. This stays in the target model and is never overwritten by a sync.
The single most consequential design decision in ALM is which lists you mark as production lists. Cost centers, products, employees, customers, projects — anything the business adds to during normal operation — should be production lists. Lists that are part of the model's logic, such as a list of P&L line categories or scenario types the builder controls, should not be.
Get this wrong in the permissive direction and every deployment wipes real business data. Get it wrong in the restrictive direction and your builders cannot change a list that genuinely is structural. Decide it early, write it down, and review it at every release.
A list can only be marked as a production list if its properties carry no formulas and nothing about it needs to change structurally between releases. If Anaplan refuses the setting, that is a design signal, not an obstacle to work around.
Model roles: development, test, production
The minimum viable ALM landscape is two models; the sane one is three.
| Model | Mode | Who works here | Data |
|---|---|---|---|
| DEV | Standard | Model builders only | Small, representative sample |
| TEST | Deployed | Testers, a few power users | Production-like copy, refreshed periodically |
| PROD | Deployed | Planners, end users | Real |
DEV is the source model. Every structural change starts here — no exceptions, and that rule is the whole point. TEST and PROD are target models in deployed mode, which mechanically prevents anyone, including workspace administrators, from changing structure in them. Deployed mode is not a bureaucratic nicety; it is what makes the claim "DEV is the source of truth" actually true.
Keep DEV small. Builders do not need three years of actuals to write a formula, and a small DEV model opens and syncs fast.
Revision tags: your version history
A revision tag is a named snapshot of a source model's structure. You create them in DEV, and they are what a target model syncs to.
To create one, open DEV, go to the model's Application Lifecycle Management settings, choose Manage Revision Tags, and add a tag with a name and description.
Naming matters more than people expect, because six months later the description is your only audit trail. A convention that works:
R2026.04.1 - Add Workforce module, DCA on Inputs (PLAN-812, PLAN-819)
R2026.04.2 - Hotfix: revenue rollup mapping (PLAN-833)
R2026.05.1 - Q2 release: Polaris rebuild of demand model (PLAN-840..851)
Year, period, sequence, one-line summary, ticket references. Tag at the point a build is ready for TEST, not at random intervals, and never tag a model mid-change: a revision tag captures whatever state the model is in, including half-finished work.
The sync
Syncing compares the target's current revision to the chosen source revision and applies the structural difference.
- Open the target model (TEST or PROD).
- Go to its Application Lifecycle Management settings and choose Synchronize.
- Choose the source model and the revision tag you want.
- Review the comparison report.
- Run the sync.
Two things to know before you click.
Read the comparison report properly. It lists every structural change that will be applied. Scan for anything you did not expect, especially list deletions, dimension changes on existing modules, and changes to actions. An unexpected item almost always means someone made a change in DEV that was not part of this release.
Sync forward only, and in order. A target moves through revisions in the order they were created in the source. You cannot cherry-pick revision 7 while skipping 5 and 6, and you cannot roll a target back to an earlier revision. Plan releases as a straight line.
If a sync fails, Anaplan tells you why. The common causes are a production list that needs a structural change, a formula referencing something that does not exist in the target, or a target that has drifted because someone took it out of deployed mode. Fix the cause in DEV, tag again, re-sync.
What ALM will not carry for you
- Data. Modules dimensioned by production lists keep the target's data. Do not treat sync as a data migration path; that is what imports and integrations are for.
- Users and access assignments. The user list and who has which role live in the target. Role definitions themselves are structural and do travel.
- Integration wiring. CloudWorks integrations, Data Orchestrator pipelines, and external schedulers point at specific model IDs. New model, new wiring. Keep a documented inventory of every integration and the model it targets — see our integration tooling comparison.
- Anything outside the model. Workspace settings, SSO configuration, and tenant-level security are administered separately; our security hardening checklist covers those.
A release process you can actually run
A two-week cadence that has survived contact with real close calendars:
Continuously, in DEV. Builders work against tickets. Every change traces to a ticket. No structural work happens anywhere else.
Day 8 — cut. Freeze DEV, review the diff against the last tag, create the revision tag with a descriptive name.
Day 8 — sync TEST. Read the comparison report, sync, then run a smoke test: open the main UX pages, run each action, check three known numbers.
Days 9 to 11 — test. Power users test the ticket list. Bugs go back to DEV, get fixed, and get a new revision tag. Never apply a fix directly in TEST.
Day 12 — go/no-go. Sign-off from the process owner. Confirm no data load is running and that you are not inside the close window.
Day 13 — sync PROD. Take a backup copy of PROD, sync to the approved revision tag, re-run the smoke test, and post a short release note telling planners what changed.
Day 14 — refresh DEV if needed. If DEV's sample data has drifted from reality, refresh it. Never the reverse.
Roll back by rolling forward: fix in DEV, tag, sync. That is why the smoke test and the pre-sync backup matter — they are your safety net, not the revision history.
Practices that separate calm teams from anxious ones
- Never leave PROD out of deployed mode. If you take it out for an emergency, put it back the same day and reconcile the change into DEV immediately, or you will discover the drift at the worst possible moment.
- One builder owns the tag. Three people creating revision tags on the same day is how releases get confusing.
- Keep a release log outside Anaplan. Tag name, date, tickets, who approved, what broke. Ten minutes per release, worth hours later.
- Test with production-like volumes. A change that is fast against 500 rows in DEV can be slow against five million in PROD. Performance testing belongs in TEST, not in the incident review.
- Treat UX pages as structure. They travel with ALM, which also means an unfinished page in DEV goes to PROD if it is inside the tag. Cut clean.
- Document the production list decision. One page, reviewed each quarter, listing every list, whether it is production, and why.
- Keep the model tidy. ALM is easier to reason about when the model has a clear structure; see the DISCO blueprint.
Starting ALM on a model that never had it
If you have a single production model that builders edit live, you are not stuck. The path:
- Take a copy of PROD; that copy becomes DEV. Reduce its data to a workable sample.
- Decide and set production lists in DEV, carefully, with a written rationale.
- Create the initial revision tag in DEV.
- Put PROD into deployed mode and connect it as a target at that same revision, so the two models start aligned with no structural difference.
- Add TEST when you can. Two models are enough to start; three are what you want by the second quarter.
The hardest part is not technical. It is the day builders stop editing production. Expect pushback, and expect it to fade within one release cycle once people see that changes can go live safely on a schedule.
Where we help
We set up ALM landscapes, define production list strategy, and run the first few releases alongside your team so the process sticks after we leave — part of our Anaplan Support and Maintenance and Platform Migrations and Modernization work. If your model is currently edited live in production, that is a common starting point, not an embarrassment. Get in touch and we will scope the transition.