What to know when moving models across workspaces: A practical checklist

AnaplanOEG

You may be considering moving a model into a new Workspace for several reasons. On the surface, a cross-workspace move looks like a simple copy, but the result is a new model with a new model ID. It loses its ALM revision history, and you need to review anything that pointed to the original: integrations, ADO, app pages, users, etc. This article covers what changes, what needs updating, and how to sequence the move so Production isn’t disrupted.

How the move works

Within the same tenant, a workspace admin can import a copy of a model into the target workspace through the model import option, selecting the source workspace and model. You need workspace admin rights in both workspaces. If you are copying between different tenants, you can’t do this yourself; contact Anaplan Support.

The key takeaway for Workspace Admins

Treat the copy as a new model. Anything that points to the original, by ID, by connection, or by link, keeps pointing to the original until you update it. Keep the original locked, not deleted, until everything points at the copy. 

What needs to be reviewed

1. Workspace and model IDs

Because the copy is effectively a brand-new model, both IDs change. That also means that integrations relying on those will need to be updated. 

• Have you updated every integration using those IDs? That includes: 
  • Anaplan Connect scripts
  • Third-party tools (SnapLogic, Boomi, Informatica Cloud, or similar), 
  • Custom API integrations and scheduled jobs.

2. ALM 

• Do you need to keep your revision tags? Model builders can’t copy revision tags between workspaces. Anaplan Support can import a model with revision tags intact if you need to retain the model's full revision history. 
• Is your target workspace near capacity? Plan this one carefully. Increase the workspace size if possible, especially if you are moving a Polaris model, which has more variable overhead than a Classic model, before importing it into the workspace. 

3. Source model links

• Is the model a source for other models? The import data sources in those dependent models still point at the original. Open the dependent model, go to Import Data Sources, edit the mapping, and point it at the new workspace and model. Do this before you archive or delete the original.
• Are both models in a hub-and-spoke relationship moving? The copies still reference the old models until you remap them.

4. Flat file imports

Import actions, which contain the mapping, are copied across and continue to work. What isn’t retained is the link to the specific file uploaded against each data source.

• Have you re-uploaded the file to each flat file data source? Do this before you run its import.
• Have you checked every process that runs a file-based import? Confirm the file is in place.
• Do integrations that push files target the new IDs? That includes anything using the API or Anaplan Connect.

5. Anaplan Data Orchestrator (ADO)

ADO connections and pipelines are tied to the original model, so plan to rebuild them.

• Have you rebuilt the links between ADO and the new model? That includes any model-to-ADO data connections.
• Have you reviewed every pipeline that syncs data to or from the moved model? Recreate the sync against the new model, then test a full run end to end.
• Are schedules re-enabled and pointed at the right target? Check every affected pipeline after the change.

6. Anaplan XL (AXL)

AXL workbooks reference the original connection, so they need to be remapped.

• Have you remapped each workbook’s connection to the new model?
• Do any reports need to be rebuilt? Pages, worksheets, and reports may need rebuilding where remapping doesn’t carry the existing layout and queries across.
• Have you inventoried all AXL workbooks and owners before the move? Users often only discover broken reports after cutover.

7. Users and access

A word of caution on the Users List.  Consider the impact of the users list between workspaces carefully. On the one hand, moving a model to a new workspace means that you can have a different set of users and/or WSA.  This may provide segregation of duties and potentially a more appropriate set of users to manage. On the other hand, you may lose some audit trail when copying over models to the new workspace. 

• Are there user-dimensioned entries in the model that need to be retained? Entries made against a specific user will only copy across if the user is in both workspaces prior to the import. 
• Have user access, role, and selective access been reviewed? Reprovision any users who weren’t in the target model at the time of the copy, and reapply the role and selective access as necessary.
• Have you verified model role settings? Confirm that the proper module, action, list and version settings are applied for each role.
• Have you told users about the cutover? Include the new model name or location if it changed.

8. App pages and workflow

• Have you remapped each App page to the new model? Then check cards, filters, actions, and buttons on every page.
• Does role-based access to the App still reflect the intended audience? If you are using restricted roles or users, verify that they have been applied appropriately after the move.
• Have you reviewed workflow tasks and assignments? They also reference the original model.

9. Forecaster and Optimizer

• Have you rebuilt or repointed your Forecaster models? Forecaster needs this after a move.
• Have you verified your Optimizer runs? Optimizer doesn’t require a rebuild, but confirm it behaves as expected if it is integrated with the model.

10. Documentation and shared URLs

URLs contain workspace and model identifiers, so links to the old model won’t resolve to the new one, and everyone’s saved links will change.

• Have you updated shared URLs, bookmarks, and links?
• Have you updated documentation and communicated the change? Include runbooks, training material, and support guides that mention the old workspace, model name, or IDs.
• Have you replaced links embedded in other tools? Wikis, intranet pages, emails, and Teams or Slack channels. Don’t rely on users to find the new location.
• Have you updated your model and integration register? Add the new workspace ID and model ID.

Recommended approach

1. Inventory dependencies. List upstream and downstream models, ALM relationships, ADO pipelines, AXL workbooks, App pages, workflow tasks, integrations, flat file data sources, user groups, and published links.
2. Check target capacity. Confirm the destination workspace has room before you start.
3. Confirm roles. Make sure the person copying is workspace admin in both workspaces.
4. Decide on ALM. Rebuild the chain, or request a Support-assisted import to preserve revision tags.
5. Freeze changes in the original model for the duration of the move.
6. Copy the model. 
7. Relink and remap. Update source model mappings, integration IDs, ADO links and pipelines, AXL connections, App pages, and workflow. Re-upload files for flat file data sources.
8. Validate. Reconcile data against the original. Run every process, integration, pipeline, and key report.
9. Update users and documentation. Confirm access, replace shared URLs, and refresh documentation.
10. Cut over, then archive. Only archive or delete the original once everything points at the copy.

Treat the move as a mini release, with a rollback plan and a named owner for each integration, pipeline, and report. Keep the original model available but locked down until sign-off, so you have something to compare against.

Resources & Discussions

• Impacts of Copying or Importing a Model
• Can we copy a model from one workspace to another?
• Moving Production Model to new workspace
• Source Model and moving model between workspaces

Please note: The articles in our Best Practices section are authored by Anaplan internal experts to provide thought leadership, technical guidance, and educational tutorials. Because every customer environment is unique, these best practices, including any custom code, scripts, or formulas, are provided "as-is" and may not apply directly to your specific use case. Customers are responsible for testing and adapting these solutions for their own environments. Please note that standard Anaplan Support does not cover the troubleshooting, maintenance, or custom modification of code or implementations derived from these articles.