Thinking about infrastructure for that upgrade

Following on from my previous post about things to think about if you're new to upgrading a Sitecore project in your development environment, there was another side of the issue of upgrading I wanted to point out – some of your deployment choices...

You need to plan for handling infrastructure in your upgrade deployment url copied!

While you're busy working on getting your code and data upgraded, you will need to do some thinking about how you're going to go about deploying the results of your work. Broadly speaking there are three approaches you could take:

1. Applying the upgrade process to the other instances
   You've already gone through an upgrade in development – so you'll have a pretty good idea of how to achieve this. But this is generally my least favourite option. The key issue is that it probably involves downtime for your production site, since you're making a complex set of changes to the servers in place. You may be able to do things with copied content databases and load balancing to avoid that – but it involves extra work. The other issues are that there are likely to be some differences in the process required for other platforms that could trip you up. For example in dev you're unlikely to be worrying about CD servers with no connection to the Master database. You also have to take care to tidy up any left-over out-of-date files or backups that the process creates. And in the event of issues, rolling back requires restoring backups.
2. Deploy a new instance on the same infrastructure
   The middle ground approach is to re-use the servers you already have and add new databases and IIS sites to them so you can run the old and new versions in parallel. This is a better option if you're working in a scenario where new server resources aren't easy to obtain, but this does rely on you having sufficient disk, RAM and CPU headroom that you don't cause performance issues while you have two sites in parallel. This approach can mean you don't have to disrupt your existing site, and it doesn't require an extra infrastructure to be deployed. Plus you get to do a deployment of a fresh instance of your new target version, so there's no mess left lying around from an upgrade process. Once your new site is set up and tested, you can swap over using a technique like changing where the DNS points to or the way your load balancers route traffic. You also have the opportunity to run the old and new versions at the same time, so that you have a fallback position if an unexpected issue arises with the new site – just switch back to the old one.
3. Deploy a new instance on new infrastructure
   Finally, if you're hosting your site in an environment where getting new servers is easy (Like Azure for example), then just spinning up a new set of servers is usually the easiest approach. This has all the benefits of the previous option, but without the risks around available resources when you have multiple instances on one server. Plus, by having complete separation, you don't have to worry about accidentally disrupting the old site. The down side is that you have to pay for extra infrastructure while the two sites run in parallel, so budgets may constrain the timescale for this. If you've managed to go full dev-ops in your work then this is definitely the right way to go. And even if you haven't, this is still my preferred option where possible.

Edited to add: As mentioned in the comments below by Nick, "blue/green deployments" (or "deployment slots" as Azure names this approach) are another mechanism to consider if your infrastructure supports them. It's kind of similar to option 3 above, but the extra infrastructure is automatically available as part of the hosting

But there can be some gotchas to consider... url copied!

If you're not able to adopt option 3 above, then there's one scenario you need to be careful of: Where you have a 3rd party service which need upgrading too, but doesn't support multiple versions running on a single box.

Probably the most likely candidate here that may challenge your Sitecore upgrade is the Coveo search service. The Coveo for Sitecore module's version is closely tied to both your Sitecore version and the version of the underlying Coveo search server. That means you don't have much of a choice about upgrading this aspect of your site when you change Sitecore – but it can cause challenges because it relies on a Windows Service, and doesn't have options for a side-by-side install.

In this scenario you don't really have much choice but to find somewhere else to deploy a new version of this service too. If you can arrange an extra server for the time you have both the old and new versions of your site, then this is the best approach. But if not, a potential fall-back position is to install the new version onto another of your existing servers. That's not really ideal – but may be the only choice available if your infrastructure is constrained for some reason.

And one other thing: url copied!

If you're going to use DNS to switch from an old version of your site infrastructure to a new one, don't forget to reduce the time-to-live value for your DNS entry in plenty of time, to ensure that when you make the change-over your users see it quickly. ↑ Back to top