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 guide only. It will not contain all the steps needed for your environment. Work through it carefully and then turn it into something that you can use.
Step by Step Guide for Migrating TM1 Servers from Development to Production
The steps in our deployment guide for TM1 are:
- Tell all users to get off both source and target models.
- Backup the target environment to a local zip file and name it something like servername_YYYYMMDD, so “TM1Prod_20160421”.
- Assess if you are migrating the entire environment or just some object.
- If full, then you will need to modify the tm1s.cfg file on the target so it refers to local.
- 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:
- Application files (Excel, Links etc)
- Shut down the source and target TM1 instances.
- 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.
- Copy the zip to the target server and unpack.
- Check that once again you have the production server backed up!
- Copy the objects from the unpack location to the target server location.
- Start the TM1 instance on the target server.
- Modify the System Settings cube and any hard coded Processes to refer to the target server name and data sources.
- Validate that the server is behaving as it should.
- Do Unit Testing that all cubes open, that relevant views open and that rules can be opened and saved and processes can run.
- Have Users log in and then do their own Acceptance Testing, which will likely include data reconciliation, report and view usage, contributor application usage
- Review this process and update it for specifics in your environment.
Finally, if you come across anything that you think should be on our TM1 migration checklist, please let us know so we can update it!