/
TM1 Deployments Best Practices

TM1 Deployments Best Practices

This guide outlines recommended practices for Pulse migrations, supported deployment scenarios, known limitations, and automation options. Use DEV→UAT→PROD with Change Tracking enabled, prefer process-driven data moves, and note that live view migration is targeted for v7.3.0. API-based automation is available upon request.

Best Practices

  • Follow Cubewise best practices for Pulse migration.

  • Use the step-by-step procedure for live and offline migrations (see Migration guide above).

  • Before deployment, validate prerequisites and plan rollback.

  • Ensure Change Tracking works in all environments; promote DEV → UAT → PROD.

 

Migration

 

Validate Change Tracking in all environments. Promote changes sequentially: DEV → UAT → PROD.

Deployment Scenarios

  • Migrate Dimensions, Attributes, Cubes, Rules, and Processes.

  • Deploy objects as a full package or individually.

  • Perform hot deployments of Views and Subsets where supported.

 

 

Live Migration of subset is available but Source Level needs to be enabled:Enabling the Live Migration of Subsets

 

• What are the best practices and risks for migrating Dimensions and Cubes?

Pulse driven by Source control, will detect the difference between the source and target and remove the objects which are no longer required to be in the target.

Migrating cube data, it’s all or nothing, clear the all cube in the target instance

 

Limitations

  • Known issues and mitigation steps will be reviewed during planning and testing.

  • One package can be executed to only one TM1 instance at a time.

  • Process-driven element creation and data loading is faster than object-level data migration; prefer running TI processes during deployment (see link).

These will be addressed during design and testing reviews.

• Understand the current limitations of the Pulse deployment process.

One package can executed only to one TM1 instance at a time.

Note: Live Migration of views is targeted for v7.3.0.

Migration elements or cube data is faster executing a process instead of asking Pulse to create elements or load the data. It is recommended to ask Pulse to execute processes during the migration Executing a Process during migration

• Can Pulse be a single, all-in-one tool for 100% of deployment changes?

Yes, Pulse can migrate all objects. Live Migration of views is coming in v7.3.0

• Is it possible to avoid granting full admin rights for documentation updates during deployment?

It is not required to run the Pulse documentation when doing a migration. The Change Tracking feature is picking up changes automatically by default every 30 seconds. If changes are not picked up, then we should investigate why Change Tracking is not working.

Automation & CI/CD

• Explore possibilities for automating deployments using Pulse. Learn how to set up an automatic CI/CD pipeline for TM1 deployments.

Pulse Migration Package CLI Utility Guide

Pulse includes a non public API to execute migration package. This can be shared if requested by the customer.