7 Steps to a Successful WebCenter Sites Upgrade
It’s been over a year since Oracle released WebCenter Sites 11g. Adoption is starting to accelerate as users of FatWire Content Server have had time to evaluate their options and assess the relative strengths and weaknesses of Oracle’s update.
So we thought it was high time to publish our thoughts on the essential steps towards a successful WebCenter Sites upgrade.
A good plan isn’t specific to upgrading WebCenter Sites but is still the fundamental pillar for a successful upgrade project.
A good upgrade plan should identify the following phases. They don’t all need to be heavyweight and long-winded but you should make sure that you’ve covered your bases
- What benefits will the upgrade bring?
- Which problems does the upgrade solve?
- Will the upgrade cause any new problems?
- What work needs to be done to implement new features?
- What work needs to be done to preserve current features?
- What sort of test coverage do we need?
- What has changed in the product from an end users perspective?
- How will these changes affect how they perform their day to day work?
- When is the best time to perform the upgrade?
- Will you need an outage and if so for how long?
- What happens if something goes wrong? What’s your rollback plan?
- Post upgrade support
- Who does a user talk to if there’s something they can’t work out how to do?
2. Get to know the new features under the covers
How many times have you discovered that the new functionality an upgrade promises isn’t quite what it seems or that you can’t use it immediately because of the way your current system is designed or implemented? Make sure you do your homework and understand at the technical level what the impact of new changes in the product will have on your system.
We’ve written a post on the new features in WebCenter Sites 188.8.131.52.0
3. Understanding your key business user functionality
Make sure you know which functions of your system are used most by your users and which are fundamental to the ongoing functioning of the business.
If you don’t already have it, think about performing an audit of the functionality the system provides. This information can provide the contract between the business and the developers performing the upgrade.
4. Providing a safety net
Once you’ve got a handle on your current functionality and the impact of the new product upgrade it’s time to get your developers some protection. Whether it’s manual or automated you should make sure you have some test coverage of your key business user functionality
One of the big barriers to upgrading earlier versions of the Fatwire product was how customisations to the product itself behaved. Each change made to the product needed to be assessed against the upgraded version and a choice made about how to fold it back in to the upgraded product.
WCS 11g has better support now for customisations that survive upgrades but if you’re coming from an earlier version of the product you should make sure that all the changes that have been made to core application are documented and assessed.
This is also an area in which having some test coverage is a boon.
6. Make end user training a core part of the program
Particularly if the changes an upgrade brings are large – and the leap from the old Fatwire product to WebCenter Sites 11g certainly is – you should make end user training a core part of your programme.
It’s easy to forget how disruptive large changes to a piece of software can be. If there’s a new way of doing something within the product or your asking users to change how they think about how their content is structured or produced, then you should provide them with something to help soften that blow.
7. Practice makes perfect
Practice running the upgrade against a ‘real’ environment – the closer you can get your test upgrade environment to the real thing, the more issues and gotchas you’ll catch early in the process.
Make sure the upgrade process is described in step by step detail – each time you practice the upgrade make sure that you follow your own instructions. The first few times you’ll find small errors or additions that need to be documented.
For the real upgrade you want to make the process as easy to follow as possible.