Upgrading only one ODX project/environment to new version for testing

Hi Rory,

Internal testing by my colleagues shows this combination (partial upgrade) may work OK.  

However, for some other combinations of TX and ODX versions, there may be issues when there are changes in client API version.

Hi Syed,

so just to reiterate I should be able to:

• Install ODX Server 20.10.40 and upgrade the cloud repositories in our Dev/Test cloud
• ODX Server 20.10.35 in our Prod cloud will not complain about API version mismatches and keep working

I have experienced that the other way around: TimeXtender 20.10.40 connecting to ODX Server 20.10.35 does not work due to an API version mismatch.

Also, if you wanted to test not only the ODX but also the TimeXtender projects in 20.10.40, then please take into account that upgrading the TX repository is irreversible, so we recommend using a copy/backup of the TX repository in this case

Hi @Christian Hauggaard ,

thanks - as we have a completely mirrored infrastructure with its own repository database this is/should not be a problem. 

@rory.smith regarding your question above, yes this should be possible. We recommend that you do your own testing of this on a sandbox environment before proceeding

Hi @Christian Hauggaard ,

Would the corresponding scenario be possible with version 6xxx. Two sets of ODX, MDW and SSL on two separate application servers, as long as we don’t try to open an instance on the “wrong” server or copy between the versions?

BR
Anders

@Christian Hauggaard , @Syed Yousuf 

I have tested this in our environment: ODX Server 20.10.40 , a TimeXtender 20.10.35 cannot connect due to client API mismatch:

Is there any workaround for this? As a worst-case a new license number and manual copy of the cloud repository database on your end might work, but I would prefer some more friendly solution as reverting in case of breakage would also require you to (quickly) restore a backup of the cloud repository.

@rory.smith you would need to use TimeXtender 20.10.40 desktop app to open the ODX running on 20.10.40.

@Christian Hauggaard ,

and that is exactly our problem. On Prod we are running ODX Server and TX 20.10.35 - I am evaluating 20.10.40 in a separate infrastructure to ensure there are no surprises. Having to snapshot everything and wait for you to restore a cloud repository to 20.10.35 would make it difficult to upgrade given that we do not want to risk a disturbance to the business.

OK to clarify you want to keep everything the same in production (ODX 20.10.35 and TX 20.10.35), while testing on a separate infrastructure - installing ODX 20.10.40 and TX 20.10.40 for a different ODX project/environment and a separate TX repository than the one in production. Then once you are done testing and ready to upgrade, you upgrade to ODX 20.10.40 and TX 20.10.40 in production. Is this correctly understood? 

I do not believe there is a workaround to get ODX 20.10.40 to work with the 20.10.35 Desktop app. Also, we do not currently support reverting to a prior ODX version once you have upgraded. Please feel free to submit this in the ideas section.

@Christian Hauggaard ,

alright - so the current upgrade path for 20.10.x with ODX Server has no fallback for surprises? Given that I am using Theobald DeltaQ over SSIS here, I do not really want to break things. Can I then request a separate “license” and a copy of the remote repository database to the new database for the new “license”?

Correct, there are currently no fallback/revert possibilities. Since there is currently no copy feature for ODX projects/environments in 20.10.x, I suggest setting up and testing the DeltaQ data source in a separate separate ODX project before upgrading the production ODX project

@Christian Hauggaard so each project is separate? The versions are not coupled? That would solve my issue in that case.

Hi all,

upgrading the sandbox ODX environment to 20.10.40 has not affected the production ODX environment running on 2.10.35.