The Crazy Thing About Website Migrations
I’ve worked across tens, maybe even into hundreds of website migrations in varying capacities, and I’m always surprised that despite the seemingly endless amount of migration resources available, some things always seem to get missed that could have very easily been avoided. The reasons for certain elements getting missed vary, but I feel they can be categorised into:
- Poor planning
- Poor communication
- Poor project management
I’ve tried to cover some of the most common migration pitfalls that I’ve encountered in this episode of the Internet Marketing podcast and the accompanying podcast show notes below. At some point later this year I’m also hoping to expand our Ultimate SEO Migration Checklist to include checklists for analytics, paid media, social media, email marketing, UX and customer service.
This podcast is my starting point to help kickstart that process.
Feel free to ask me any migration questions via email@example.com or hit the live chat button >>>
Questions to ask clients during PRE-MIGRATION planning
It was only in preparation for this podcast that I realised the easiest way to break down the questions was using the classic WHO, WHAT, WHEN and WHY framework.
Start with WHY
Before I start, I also recommend you check out the book, Start With Why by Simon Sinek. The book has nothing to do with website migrations, but the content provides a useful reminder of where we should start with all marketing activity.
This question when it comes to website migrations is so simple you might want to punch me for including it. I promise I am not intentionally patronising, but it’s missed SO OFTEN that I feel I have to spell it out…
Why are you planning on migrating your website?
If you’re involved in a website migration, you need to understand the ROOT REASON behind the project because everything is underpinned by the root reason.
These reasons can include:
- Someone has seen a competitor website that looks prettier and now they’re jealous
- Someone is under pressure because of poor marketing performance and has decided that the website needs changing
- There is a company rebrand happening and the website will need updating
- Acquisitions and mergers mean there are new websites to manage or merge
- A CMS change is required because of security issues, usability issues or because it’s too costly to use
- A domain name change is happening because of a branding or SEO decision
- New ways to improve UX have been identified or are being experimented with
Sometimes, the reason for changing or launching a new website is a mix of the reasons above.
Why is this simple question so often missed?
From my observations, when the word “website migration” is first spoken, people move into sales mode or tactical mode too quickly. The focus rapidly shifts from why to how.
The two questions I find most useful to ask in respect of when are:
- When are you planning on migrating?
- When did you start discussing this migration?
The reason the 2nd question is so important is that it will give you an insight into truly how far along the journey you are and how seriously committed a business is to the migration.
The two questions I find most useful to ask in respect of who are:
- Who else are you working with? For example, for design, development, branding, copywriting etc.
- Who are the key contacts that are managing the project?
The key here is question #1. You need to know the full scope of a migration beyond the work or channel you’re contracted to. This is crucial as it’s often tunnel vision that’s the critical problem when agencies are working in a silo and not communicating during a migration.
There’s a bad habit, particularly in SEO, of using the word migration as a catch-all term for almost any design or development change. On the flipside, I’ve also seen it on occasions where marketers downplay a migration (such as a full CMS switch) by assuming that their client is just making a small design change.
So, the question to ask here is…
What, specifically, does this migration entail?
Migrations can range from:
- Domain name switches
- Server switches
- HTTP to HTTPS
- A move to a mobile responsive site
- A change in CMS
- Acquisitions or mergers that require websites to be consolidated
- Company rebrands
- Page level template changes
Again, sometimes it can be a combination of all the above.
Include These Elements in Your Next SEO Migration Plan
As noted in the intro, we’ve produced one of the most comprehensive SEO migration checklists, but there are still several some phases I see that are frequently missed, plus some new checks you should be adding into your migration plans when moving from HTTP to HTTPS.
The impact of rebrands on SEO
In short, the impact that rebranding has on SEO is often underestimated.
Rebrands will always result in copywriting changes. An entire site-wide rebrand means large-scale copywriting changes. Copywriting is time-consuming.
There’s no point in launching a beautiful new website if you lose your traffic in the process.
Record your pre-migration SEO benchmarks
Don’t leave migration success in the hands of opinion.
To truly judge the success of a migration when it comes to SEO, you need to produce a post-migration report that details key post-migration metrics against pre-migration benchmarks.
When it comes to SEO, you’ll need to consider metrics such as:
- Organic conversion rates
- Total indexed pages
- Total traffic generating pages
- Mobile and desktop page speed scores
- Mobile friendliness and UX checks
- Rankings on mobile and desktop
An Important HTTPS Consideration When Changing Development Agencies
Aleyda Solis has an awesome HTTPS migration checklist which details maybe 95% of what you’ll need to consider as part of the SEO side of HTTPS migrations.
However, we had an interesting scenario with one of our clients recently where they were changing development agencies as part of a website migration. The client was already using HTTPS, but the development agencies hadn’t communicated about the transfer or set up of the SSL certificate from the old server to the new one.
On launch day, this mistake proved fatal as it was discovered that the new SSL certificate was going to take 48 hours to implement, causing our client to have to delay the new website launch.
The lesson here is simply not to assume that if during a migration you’re also switching development agencies, they will have discussed the transfer or configuration of SSL certificates.
What to do with paid media during a migration
Often the assumption is made that all a paid media team/person will need to do during a migration is update the URL locations for ads to the new destinations.
This is just a tiny part of potential paid media work that needs to be undertaken during a migration.
Rebranding changes will likely mean changes to ad-copy, imagery, keyword and audience targeting. From an AdWords perspective, some of these changes will also impact your quality score. Something else to think about…
Plan for the worst-case scenario. Have your SEO team discuss important traffic generating keywords that might be at risk during a migration and pre-prepare your PPC ads to cover those keywords if ranking fluctuations are more volatile than anticipated.
Don’t forget these quick analytics checks…
- Remember to configure a separate Google Analytics property for testing on a staging server.
The simplest way is to use GTM environments.
- Exclude agency IPs from the site. (During migrations you will have lots of agency and staff visiting your site, so you should make sure they are excluded using IP filters).
- If switching to HTTPS, make sure you relink your Google Analytics Property to your new HTTPS Google Search Console account.
- Check Analytics code has been added to all pages on launch day. Here are some tools that will help you do this.
- Update the default URL in Google Analytics Property settings when moving from HTTP to HTTPS.
UX Considerations during a Migration
If you’re updating your website because of UX reasons, industry changes or because of a rebrand, I’d suggest one of the best ways to ensure you’re on the right track is by getting impartial feedback from your customers (perhaps via Beta testing) or through using services like UserTesting.com or WhatUsersDo.
It’s also important on launch day to have several members of your team or agency reviewing the live website for any bugs and to have a system to record these bugs. The simplest solutions are probably to use a Google Sheet or maybe a Trello board to record any issues that are found.
I’m also fond of the Chrome extension “UX Check” as it provides an easy way to highlight individual elements on a page and to export all your bugs and recommendations into a neat Word document during a browsing session.
Finally, remember to tell your customers about your new website
It’s crazy the number of times I have seen a new website launch and a business forget to tell their customers that they’ve launched a new website and WHY they’ve launched a new website.
At very least, send out an email to your customers. Pin the news to your social accounts.
Tell your customers how they can report the bugs and issues that they find on your website, and perhaps even reward them for doing so.
Lastly, make sure your customer service and social media teams are also fully aware of the launch of a new website and how it might impact customers. Running a session with your social and customer service teams ahead of launch day will allow them to prepare for any potential questions that are likely to arise.
Your customer service and social teams are also likely to be using social media management tools that will allow them to filter and segment conversations containing specific keywords, meaning they can prepare filters in advance for questions relating to potential migration issues with filtered keywords like “new website”, “problem with”, “how do I”, “what happened to” etc.
My number 1 tip when it comes to website migrations
If you’ve decided to undertake a migration, it’s your responsibility to document and tell people the root reason behind a migration.
If it’s your client that’s just told you they are planning a migration, it’s your responsibility to find out the root reason for the migration. You’ll also be able to plan a lot more effectively if you think about the migration beyond the channel of work that you’re contracted to.
If you have something to add to this article or you have any questions about migrations that you’d like to discuss with me, hit the live chat button on this screen or email firstname.lastname@example.org.