In this blog I want to share steps that I see as necessary to ensure that Tridion upgrade tracks succeed, based on my experience with two Tridion upgrade tracks in the past few years. The fist upgrade track was from Tridion 5.3 to 2011. The second upgrade track was from Tridion 2011 to 2013. I will try to draw a comparison between the two tracks to illustrate my thinking.
1. Scan the existing system
First, assess all items which are deprecated, dropped, not forward compatible or which you want to revamp. Make a plan to deal with and fix any issues found.
2. Assess Tridion content manager customatizations
Review all your Tridion content manager customatizations. Make sure you have a list of all GUI Extensions, DLLs placed in the GAC, custom Mediators, any custom URL extensions that reside on the content manager server which are to be used on Schemas, the Format Area Styles file, the TcmXHTML.config file, custom pages, etc. Make a plan to address them and fix any issues found.
3. Involve all stakeholders
Communication is key to success. Make sure everyone who has any interest in Tridion Content Manager is involved from the start. Think of all involved, from Developers, Editors, DBA’s, Business Users, IT Operations and so forth. Tell them your plans and timeframes. Seek their feedback. Hold regular stakeholder meetings to keep teams in the loop on upgrade progress.
4. Plan your implementation
Make sure you have a sound development, test, and acceptance environment scenario for the implementation phase of the upgrade. Do a test upgrade first in a development environment, to avoid disruption in production if your upgrade fails for any reason. Of course, always follow the official Tridion installation/upgrade documentation.
Basically, the steps are:
Upgrade the database(s)
For the upgrade from Tridion 5.3 to Tridion 2011, we did this in phases. First from Tridion 5.3 to Tridion 2009, then to Tridion 2011. Tridion has tools to help this process located in the installer/database folder. Always make sure to have a backup before running these upgrade tools. Don’t forget to upgrade the CMS database, the broker databases and your outbound email database, if you use them. For both the upgrade from Tridion 5.3 to Tridion 2011 and Tridion 2011 to 2013, Tridion tools made this step almost a no-risk step.
Upgrade the CMS server
For the Tridion 2011 upgrade, a clean install after an uninstall of the old Tridion 5.3 installation was the best way to go. An upgrade would have left me with too many 5.3 version dlls and extraneous and unnecessary things on the file system. In this case, there was a legacy Visual Basic 6 event system, which I managed to keep running with the legacy event adapter.
I followed the same uninstall-clean install process for the Tridion 2013 upgrade. Here again an upgrade would have left me with so many old dlls that it made sense to choose a clean installation.
Upgrade the broker and deployer
For both the Tridion 2011 and Tridion 2013 versions, no installer is available. You must manually copy and paste the right Tridion and third-party jar files. The old cd_broker_conf.xml configuration file from the Tridion 5.3 version is replaced by a new cd_storage_conf.xml file for both Tridion 2011 and Tridion 2013.
Fortunately, the broker API is still fully backward-compatible. So the Tridion 5.3 version broker calls still work for both Tridion 2011 and Tridion 2013.
Legacy code is supported for both vb-script templates and the old TOM-based event system. All vb-scripts are still 100% supported in both Tridion 2011 and Tridion 2013. The legacy event system (old TOM, Visual Basic 6) is supported as well with the legacy Events Adapter for both 2011 and 2013. Also the logging configuration has changed from log4j in the Tridion 5.3 version to a new logback logger in 2011 and 2013.
Above all, make sure you have a proper testing plan. Involve all authors/editors and webmasters.
5. Make a roadmap for Go–Live
Prioritize everything that needs to happen, who will do it and by when. Make sure you have hard dates here and list any prerequisites for sign off. Also include dates for testing, content and publishing freezes, handovers and any key milestones. Quite often, backups will be the responsibility of the DBA team, so it is easy to forget them, but they are critical. Make sure you ask the DBA team to do this and verify the backups were successful. The safest way to go is to have a preproduction environment so everything is tested overall before going into the production phase.
Tridion’s databases need maintenance scripts to be run periodically in order to optimize indexes, etc. There are also tweaks to the deployer and publisher that can massively affect performance. Find out if any of these have been put in place and make sure they are well documented.
7. Go Live
There are three keys for a smooth go-live. The first is to follow the go-live roadmap in detail for both the timing and resourcing involved for each and every step. The second is communication. Make sure everybody who has a stake in the go-live is involved and has a complete picture and understanding of all steps roadmap. Keep a list of names to make sure everybody is kept up to date for each and every step. The third key is to have a fallback plan in case something goes wrong. (Backup early and often.)
For both upgrade tracks, Tridion 5.3-2011 and Tridion 2011-2013, the generic steps to follow were the same.
- Assess existing system
- Assess Tridion content manager customatizations
- Involve of all stakeholders
- Implement the upgrade
- Map go-live processes
- Go live
Generally, as far as my personal experience, the database upgrade scripts are the most important step. Then, a fresh install of the CMS and configuring it to the upgrade DB and CMS backend should make it work. By installing the so-called legacy pack even all vb-script templates, and a large part of legacy event systems and custom pages should work. The real challenge is often in making customization code, e.g., legacy event systems, work properly. This applies to both upgrade scenarios presented here.