The Definitive Guide to TM1 Migration from Dev to Prod

TM1 migration isn’t the strongest point of this great tool. Pretty well all TM1 installations should have a Dev, Test and Production server or TM1 instance. This allows us to build and experiment in Dev, test our changes and then migrate what we want to Production – without breaking Production with an error during development! This will guide you through the important steps for migrating TM1 from development to production.

Important Notes before you Move a TM1 Model from Dev to Test

A few points before we get into our steps for TM1 migration:

• First of all, TM1 does not support technology-driven migration tools, so you have to do it manually.  Therefore we strongly encourage you to use a change log to list what you are doing in one environment before migrating it to the new.
• Secondly, we also recommend that you do not migrate straight from Dev to Prod. Rather, have a fully refreshed version of Prod in a Test environment and then update there first, make sure it works, then take the deployment package to Production.
• Thirdly, ideally you would not have a developer do the migration or testing – get a different person completely. This then ensures that the documentation is complete, that the person migrating can follow the instructions and that there is increased rigour in managing the deployment process.
• Fourth, when we are doing this, the biggest risk is the loss of data in a cube on the Production (target) server as this data is live and may be more up to date than the source.
• Next, this document only covers the deployment of standard TM1, not Contributor or TM1 Web. For Contributor Applications, we recommend you take a look at the Transfer Specification Editor which started in TM1 10.2.
• Finally, this is a rough guide only.  It will not contain all the steps needed for your specific environment. Work through it carefully and then turn it into something that you can use.

Methods for TM1 Deployment

There are two primary methods for deploying from one TM1 server to another. They are:

• Copy and paste only the elements that have changed (use this method when you have a small number of changed objects that need to be migrated and you are confident of copying all changed items).
• Copy out the objects to be kept in the target, then copy everything from the source, then copy back the objects to be kept. (use this method when you have a large number of changed objects or your confidence in ensuring all changed items is migrated is low).

Step-by-Step Guide for Migrating TM1 Servers from Development to Production

Method 1 – Deploy Only the Changed Elements

1. Tell all users to get off both source and target models.
2. Backup the target environment to a local zip file and name it something like servername_YYYYMMDD, so “TM1Prod_20160421”.
3. Assess if you are migrating the entire environment or just a set of objects.
4. If full, then you will need to modify the tm1s.cfg file on the target so it refers to local.
5. If specific objects, list elements of what has been changed and this will form the basis of your migration guide for the person deploying your package. You will need a good understanding of the types and locations of TM1 files (.PRO – process, .VUE – views, .RUX – rules, .CUB – cubes, .SUB – subset etc) . These objects could include:
   1. Cubes
   2. Dimensions
   3. Processes
   4. Chores
   5. Rules
   6. Attributes
   7. Application files (Excel, Links etc)
6. Shut down the source and target TM1 instances.
7. Create a zip file from the source containing only the objects that are required in the target environment. We suggest that you use a naming convention that identifies the source server name, a subject and the date. So something like “TM1Dev_Inventory_20160421.zip”. This will help with version control.
8. Check that once again you have the target server backed up!
9. Copy the objects from the source to the target server and unzip.
10. Start the TM1 instance on the target server.
11. Modify the System Settings cube and any hard coded Processes to refer to the target server name and data sources.
12. Run your refresh TI’s to update dimensions and cubes with data from the source databases.
13. Validate that the server is behaving as it should.
14. Do Unit Testing that all cubes open, that relevant views open and that rules can be opened and saved and processes can run.
15. Have Users log in and then do their own Acceptance Testing, which will likely include data reconciliation, report and view usage, contributor application usage
16. Review this process and update it for specifics in your environment.

Method 2 – Migrate Everything and Put Back the Data

1. Tell all users to get off both source and target models.
2. Backup the target environment to a local zip file and name it something like servername_YYYYMMDD, so “TM1Prod_20160421”.
3. On the target server, copy the tm1s.cfg file, all .cub files (as these contain the data) and any dim files that are not able to be recreated perfectly from source data to a temp folder. You will use these copied objects later to restore them to the Data folder after you have copied the entire contents of the source data folder to the target server.
4. Shut down the source and target TM1 instances.
5. Create a zip file from the source containing the entire contents of the source Data folder. We suggest that you use a naming convention that identifies the source server name, a subject and the date. So something like “TM1Dev_Inventory_20160421.zip”. This will help with version control.
6. Check that once again you have the target server backed up!
7. Copy the objects from the source to the target server and unzip.
8. Go to the temp folder from above and copy everything from there to the Data folder. You will be prompted to overwrite files. This is ok, because you are restoring here the cubes, dimensions and possibly the TM1s.cfg file.
9. Start the TM1 instance on the target server.
10. Modify any hard coded Processes to refer to the target server name and data sources.
11. Validate that the server is behaving as it should.
12. Run your refresh TI’s to update dimensions and cubes with data from the source databases.
13. Do Unit Testing that all cubes open, that relevant views open and that rules can be opened and saved and processes can run.
14. Have Users log in and then do their own Acceptance Testing, which will likely include data reconciliation, report and view usage, contributor application usage
15. Review this process and update it for specifics in your environment.

Download of the Infocube Internal TM1 Migration Checklist

Please feel free to download our internal Infocube migration checklist and use it in your own environment. Please note that you will need to update it to reflect you specific TM1 models and servers. Here is the file: Infocube TM1 Migration Plan.

Note, if you come across anything that you think should be on our TM1 migration checklist, please let us know so we can update it

Smart Selection of Migration Objects

We also have a great blog post on how to use some of the smart Windows tools to select your objects for migration. Please see this link for more information on this.

Need Help with TM1 Migration?

If you need some help with how to set up your migration processes or just want to get some advice, please reach out to us. We’d be delighted to offer you some advice, or to help you get it done.