Best Practice : Migration into a production environment

Post Reply
Emixam
Posts: 139
Joined: Tue May 21, 2019 3:33 pm
OLAP Product: TM1
Version: PA 2.0.x
Excel Version: 2016
Location: The Internet

Best Practice : Migration into a production environment

Post by Emixam »

Hello Guru,

I'm currently doing a migration into a model in production and I have to migrate more than 250 objects (new and some already exist in prod).

What's your best practice to never forget an object ? What's the fastest way to create a migration package ?

Thanks and have a good day !
User avatar
PavoGa
MVP
Posts: 616
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Best Practice : Migration into a production environment

Post by PavoGa »

There are a number of different methods, many of which are elucidated on this forum.

However, working two simple scenarios:

1) migrating everything from DEV to Prod

Shutdown both servers (or run Save Data on DEV) and copy the DEV\data folder to PROD\data folder. Restart Prod instance.

2) migrating some items in DEV to Prod

Save Data on DEV, copy desired items into a folder, shutdown PROD, copy desired items to PROD\data folder. Restart Prod. If you have network latency issues, modify the above sequence to include zipping up the DEV objects.

Not going to claim this as best practice, but when developing, I use Beyond Compare and, as I create/edit objects that will need to be migrated, I add them to a session filter which can be used to compare and manipulate objects through our particular migration method. For objects that I do not wish to migrate, but do need to be updated, I write what I call an init. processes that updates any dimensions/attributes/cube values that will properly implement the new development. This has work very well for us, particularly where we really do not want to overwrite an attribute cube in prod and do not want to manually update it.
Ty
Cleveland, TN
blackhawk
Community Contributor
Posts: 136
Joined: Thu May 29, 2008 2:29 pm

Re: Best Practice : Migration into a production environment

Post by blackhawk »

While you certainly can do it manually, it is error prone, and it doesn't catch things that are data and metadata related. Using Beyond Compare or WinMerge tools are great for processes and rules, but when it comes to comparing dimensions, or attribute data, or even cube data, that is where the manual effort falls apart. Beyond Compare is great and certainly more refined, but WinMerge is free! (we like free) https://winmerge.org

It is really hard to migrate partial objects as well. When you copy over the attributes cube, you get all the attributes from the development copy. But what happens when production has been updated in the meantime? How do you move just one attribute. You will have to log into prod, add the attribute and then copy the data manually. Same goes for dimension elements. Copying over the .dim file will replace all elements, not just changed ones.

For those kinds of things you can do a few things:
  • Create a spreadsheet with a tab for each dimension and then list out all the elements for that dimension on each server side by side. Then you can do vlookups to see if something new was added. You can do the same for attributes. Data gets to be a bit harder, but that is less frequently migrated from server to server.
  • There are also third part tools that do the comparison and migration for you. They cost money, but as you can see if you have a lot of objects, or you do the migrations frequently, they can be huge timesavers. One such tool is TM1Compare. https://www.tm1compare.com.
Disclaimer: I work for the company that built TM1Compare.

Good luck with your migration!
lotsaram
MVP
Posts: 3651
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Best Practice : Migration into a production environment

Post by lotsaram »

PavoGa wrote: Tue Oct 22, 2019 2:31 pmFor objects that I do not wish to migrate, but do need to be updated, I write what I call an init. processes that updates any dimensions/attributes/cube values that will properly implement the new development. This has work very well for us, particularly where we really do not want to overwrite an attribute cube in prod and do not want to manually update it.
This is pretty much exactly the use case that bedrock.hier.export.script was developed for. The process exports as TI code the script required to build dimensions (or hierarchies). There are options to filter on particular elements, attribute definitions, etc. It's a super easy way to generate this kind of code which from where the relevant parts can then be copy/pasted into an upgrade or migration process.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
User avatar
PavoGa
MVP
Posts: 616
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Best Practice : Migration into a production environment

Post by PavoGa »

blackhawk wrote: Tue Oct 22, 2019 3:56 pm While you certainly can do it manually, it is error prone, and it doesn't catch things that are data and metadata related. Using Beyond Compare or WinMerge tools are great for processes and rules, but when it comes to comparing dimensions, or attribute data, or even cube data, that is where the manual effort falls apart. Beyond Compare is great and certainly more refined, but WinMerge is free! (we like free) https://winmerge.org
Beyond Compare will compare dimensions. It is limited, so for instance if a dimension in PROD is routinely updated with new elements, BC's effectiveness is limited very quickly. With regards to WinMerge, one gets what one pays for. For example, I grew up on a farm and there are reasons why we used John Deere tractors, which are far more expensive than mules.
Last edited by PavoGa on Thu Oct 24, 2019 12:50 am, edited 1 time in total.
Ty
Cleveland, TN
User avatar
PavoGa
MVP
Posts: 616
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Best Practice : Migration into a production environment

Post by PavoGa »

lotsaram wrote: Tue Oct 22, 2019 7:11 pm
This is pretty much exactly the use case that bedrock.hier.export.script was developed for. The process exports as TI code the script required to build dimensions (or hierarchies). There are options to filter on particular elements, attribute definitions, etc. It's a super easy way to generate this kind of code which from where the relevant parts can then be copy/pasted into an upgrade or migration process.
Ah! Good to know and I will check it out. Typically, we do not have a lot of lines in our inits and almost all are in the prolog. A lot are making calls to existing sub processes to perform the metadata changes then the rest do the updates; for example, setting an attribute value or various security settings.
Ty
Cleveland, TN
blackhawk
Community Contributor
Posts: 136
Joined: Thu May 29, 2008 2:29 pm

Re: Best Practice : Migration into a production environment

Post by blackhawk »

PavoGa wrote: Wed Oct 23, 2019 12:13 pm Beyond Compare will compare dimensions. It is limited, so for instance if a dimension in PROD is routinely updated with new elements, BC's effectiveness is limited very quickly. With regards to WinMerge, one gets what one pays for. For example, I grew up on a farm and there are reasons why we used John Deere tractors, which are far more expensive than mules.
Yeah, Beyond Compare is certainly better than WinMerge without question (I use it internally), especially comparing code and JSON data, but in a lot of places we go where the customer doesn't have it, getting authorization to purchase a product takes a lot of time and paperwork. WinMerge seems to get the job done sufficiently for our limited use of it. That is why we also see Notepad++ everywhere too.
User avatar
PavoGa
MVP
Posts: 616
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Best Practice : Migration into a production environment

Post by PavoGa »

blackhawk wrote: Wed Oct 30, 2019 2:21 pm
Yeah, Beyond Compare is certainly better than WinMerge without question (I use it internally), especially comparing code and JSON data, but in a lot of places we go where the customer doesn't have it, getting authorization to purchase a product takes a lot of time and paperwork. WinMerge seems to get the job done sufficiently for our limited use of it. That is why we also see Notepad++ everywhere too.
Yes, very true. Been lucky and been able to get clients to buy BC4, but that may just be luck or BC4 should be sending me commission checks... :D
Ty
Cleveland, TN
Post Reply