TM1 Forum

Hi,

Our client is downgrading existing application from TM1 9.5.2 (in which it was created) to old version 9.2.1 due to licensing/some other issues - could anyone please clarify below queries

1. Is it possible to downgrade TM1 9.5.2 application to TM1 9.2.1?
2. What are the possible issues that we might have to overcome/face?
3. Will there be any impact on performance? (processes: 50, Dimensions: 40-45, Cubes 15 - 3 main with 12 supporting cubes)
4. Creation of Dimensions, Cubes and Security are done via processes coded in 9.5.2 i.e. can we run the same code/processes in 9.2.1 without any changes?
5. Issues that we have to keep in mind while downgrading.
6. Link to any documents or articles which might help us.

I guess, your answers will give me heads up for upcoming downgrade

Thanks,
Logan

LoganNSE wrote:Hi,

Our client is downgrading existing application from TM1 9.5.2 (in which it was created) to old version 9.2.1 due to licensing/some other issues - could anyone please clarify below queries

1. Is it possible to downgrade TM1 9.5.2 application to TM1 9.2.1?
2. What are the possible issues that we might have to overcome/face?
3. Will there be any impact on performance? (processes: 50, Dimensions: 40-45, Cubes 15 - 3 main with 12 supporting cubes)
4. Creation of Dimensions, Cubes and Security are done via processes coded in 9.5.2 i.e. can we run the same code/processes in 9.2.1 without any changes?
5. Issues that we have to keep in mind while downgrading.
6. Link to any documents or articles which might help us.

I guess, your answers will give me heads up for upcoming downgrade

Thanks,
Logan

Hi Logan,

There is no such thing as a TM1 version 9.2.1 - TM1 skipped some versions going from version 9.1.4 directly to 9.4.0.
If you meant 9.1.2 instead of 9.2.1 than you're facing the problem that you have to rebuild your TM1 database, as version 9.5.2 is Unicode encoded, while version 9.1.2 is not and therefore is unable to read the TM1 9.5.2 database files.

Michel

Michel Zijlema wrote:version 9.5.2 is Unicode encoded, while version 9.1.2 is not and therefore is unable to read the TM1 9.5.2 database files

There was a 9.1.x release that did enable the use of Unicode and TM1 (see here) but this was an Applix thing and I very much doubt IBM support this release, or even are willing to release it to a downgrading customer.

LoganNSE wrote:1. Is it possible to downgrade TM1 9.5.2 application to TM1 9.2.1?

I guess technically it is, but as Michel points out, you're not going to be able to just uninstall, reinstall and fire up the same instance because of the Unicode issue. I guess you have a back-up of your model before you upgraded? Then, you might be able to fire that up after the downgrade and go through a one-time exercise of manually changing all the rules/ TI/ etc to align to the current model.

LoganNSE wrote:2. What are the possible issues that we might have to overcome/face?

Unfortunately, probably several hundred. Just check the release notes from 9.4.x through 9.5.1 and work out how many bugs that were fixed will be re-introduced into your model. Also, if your current model relies on functionality that wasn't present in 9.1.4 then this is also going to be a large problem.

LoganNSE wrote:3. Will there be any impact on performance? (processes: 50, Dimensions: 40-45, Cubes 15 - 3 main with 12 supporting cubes)

I guess there would be a performance impact and maybe a positive one as, anecdotally, one can see TM1 slowing down in certain areas in its evolution as newer features get introduced. This concern would be very secondary to the problem of (2) though.

LoganNSE wrote:4. Creation of Dimensions, Cubes and Security are done via processes coded in 9.5.2 i.e. can we run the same code/processes in 9.2.1 without any changes?

Per Michel's point, no, changes are going to be required, perhaps in line with my response to question (1).

LoganNSE wrote:5. Issues that we have to keep in mind while downgrading.
6. Link to any documents or articles which might help us.

Primarily I would consider what sort of length of outage is going to occur here for your users, and the risk that you won't be able resume normal service at all... I don't think there is any official doco that is really going to help you with specifics but happy to be proved wrong.

LoganNSE wrote:Our client is downgrading ... due to licensing/some other issues

I sympathise with the forum school of thought that says don't question the question, just answer it... but on this occasion, the obvious elephant in the room is the reason why you are downgrading... Perhaps you need to present the twin risk and effort issues to the person making this decision to see if they want to re-evaluate the benefits of proceeding down this path. Personally, I would urge you not to do it!

LoganNSE wrote:Hi,

Our client is downgrading existing application from TM1 9.5.2 (in which it was created) to old version 9.2.1 due to licensing/some other issues - could anyone please clarify below queries

Licensing? REALLY? Seeing as TM1 is not, and never has been licensed on a version basis i do not believe that for a minute.

All the previous comments should be taken in and thought about thoroughly. Downgrading is a monumentally bad idea. Another one to add to the mix is IBM support - i doubt 9.1.x will get much joy from IBM other than the standard "you should upgrade" response.

rmackenzie wrote:

LoganNSE wrote:Our client is downgrading ... due to licensing/some other issues

I sympathise with the forum school of thought that says don't question the question, just answer it...

I think that one may have been misconstrued a little. I don't think that the school of thought is "don't question the question", it's more "just don't do it in a way that may make the original poster feel like an idiot for not seeing the superiority of the answerer's own preferred solution" and/or "don't assume that the poster doesn't have a reason for asking which may not have been fully outlined in their post"[1]. Raising alternative options or even room-bound elephants in the way that you've done here is both constructive and useful.

rmackenzie wrote:but on this occasion, the obvious elephant in the room is the reason why you are downgrading... Perhaps you need to present the twin risk and effort issues to the person making this decision to see if they want to re-evaluate the benefits of proceeding down this path. Personally, I would urge you not to do it!

Agreed. Unless you hit severe stability issues, I think that going back is always a perilous idea for all of the reasons that you've given and then some.

---------------
[1] Unless the poster has a demonstrated history of really badly thought out, badly expressed time-wasting questions that they never seem to listen to the answers to and who never seem to put any effort into finding the answers for themselves, but that's a whole other thing. (And no, I'm not referring to any specific person here.) However there have been some instances where first time posters have all but had their noses slammed in the door for asking a "wrong" question, which doesn't exactly encourage new members to speak up.

TheEnforcer wrote:Licensing? REALLY? Seeing as TM1 is not, and never has been licensed on a version basis i do not believe that for a minute.

I don't want to get too far off topic as I basically agree with the points everyone else has raised already. But, as has been pointed out on quite a few occasions IBM's licensing when it comes to Cognos products is "somewhat less than transparent." Certainly I have heard on more than one occasion things from IBM sales representatives along the lines of "customer X needs to convert from concurrent users to named user licensing model" or "customer Y needs to convert from server based to PVU based licensing" in order to go beyond version 9.x and access features in the current version not currently licensed or in order to go from 32 bit to 64 bit. (with the .x being the 9.1 to 9.4 Unicode divide and the 9.4 to 9.5 inclusion of Contributor, I guess you could include x64 in this argument as well since it used to be sold as a separate component).

Whether such lines of argument from IBM actually stand up or are legally valid may or may not be questionable depending on the specifics of the contract with the customer in each particular case. And to a large degree it's a moot point anyway since ultimately it seems to all come down to a negotiation with IBM hinging to no small extent on the price the customer will bear and how badly IBM wants the sale. I'm just saying that I have certainly heard of cases where IBM has insisted that customers can't use particular versions or features without first changing licensing (i.e. coughing up more money) so I don't think you can say that TM1 has never been licensed on a version basis in such strong terms.

lotsaram wrote:

TheEnforcer wrote:Licensing? REALLY? Seeing as TM1 is not, and never has been licensed on a version basis i do not believe that for a minute.

I'm just saying that I have certainly heard of cases where IBM has insisted that customers can't use particular versions or features without first changing licensing (i.e. coughing up more money) so I don't think you can say that TM1 has never been licensed on a version basis in such strong terms.

That's a depressingly good point. I can also imagine the following scenario:
- User is on maintenance and on version x;
- User receives an obscenely large annual bill for maintenance;
- User allows the maintenance contract to lapse;
- Version Y is released and User downloads it;
- IBM kills user's account access for non-payment of maintenance;
- In a subsequent audit IBM discovers that user is on a version that was released after the maintenance contract expired;
- IBM insists that the user downgrade "unless we come to some arrangement". (And as one IBMer once said to me, "You think that paying maintenance is painful? Try going off it and then getting back on.")

I'm not saying that that's what happened here, but I can certainly envisage such a chain of events.

All,

Sorry - it was 9.1 and not 9.2.1 and their user base is > 200

First of all - I have no idea why my client was downgrading, they just want their app in 9.1 instead of 9.5.2. When questioned, they said "licensing issues" and I am not sure of what might that be.

I had already suggested them that downgrading is not recommended however they insisted on it and of course "adamant" and ready to face difficulties. I was out-of-project as I told them that it will not succeed and have to go through a lot of pain to make it work.

Thanks a lot for your views and informations (felt Idiot myself on asking such questions as 99% will look-out for Upgrade rather than downgrade )

I will update you all after a month on the status of downgrade - they have hired a new consultant to do it instead of us (employee) - may be he will develop it from scratch in 9.1.x instead of mere downgrade!!!

Logan

LoganNSE wrote:I will update you all after a month on the status of downgrade - they have hired a new consultant to do it instead of us (employee) - may be he will develop it from scratch in 9.1.x instead of mere downgrade!!!

While downgrading is probably not a good idea, it really wouldn't be that difficult to accomplish.

1) Export all the data to CMA files and export the dimensions to XDI files.
2) Install 9.1.4 on a separate box with no cubes or anything on it.
3) Check tm1s.cfg file on 9.1.4 and make changes based on what you have on 9.5.2 instance (making sure not to reference options that don't exist in 9.1.4)
4) Create dimensions on 9.1.4 from the XDI files
5) Create cubes on 9.1.4.
6) Create attributes on 9.1.4
7) Write one-off TI processes to load all data from step 1.
8) Create rules on 9.1.4 by opening rule editor and cut and paste rules code from 9.5.2.
9) Stop 9.1.4 service and copy in all .pro, .vue and .sub files from 9.5.2 (skip any Contributor files)
10) Re-start 9.1.4 service and test, test, test.

I'm not 100% sure about step 9) working but I'm pretty sure it will work since these are all just plain text files. If it doesn't you'll have to re-create views, subsets, and processes. but it shouldn't be that hard. An experienced TM1 person should be able to do this in less than a week.

tomok wrote:An experienced TM1 person should be able to do this in less than a week.

Wow, I see you're full of festive cheer and optimism! LoganNSE, I suggest you recommend to your client that they get tomok in, with that quote!!

Martin Ryan wrote:Wow, I see you're full of festive cheer and optimism! LoganNSE, I suggest you recommend to your client that they get tomok in, with that quote!!

I take it you disagree. Actually, I think a week is quite conservative. My time estimate was not a customer quote or anything like that because I didn't include time for discovery, documentation, backups, etc. I was just trying to give the OP an idea on how long it would really take an experienced TM1 person to do the actual downgrade steps so he would be better prepared to judge quotes. If I was proposing for this engagement I would double it, for contingencies, and then add a few days for documentation, etc.

I think it's a best case scenario which would set an unrealistic expectation. If everything went to plan then I agree, a week would be ample. But as mentioned above there have been a fair few changes between the two versions and I think there is a big potential for problems where rules don't work anymore.

tomok wrote:If I was proposing for this engagement I would double it, for contingencies, and then add a few days for documentation, etc.

I'd agree more with that. That also means that a quote of three weeks (generous, but reasonable in my view) would get a look in, whereas with your initial estimate it may not.

When I could get away with it because it was internal charging, not consulting, my old rule of thumb was to triple my initial estimate (I'm not the only one). About 80% of the time I'd blitz that estimate - the end user was always pleased to get it earlier and cheaper than originally promised - but for the other 20% of the time I was glad I had given myself the padding.

Though I appreciate that methodology is a bit harder to do when competitively quoting in the consulting world.

Martin