Sitefinity is a powerful CMS indeed and depending on its current version and custom implementation upgrading can be a seemingly daunting task. This post will reveal the steps and a few hints to make the upgrade process run much smoother than you thought.
As Platinum Partners with Telerik, we find ourselves producing and shipping all manners of CMS driven applications. Sitefinity is a robust and client-centric CMS offering developers the opportunity to craft a powerful website with little customization out-of-the-box. There is an expiration date though. Like every great car, general maintenance and new features will be desired by its owner and it’ll be time to upgrade. The good folks at Telerik are constantly improving Sitefinity so that clients and developers can better deliver technology and information to the world. But I know what some of you who’ve worked with content management systems are probably thinking:
It’s true. This isn’t a walk in the park, there is no upgrade “one-click-to-rule-them-all” button. But it’s certainly do-able and highly attainable. So let’s get a game plan going.
Back that app up!
Before proceeding with the update process, always back up the production code and database. There’s always the small chance you need to start over recover lost items (a rarity albeit). Keep in mind that you’ll be pulling down production and upgrading locally and replacing the old production with your shiny, new upgrade. Be sure to give a heads up to your clients and fellow developers that this will be taking place as you’ll want a “Hands-out” of the production CMS to avoid any content loss. Due to the significant database and configuration changes, this is a must. Might I suggest a new branch for your code base as well…
Get the latest manager and get Crackin’!
Getting the latest version manager is a cinch and can be pulled down after logging in to your Telerik account here. The first thing I suggest doing is creating a test project with the new manager. This will allow you to easily compare files later to make sure nothings is missing or reconfigured wrong.
Once you’re ready to dive in keep some of these articles in mind (and probably open):
The General Upgrade Documentation is a must. The document lays out the basic steps using the project manager for upgrading your Sitefinity site. The process is rather auto-magical to start, once you’ve deleted out the dlls bin directory the manager will do ‘its thing’ prompting you if you want to update the web.config automatically (which you do). Once the code update is complete the browser should open and begin the database re-configuring process. This can take several minutes depending on the version-hop as its adding and reforming many of the database tables. Eventually, hopefully error free, the site should announce its completion and the easy part comes to an end.
I have Errors!
There are a number of issues that could have caused errors with the initial upgrade process. Here is a few I’ve commonly seen:
- Missing Dlls. The most common for me thus far. This is usually solved by pulling in any missing or updated dlls from that test project created earlier.
- Reference or Dependent Assembly Errors. These are common as well, especially if your project was updated before. Make sure the web.config has the proper assembly references to the new version, not the previous version.
<dependentAssembly> <assemblyIdentity name="Telerik.Sitefinity" publicKeyToken="b28c218413bdf563" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="7.3.4210.0" />
- Clear out the bin folder first! This is how conflicts generally appear.
- Configuration Files. These should have upgraded themselves but if they are marked for the previous version be sure to set them for the latest.
- Custom code breakage. This is a tough one. I find this usually happens due to code referencing common older dlls that have different methods then previously utilized.
Time to Get Thorough
So if you’ve made it this far, the sites up and running and seemingly without errors. The worse thing that could happen now is you publish to production without thoroughly sweeping the site. You need to CHECK EVERYTHING.
- Custom Code
- Ensure forms are still functional
- Email functionality is still in tact
This is rarely an issue when hopping just a few versions but we’ve found older code bases need “re-application’ of new code and widgets to the page. Forms controls, for instance, have been remodeled several times over the years and you may need to update. Here are a few key things to keep in mind:
- Drop new widgets if others are outdated. This is an obvious issue to spot, as it generally turns your page into error screens.
- Some modules may need to be re-installed. This I see commonly in libraries and will need to be unloaded and reinstalled. In most cases you won’t lose data, but it doesn’t hurt to do a backup.
- Settings are different/reset. This is fairly common with big hops. Take some time and peruse through the Module and Advanced Administration Settings.
- Forms & Security. You may have jumped so far from an older version you now have claims authentication instead of Forms authentication. Check out this documentation
I Survived, Now What
Setup the good stuff and go live! Surely you’re ready to get started with your new features and you’ll want to go live as soon as possible. I’d suggest keeping your old implementation around for bit in case something got missed or perhaps an item in staging didn’t quite make it to production yet.
Final Words To the Wise
Stay calm and plan plenty of time to upgrade. It’s rarely a ‘fast’ thing and depending on the obstacles you run into, it may take several hours.
- Plan ahead of time
- Make sure the client is hands-out
- Make backups
Follow the plan and you will find yourself in the seat of a shiny-new CMS ready for the world.