Website migrations are a naturally occurring and common event on the internet as companies upgrade (or change) their platforms, rebrand, or merge with others.

This is why it’s important to have a defined, phased approach to website migrations, and using past experience (and learnings) to continuously improve and refine processes.

Collectively at SALT.agency, we’ve handled hundreds of SEO migrations, ranging from 10,000+ SKU e-commerce websites through to companies rebranding/merging with others — so we’ve learned a thing or two along the way.

What is classified as a website migration?

To understand the scope of a website migration it’s important to classify it so you can assess the number of variables and level of risk involved.

This is because there is no such thing as an off-the-shelf website migration.

Websites (even small ones) can have complex tech stacks due to years of bolt-on changes and modifications.

These can vary wildly, so imagine how many variables and variances there are between enterprise websites!

Through classification and accurate scoping, you can remove large amounts of ambiguity, as ambiguity equals risk.

From experience, some of the common “migrations” we’ve encountered include:

  • Changing your website architecture and/or URL structure.
  • Moving from HTTP to HTTPS.
  • Changing hosting providers.
  • Moving to a new CMS or platform.
  • Changing domain names/rebranding.
  • Merging websites/companies.

These are top-line migration categories, as within each one there can be a multitude of variances.

A single “migration” can also encompass a number of these changes at the same time; multiplying the risk factor.

Where things go wrong

Website migrations — no matter how carefully you plan and put in place contingencies — sometimes go wrong and you see traffic declines.

But there is always one variable in the migration equation that you cannot control, and that is Google.

Sometimes Google can take a while to process changes in URLs even when redirects are in place. Other times an update may be pushed at the same time as the migration. It is, unfortunately, one variable that can’t be catered for, regardless of how much you try.

Source: Lingvistov.ru/doodles

Outside of Google, the root cause of most migration failures can be traced back to one of the below pain reasons:

  • The migration was conducted without consultation or a thorough enough framework suitable for the scope and risks of the project.
  • Consultation/frameworks are sought after the horse has already bolted and it then becomes a reclamation/salvage project.
  • There is insufficient resource allocated to the project in terms of initial scope, or to make necessary changes once issues have been identified.
  • The timeline is too rigid to accommodate necessary changes once issues have been identified.
  • Change of scope/resource allocations mid-project.

There are of course other reasons, but from experience, these are the most common and as a consultancy being invited late to the party, this often means performing a bespoke organic traffic drop audit.

Frameworking successful migrations

Successful website migrations come from an often unachievable balance of adequate time and resources (from all stakeholders), accurate scopes and objectives that don’t change. You also need a fair amount of luck.

The luck element can’t be created, but it can be influenced.

With adequate data collection, risk mitigation and monitoring, you have given yourself the best opportunity of identifying risk or potential declines earlier on (before they become noticeable to a hellish extent).

This affords you the opportunity to put in place contingencies.

Such a strategy stems from good project management and resource allocation, ensuring that visibility of the site’s migration progress is monitored consistently — and not just when a tool highlights an issue.