This post comes from Alan Mackenthun – Fishbowl’s Technical Program Manager.
We held a webinar recently to introduce our 11g Upgrade Package. One good question was asked a couple times and really merits a better answer than could be delivered in the Q&A session so I thought we could elaborate a bit more here. The question is: Is it better to use the 11g Upgrade Assistant to upgrade in place or to migrate everything to a fresh new 11g instance. The short answer is – It depends:) Another good answer is – Neither.
You may now understand why I wanted to expand on the short answers given at the end of the webinar. I’ll describe the two approaches below as well as a potentially better 3rd way. Whichever approach is selected, the process needs to be well thought out, clearly defined, and tested before doing anything in production.
Migrating to New Instances
Migrating to new instances isn’t really an upgrade, but it is very common. For a long time, this was the standard recommended way that we’d execute upgrades. In this scenario, wholly new instances of Content Server are installed and all configuration, status information, and content is migrated to the new instances. This is necessary if you are planning to change the variety of hardware or database to be used going forward.
Care must be taken to get all configuration migrated. The Configuration Migration Utility (CMU) is used to migrate the bulk of the configuration, but archiver is used to migrate custom table data. Also, many add-ons or optional components require special steps to migrate other relevant information.
The migration of content is typically performed with the Archiver applet. This process is error prone and needs to be monitored carefully. Migrating content in a workflow lies somewhere between difficult to not supported. If a lot of content needs to be migrated, a custom process is likely to be recommended. If the instance manages a lot of content, a migration can take a long time and this needs to be accounted for in the planning. Fishbowl has created the Content Migrator to support the migration of content from one instance to another without needing to use Archiver.
It’s all doable, but migrations are usually more complicated than the other options.
Upgrade Assistant
Use of the Upgrade Assistant allows for ‘in place’ upgrades. The high level process involves:
- Installing WebLogic Server (or the supported container of your choice)
- Installing the WCC installation files
- Then running the Upgrade Assistant pointing to the existing instance of Content Server.
The Upgrade Assistant will take over the existing instance and upgrade the file system and database schema to support 11g. It will disable any older patch components and enable the 11g versions of any standard components. It will also disable any custom components and give you the list of these. For this reason, it is very important to do this in a quality dev environment 1st as it will take time to enable, test, and likely fix any custom components in use in your system. Once the dev instance is upgraded and tested, the production instance is upgraded in exactly the same way, but after the Upgrade Assistant finishes, you can install the upgraded components from the dev instance, restart and do your final system testing before turning it back over to your users.
The benefit of leveraging the Upgrade Assistant is that you don’t have to migrate the configuration and content to the new instance. If you aren’t changing your search index (Verity is no longer supported in any way), you don’t have to immediately rebuild your search index either though it is highly recommended that a rebuild be completed after the upgrade.
The downside of this approach is that you are directly working in the production instance. There is no way around significant downtime and if something goes wrong you’re under the gun to rectify it immediately or you have to restore everything from tape and try again later.
Copy & Upgrade in Place
The 3rd options is to make a copy of the production instance and upgrade it in place. As long as you’re not changing the variety of operating system or the type of database, this has worked well for us. If there’s a lot of content, the copying itself can take a fair amount of time, but then the upgrade can be executed on new and refreshed hardware and the production system need only be down while the copy is being made. After the copy, the old Content Server can be restarted in read only mode until you can switch over to the new system. Sometimes this is only done to make a new dev or stage instance if the old instances were out of sync. After having run the upgrade in those two environments, customers may be comfortable running the production upgrade in place.
If you’d like us to assist you with an upgrade to WCC 11g we’ll ask that you complete an upgrade questionnaire. We put this together to most efficiently estimate the level of effort for an upgrade. Some of the questions included on the questionnaire help us determine which of these approaches might best fit your needs.
If you’d like to see what we think, please email any of us here or [email protected] and request a copy of the upgrade questionnaire.
