Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X
Version: Windchill 12.1
Use Case: Hi, we are upgrading Windchill + Flexplm 11.0m030 to Windchill + Flexplm 12.1.2.9. we have completed upgrade for 3 rehersal as well. Now during the pre prod and production we are reusing the Windchill 12.1.2.9 application servers. If we install ootn 12.1.2.9 and perform upgrade as a part of pre-prod. Can we simply drop the db user which was upgraded as a part of preprod,create a new user and import the database and execute the upgrade manager ? Similar way we normally refresh our lower environment using rehosting.
Description: 
1. During pre pod rehersal, Windchill ootb installation+ upgrade is completed.
2. During the next rehearsal can we use the same above Windchill instance by dropping the db user, recreate and re import the database and execute the upgrade manager.
Solved! Go to Solution.
For multiple upgrade passes of one system (e.g. production), I follow this approach to minimize risk throughout the process. The first part occurs once per upgrade, independent of upgrade passes.
The iterative part is...
So, for each upgrade pass, I get a fresh copy of the 11.0 production database for the upgrade source environment. However, as @BenLoosli said, the upgrade manager will not recognize the DB unless you also restore the target Windchill 12.1 from your restore point backup.
If you are using SQL Server, you can just restore the 11.0 DB backup into the upgrade source DB. You don't have to delete and recreate the DB to reset. For Oracle, I typically drop and recreate the Windchill database and then import the 11.0 DB from production.
Nope
UpgradeManager will complain that the system is already at the target version and not go any further. There are files in the Windchill installation structure that get modified by UpgradeManager, it is not all DB updates.
I do many test upgrades, too and always wipe my systems back to nothing before starting an additional upgrade test. This includes running Regedit to remove all traces of the Oracle and Windchill installation on both servers.
For multiple upgrade passes of one system (e.g. production), I follow this approach to minimize risk throughout the process. The first part occurs once per upgrade, independent of upgrade passes.
The iterative part is...
So, for each upgrade pass, I get a fresh copy of the 11.0 production database for the upgrade source environment. However, as @BenLoosli said, the upgrade manager will not recognize the DB unless you also restore the target Windchill 12.1 from your restore point backup.
If you are using SQL Server, you can just restore the 11.0 DB backup into the upgrade source DB. You don't have to delete and recreate the DB to reset. For Oracle, I typically drop and recreate the Windchill database and then import the 11.0 DB from production.
Upgrade strategies vary based on size of the data set being upgraded. I'm not following what you are asking. Are you just upgrading one system (production) and cloning to create/refresh pre-production, test, dev, etc.? Or are you upgrading each system separately, starting with non-production and working your way up to production?
Thanks for your inputs.
As we are planning to use the same VM for a database server during the pre prod and production upgrade. Also same time target Windchill application VM is common for pre prod and production upgrade.
We will follow the std approch as suggested above to do complete upgrade, Wipeout everything and go for next production Upgrade.
Thanks
Vivek
