As 2018 is coming to a close many people are planning their projects next year and an upgrade might be part of it. The good news with the latest SDL Tridion Release, named ‘Tridion Sites 9’, is that the word ‘Tridion’ is back in the name! OK, all kidding aside, the other good news is that little has changed in the product since Web 8 and Web 8.5. Meaning, if you’re thinking to upgrade from 8.1 or 8.5, expect few hidden bumps or issues. However, the bad news is also that little has changed since Web 8.1 or Web 8.5. So, if you were expecting to see some of the suggestions on the SDL Ideas Site, then you’ll have to wait a bit longer. One long-standing request that is implemented (I’m aware of it since at least 2007) is image cropping and re-sizing within the backend GUI. Yay! And if you’re curious what’s coming out in 2019 and beyond, watch the Tridion Developer Presentation by the SDL team about the GUI vNext here. For a complete list of the new features in SDL Tridion Sites 9, check out the release notes. Despite the good and bad news, the fact is that it is important we keep our software current, as it both gives us the latest and greatest version, happier users, a larger version number (just kidding!), and also longer support. In this article I will give a list of some of the things to consider when upgrading.
The upgrade process is usually somewhat confusing, as the architecture of Tridion in an enterprise setup can be complex and a bit overwhelming.
I tend to think of it from a bird’s eye perspective, and divide the architecture into 3 large pieces: Content Management, Publishing, and Content Delivery. These pieces all affect various parts of the organization and the ways they work – and this is something we should consider as part of our plan when we upgrade various mission-critical pieces to the new version.
Before we begin, if you’re using a web framework such as DXA, then you need to check if the version of DXA is compatible with the version of the Tridion upgrade.
First, I always suggest to start with a ‘sandbox’ server, which can be a copy of the Development environment. This is a place where if we make any mistakes, we won’t do any harm. We try to get as close to production as possible, but sometimes we might not have various components such as load balancing configurations or other third-party systems. Regardless, we try our best to have a fairly decent environment here that resembles production. We should also have all of our latest Templates, Event System Code and other Tridion extensions in this environment. This is where most of our risk lies, and where we will want to have time and a safe place to try the old code in the new version – to fix any potential issues that pop up. Once we analyze and try out our customizations in the Tridion environment and prove they don’t break the newly upgraded system, then we can relax that most of the risk of the upgrade is handled.
In the sandbox environment, most of the customizations and extensions in the Tridion system are in the CMS or the Publishing side, although many people also extend and use the Content Delivery APIs as well (using Java or .Net).
I suggest we start with the Content Manager server upgrade, as it is fairly quick and fairly painless, and the CME / DB usually upgrades without any major issues. This then allows us to test our Templates and backend customizations. Next up would be the Publisher upgrade, and again it is fairly painless. Finally, we would upgrade Content Delivery, and the Micro Services. This is a bit more time consuming and also can be trickier, given the number of moving pieces and numerous configuration files. However, if you’re upgrading from 8.1 or 8.5, your experience should be fairly smooth, since as I mentioned above, little has changed… Please refer to the SDL Docs Upgrade documentation for more details.
The first thing we want to try after we upgrade is to Publish. This tests that all the layers of the architecture are working together and we can deploy content changes. If the publishing doesn’t work, common issues are a configuration issue in the Deployer_conf file (check the Database settings, etc) or that the items hang in the Publishing queue and might need a Publisher restart. Once items are publishing you can move onto testing Publishing other pages, and page types. We usually suggest to try to re-publish an entire site, or sites, if it is possible within your environment. If not, then select a subset of pages which represent the main page types and publish them to be sure the mechanism works for these as well.
Next we would want to look at any advanced extensions or customizations. I would suggest that someone who has been a member of the Dev team for a while make a list of the customizations, the locations of the files, what the customization does, and how to test it. This is very helpful not only during the upgrade, but in the future for testing as well.
If you’re using the excellent Alchemy Framework, make sure to check if the plugins continue to work with the new GUI, and also check to see if a new version of Alchemy is out and you could upgrade to take advantage of new features and compatibility. Other common things to check are ‘Custom Pages’, Event System code, GUI Extensions, Core Service apps and templates that call external services.
Assuming everything still works, then we would want to update the Event System, GUI Extension, and Core Service apps to reference the latest Tridion Sites 9.0 DLLs instead of the 8.1 or 8.5 ones.
And, again, test everything to make sure that nothing breaks, and celebrate that this step in the upgrade has gone well.
Next up would be to look at any Publisher / Deployer customizations, as it is common to publish content to various search engines or databases. Usually this code is written in Java, and with a bit of luck you will have a Java developer handy that is familiar with the code and Tridion, and can update the app to use the latest Tridion JARs, and test it on his local development machine. This sometimes can be a but tricky if the developer doesn’t know Java, or doesn’t know Tridion. So, if you have one of these types of extensions, then before the upgrade begins you might want to confirm the availability of the Java developer to support your team. He or she will not need to help out in the above steps. Also, the upgrade can be done on a local development machine and tested with Deployment Packages, and in that way the Java dev can use their local IDE such as Eclipse or NetBeans to debug the code.
Finally, if we are using any Content Delivery APIs, we would want to upgrade our WebApps to take advantage of the latest features. This includes both .Net and Java environments. The Tridion installation media includes the latest DLLs or JAR files, and we would then need to update our WebApps and re-compile them to take advantage of the latest version. If you have some automated tests of the live website and it’s possible to run them here, that would be great and very helpful. Also, it’s a good time to check some basic performance numbers, if possible.
If you’re using a Web Framework such as DXA, then you might need to also upgrade that to the latest version to be compatible with the latest Tridion version. This would be part of the ‘upgrade WebApp’ step.
At this point most of the article and attention has been on customizations and the ‘risky’ part of the upgrade. I haven’t discussed TopologyManager or MicroServices in detail, as they already exist in Web 8.1 and 8.5 and should continue to operate in more or less the same way, without any major changes. If you’re upgrading from Tridion 2013 then you would need to plan a but more time to handle the MicroServices and TopologyManager sides of the upgrade.
So, we come back to our original question: Why Upgrade? It’s a good one and it’s sometimes hard to answer. With large software packages that rely on many external systems (Database, Server, etc) it is good that we maintain them and keep them all in alignment – so they can all operate efficiently and also as expected. We also stay on a same version as other customers, and with that, we benefit from any hotfixes or service packs that solve open issues. Finally, we help provide our end users with the best that Tridion Sites has to offer at this point in time. I’m a big believer that we can always do better, and if you’re using an older version of Tridion, probably the business and users would be happier and more efficient using the latest version of the product.
If you need support or help for an upgrade please feel free to contact me at email@example.com