Migrations! Migrations! Migrations! Everywhere you look there seems to be one that is happening. But website migrations are not easy! There are many good migrations being conducted on a regular basis, but you never hear about them. You only hear about those that have not gone as well as expected, sometimes through no fault of those involved. It is easy to jump to conclusions as to what has or hasn’t happened. Silent whispers of they should have done this or that, but sometimes you are in the hands of the search engines. In the remainder of this post I talk about a three stream approach to website migrations, and those key areas that I feel are often missed.
Three main streams to a website migration
A website migration is not just implementing a few redirects here and there, there is so much more to it. Looking at it from a 10,000ft view you could identify a handful of areas that you need to looking into:
- What is the process of delivering the project going to be?
- Which stakeholders are going to be involved?
- What tools are required?
- Why is a migration required?
- What data is needed?
- What are the dangers of migrating?
- What will the testing plan be?
- How do I manage the launch?
- What areas do we need to monitor pre and post launch?
But then you look further into these areas (shown below) and start to realise the scale of the task at hand. But all of this general fits into three work streams:
- Project planning and management
- Implementation and fixes
Having the right approach
Different people have different approaches to conducting a website migration, and one that I see often can be shown below. The problem that I have with this approach is that it is siloed. The project planning and management stage ends before any implementation has actually begun. Then you get a long implementation sprint, where you generally see a lack of management, or interaction with key stakeholders before it is launched. It is then at this stage that the monitoring process starts, but this is way too late. You can’t monitor the changes from launch if you don’t know the history and fluctuations that is likely to have happened over the previous few weeks and months. All this can be changed however if you extend the two of the three sprints. The approach used above ensures that there is a lot more planning and managing of the project in question. One thing that is inevitable in a project such as a migration is change. Whether it is launch dates, project scope and/or key stakeholders, all which needs to be managed in a correct manner. The other main change in the approach, is to extend the amount of time that you are monitoring. Before launch – generally a couple of months – you want to know exactly where you are, traffic levels, revenue, visibility, etc, and you want to know this before significant change is made.
Project management and planning
This stream is key to the entire project running smoothly, not necessarily the results but ensuring the right people are in the know, tasks are registered, planned and executed. But it seems one of the key areas that get missed or give the least amount of investment during what is such a big project.
“He [She] who fails to plan, is planning to fail” – Winston Churchill
Below are some of the key areas that are generally overlooked when going through a website migration, though they are some of the most important tasks.
Get to know all of the key stakeholders including developers
This is one of those things that you say over and over again, but it is one of those that nobody ever does, there is always an excuse. For me this is one of the most important parts of the website migration, and one that needs a lot of time and attention given to. As an SEO or a member of the digital marketing team, you are going to need to get lots of support from a wide range of people within the project team, and the way you do this is by making friends, and early. You could go through the key stakeholders and give them all some kind of importance level, but ultimately your two best friends should be the developer and decision maker. These are the two main stakeholders who will be able to implement all or the majority of the changes that you want to get through. They are also the people that will fight your corner when you want to get something pushed through. This is why it is imperative that you make an effort in getting to know who they are. This is even more important if you are in an agency, you need people on the insider that will fight your corner when you are not there.
Know the reason behind the migration
There has been many occasions where the team involved with the website migration are not really sure why it is happening in the first place.
- Change in brand name
- Change in TLD
- Move to SSL
- Change in CMS
Manage expectations of the website migration
Website migrations are extremely unpredictable. You can do everything right, get all the redirects perfect, the content is amazing, the website is better, quicker and more user friendly than before but you lose visibility. As I have said before, website migrations are not easy so you need to manage the expectations of all the business and the stakeholders. This will ensure that there are no nasty surprises if things do go wrong.
Create a detailed road map
Knowing who will be doing certain tasks, when things will be completed, what is a prerequisite of another tasks, and much more detail is an important part of the planning stage. This will become the central location of the whole project. In the project plan you need to ensure tasks that spans each of the departments are shown so there is a complete understanding of what is happening and all times. Even including the small items such as regular status calls, meetings and holidays. You want to know if someone is going to be on holiday whilst a critical task is being deployed. In projects that I have worked in we have used Asana alongside Instagantt which has created easy to use gantt charts that enables those working in the project to work seamlessly.
Regular status calls & meetings
Alongside getting to know your stakeholders, attending regular project calls is the other most ignored process in a website migration. For some reason, we do not like being involved in phone calls. Maybe we feel that we don’t need to know about other areas of the project, but that’s not quite accurate. It is essential that we are aware of what is going on in other areas of the project. As we know, SEO integrates with lots of different areas, so it is likely that any change could have a potentially damaging impact if we are not involved. Example status call agenda: Business developments – Anything that will affect the project Infrastructure – Server challenges / effects on project Development – Sprint updates / testing SEO – Requirements / challenges / defects Review project plan Launch date Absences – Holidays / leaving business
Implementation and fixes
This stream of work is all about getting things right. Ensuring that the data that has been gathered is accurate, the tasks that have been planned are completed and everyone is working together to move the project along. There are, however, three key items that almost always come to the fore during such migration projects that need dealing with.
Staging site hell
A regular item line in most of the SEO audits that I conduct, is removing the staging site from the index. By conducting one of the following searches in Google, you generally identify your staging website. Go away now (in a new tab of course) and conduct one, is your staging site indexed?
- Site:[insert domain] inurl:staging.
- Site:[insert domain] inurl:dev.
- Site:[insert domain] inurl:uat.
The most frustrating part of this, is it is so easy to solve and therefore prevent. So why don’t development teams do this as part of their process? I am sure some do, but the majority seem not to do so. Anyhow, I digress. The preventions that you need are one of the below:
- Add Noindex tag to all pages
- Make sure the staging is behind a gated access
- Add a disallow: / to the Robots.txt file before launch
- IP restrict the site
From a personal, paranoid perspective I generally suggest doing all of the above. I’d rather do more and ensure that the URL is unable to be indexed than have to fix it at a later stage. One thing to note however, is, if you do add an IP whitelist ensure that you get a proxy setup for any remote workers that you may have.
Working on many migrations, I am often left surprised by the lack of respect that is given to the need to implement redirects. Whether it is key stakeholders, c-suite or developers, there seems to be a reluctance to want to implement them. Now some of the excuses can be valid, with website speed being one provided by the development team. However, if they are not implemented then there is a serious chance that you could lose a lot of the visibility that you have worked so hard to get over time. To help reduce the potential of redirect not being implemented or vetoed by decision makers you can try to be as efficient as possible with the implementation. The most obvious way of doing so is to limit the number of redirect lines used through redirect rules. These can be combined with those inevitable 1:1 redirects to reduce potentially a huge number of lines to a more manageable and acceptable number. Making sure that you have covered all the redirects you need, means that you need to gather a lot of data and therefore using a lot of different tools. When gathering the data for redirects, I generally use the following tools to help me create my list:
- Google Analytics
- Google Search Console
- Crawl of website
- Wayback Machine
- URL Profiler
- Log files
Test! Test! Test!
One of the most difficult parts of the a website migration is testing, and more specifically for redirects. It is often seen that redirects would be put in place without testing, and when launched issues are realised. This is why a robust testing plan needs to be planned and implemented before testing. To enable you to provide an almost identical testing environment you need to have two staging sites. Yes, you read that right, two staging websites. The first staging website should be a copy of the current website that is being replaced, with the second staging environment being a duplicate of the new site. The only difference should be the domain name, as shown below:
- Staging.domain.com – Identical version of the current website
- Prod.domain.com – Identical version of the new website
By having these environments in place enables you to test the redirects that you will deploy on the live environment. You can then see any errors that may or may not have been accidentally made during the implementation. As well as testing for redirects, you want to test for:
- Ensure a single protocol is used
- Sitemaps present and correct
- Zero 404 errors on launch
- Internal redirects are removed
- HTaccess is implemented
- Robots.txt is working correctly
- Canonical implementation is correct
- Structured data has been added
To test some, if not all of the above you should use Screaming Frog and/or Deepcrawl to speed up this process by taking a lot of the grunt work out.
As I mentioned at the beginning of this blog post, you need to begin monitoring your chosen metrics way before the launch of the new website. Different websites will want to monitor and report on different metrics but in general they include;
- Organic traffic
- Organic revenue
- Organic landing pages
- Number of pages indexed
- Bounce rate
- Ranking information
All of these metrics need to be updated on a weekly basis in an easy to understand format that can be distributed to all levels within the business. This needs to be kept up on pre and post migration so that you can easily spot any issues that may rise and allow you to react quickly. So there you have it, a three step migration plan that prepares you for a success for launch. I’d love to hear your comments and questions below or over on twitter @danielbianchini.