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.
- Create a temporary upgrade server and use it for all upgrade passes (including production). I typically install the DB software on this server and tune it for upgrade performance.
- Clone/rehost the upgrade source from the production (11.0) environment into the upgrade server. You don't need files in the vaults, just the file vault folders.
- Install the upgrade target (12.1) into the upgrade server and configure it as required for upgrade.
- Create a restore point for the upgrade in the upgrade server. I use robocopy to create a backup of the Windchill 12.1 target installation. After each upgrade pass I can reverse the robocopy to copy from the backup.
- Install your production (12.1) system with all components (SOLR, WVS, replicas, etc.) and tune it for production use. All validation testing will occur in the production 12.1 system.
The iterative part is...
- Create a restore point for the upgrade.
- Get a fresh copy of the 11.1 production DB for the next upgrade.
- Prep and run your upgrade pass and follow post-upgrade steps.
- Rehost the upgraded DB into the future 12.1 production environment for performance and validation testing.
- Reset the upgrade environment to the restore point. Make any necessary permanent upgrade changes and refresh the restore point.
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.