Migrating your site to HTTPS can be hard, really hard. There are countless different ways to perform your migration and various tools and techniques that can help you smooth out the transition. This is a high-level deployment plan that should help you to consider all of the aspects that you need to factor in to a successful deployment of HTTPS.


Why migrate to HTTPS?

Because it's 2018 and you really should just do it! Pages without HTTPS might not carry passwords or credit card details but they're still prime targets for passive montoring, advert and malware injection, crypto attacks against other sites like CRIME and just general abuse. We're sending a page to the browser at the other side and we want to be sure the actual page, as we sent it, arrived at the other side. I covered loads more reasons in Still think you don't need HTTPS? so you can head over there if you're not entirely convinced.


The 6-Step "Happy Path" to HTTPS

Troy Hunt wrote an awesome blog post titled The 6-Step "Happy Path" to HTTPS and that's a really great place to get started and outlines a few of the things I'm going to touch on today. There are however a few slightly deeper technical considerations depending on your site that you might need to consider for a migration and those are what I want to dive into today.


Preparation

As Troy covered in the article above the 2 easiest ways to get to a point where you have the technical capability to serve over the https:// scheme properly are either Cloudflare or Let's Encrypt. Your choice between these will be largely based on your own specific infrastructure but if you do have a CA that you're currently buying certificates off for cold, hard cash then I'd highly recommend looking at Let's Encrypt as a drop in replacement.

Once you have the ability to serve your pages over HTTPS then you need to ensure that all of your content is served over HTTPS too. This could be particularly difficult, especially if you have a lot of legacy content like a news site, because a string replace across your entire database probably isn't going to work out too well for you. As Troy mentioned in his article there are two awesome technologies that can help you out here, HSTS and CSP. I've talked before about Fixing mixed content with CSP, I have a CSP Cheat Sheet to help you get started and a HSTS Cheat Sheet too. These two mechanisms are so great at helping you on this migration I even wrote a blog post dedicated to them, Migrating from HTTP to HTTPS? Ease the pain with CSP and HSTS!. The main point is that once you migrate to HTTPS you have to fixed mixed-content and we can be pretty confident we can address that reliably.


Referrer values

Another consideration is external links from your site. Imagine you're a large online directory, like Yell here in the UK, and one of your biggest metrics is how many people or how much traffic you have click through to another site from your own. The site being linked to will track those referalls, most likely, with the referrer header sent by the browser after clicking through but if your now serving over HTTPS and the target site is served over HTTP there could be some considerations there. You'd need to consider setting a Referrer Policy on your site to ensure that just enough information is sent to the target site, or perhaps you don't care at all about this and you want to make sure no data is sent in the referrer header on a scheme downgrade. Only your circumstances can decide what is the correct configuation for you, but you really need to choose one and deploy it.


Flipping the switch

Even with everything done and ready, you can serve over HTTPS, we have mixed content sorted, the referrer policy is set, how do you actually transition from http to https? There are a few different ways you can do this and as usual, each has its own benefits.


The Nuclear option

If you're confident that everything is good to go and there will be no issues you can just flip the giant HTTPS switch to the 'ON' position. You would immediately start serving a 301 redirect to any HTTP request and redirect them to the HTTPS scheme. All of you traffic would immediately start using the HTTPS scheme but this is quite a direct and possibly risky approach, it could be a better idea to dip your toes in the water first.


HTTP/HTTPS hybrid

Another option is to bring the HTTPS version of your site online but not to redirect traffic there at first. This means that most of your traffic will still hit the HTTP version of the site but you can either selectively redirect a subset of your users for testing or just progressively introduce HTTPS links to your site in things like emails, social media etc... This way if there are problems they will only be exposed to a small subset of your visitors and you have time to rectify them before the impact becomes too big. There are SEO considerations here, and I'm no expert on SEO, but you will have your site available at two different URLs for a short period of time but the canonical version will still be HTTP.


HTTPS on different paths

For some larger sites different sections of the site could be run by completely different teams of people. Take the BBC here in the UK as a good example. They have bbc.co.uk, bbc.co.uk/news and bbc.co.uk/sports that are all run by different teams, amongst many others. It could be that the /sports section is ready to go to HTTPS first but instead of waiting for the entire domain to be ready to go you could just 301 everything in /sports to HTTPS and migrate only that section of the site. This of course does make it difficult to deploy HSTS, because that works across an entire domain, but it's still a step in the right direction.


Other Considerations

There are a few other things to think about when you are migrating or have migrated your site to HTTPS and you need to be sure you catch them all. Updating things like your Site Map, login to Google Webmaster Tools and setup your site on HTTPS, update social profiles and links, email signatures and anywhere else you can control links to your site to avoid using HTTP.

If you have any 3rd party dependencies on your site you need to make sure they can be served securely over HTTPS or you're going to be stuck with mixed-content or having to live without those dependcies. Things like ads if you have them, anything loaded from a CDN or integrated from 3rd parties etc...