Migration/upgrade WebLogic can happen to any application environment which demands HA, more performance for their application. It could be WebLogic pre 10.x to another version WebLogic 10.3.3 (11g) it is known as upgrading WebLogic domain. Some times the migration process could be taken place, Solaris machine to zones. The basic changes are required in the migration process are listed as following:
To creating a domain template you can use pack.sh/cmd script, in Windows environment you can use Domain Template builder, final option is our WLST. To open a domain template for domain creation you have to use readTemplate('absolutepath/wls.jar'). To make changes to newly configured domain or extending an existing domain, you can use readDomain('/absolutepath/newdomain'), you can do the changes as required and give the updateDomain() and followed by closeDomain() WLST commands.
On a single machine there can be many domains could be configured. For all the domains you can use common installation. When the WebLogic 11g domain migration happening, by default VM argument contains -client JVM, As recommended, if you need to change it to -server JVM this you can do the change it in commEnv.sh
Updating startWebLogic.sh There could be application specific dependent jars must be in the CLASSPATH, some applications demands that library files must be loaded before weblogic.jar then you need to use the PRE_CLASSPATH need to updated
update in startManagedWebLogic.sh
In multiple Server in multi-clustered environments established on multiple machines, You can assign the values for the WLS_USER, WLS_PW so that Managed servers can start smoothly. If you don't updated the admin server details using WLST then you need to update them manually in ADMIN_URL positional parameter.
The JTA timeout There could be chance of insufficient transaction timeout, by default it is defined as 30sec. As per your application need change it.
Global transaction enable. why we need to change this? what is this Global transaction means?
A WebLogic cluster can be shared among different domains? no it should not. we need to ensure there could not be any conflicts between domain cofigurations while replicating the config repository.
In DR environments the middleware admin needs to ensure that application code and its dependent properties must be synchronized with actual production environment.
moved to different location
Application deployment path issue