PPC – How to avoid a site migration disaster

PPC - How to avoid a site migration disaster

There are many reasons you might be considering a site migration: introducing a new CMS, changing hosting providers or relaunching your templates and so on. But you need to be careful and proceed with caution, because many things can go wrong. And the consequences can be severe.

At SMX West, Bastian Grimm, CEO & Director Organic Search at Peak Ace AG, and Patrick Stox Technical SEO Specialist for IBM, will be sharing their tips and best practices for executing a successful site migration. Both have performed dozens of successful migrations for a variety of sites around the world. They’ve also seen their share of things going wrong. I asked them to give a brief preview of what they’ll be discussing in their hour-long session at SMX West.

What are the most important things to consider when approaching a site migration?

Grimm: Personally, I believe that it generally comes down to two things: proper, well-in-advance forward planning and attention to detail when executing the migration. However, that’s certainly easier said than done. Last year we performed an overview and again, for botched migrations, the biggest problems either concerned redirects (yes, still!) or were somehow related to broken crawler control strategies (indexing directives, canonicalization issues).

Stox: Ask yourself if you need to make the changes at all. There are a lot of risks in making changes and the more you are doing the more chances there are for something to go wrong. The main considerations are scope and planning, which also includes checking over the migration. You’re going to have to consider brand, personnel, platform, costs, redirects, internal links, structure and much more. It can be a complex process and you really need to make sure the benefits outweigh the risks.

Are site migrations really technically complex, or is it just a matter of paying a lot of attention to detail and process (or both)?

Stox: It’s kind of both. If you understand the technical parts then it’s really attention to detail, but if you don’t understand the technical parts then something you’re not even aware of will probably go wrong.

Grimm: Both, really. Migrations become especially technically complex when a site reaches a certain URL inventory volume, say over 100k URLs. This usually means that there are many different (legacy) systems involved, you’re dealing with CDNs, etc. But on the flip side, we’ve migrated domains with only around 1,000 URLs in total. However, that specific company was almost exclusively ranking for short head keywords; if things went wrong, it’d be equally devastating for them. Generally speaking, a properly planned and executed process is certainly the key to success for any migration.

Over the past couple of years, we’ve seen a lot of site migrations due to moving to HTTPS. What other circumstances would prompt a migration?

Grimm: There’s a pretty broad variety of different migrations – the bigger problem is that the SEO industry doesn’t do well with restrictive definitions: it can be anything really, from hosting, software, domain and template migrations to content, design or even strategy migrations. Somehow, all of these factors influence SEO, some more – some less.

Here’s a slide from my presentation that summarizes various migration types.

Stox: Domain changes usually happen with re-branding or acquisitions. URL changes can happen with changes to your CMS or just general changes to your taxonomy or restructuring of a company.

Any good “war stories” of migrations going wrong? How did you fix things?

Stox: I have tons of these. Come to the session to hear about them. What you need to keep in mind is anything wrong is temporary. Luckily with these migrations, there’s almost nothing that can’t be fixed later, so don’t panic. It may hurt temporarily but it can be fixed.

Grimm: The worst case, no matter if you’re freelancing or part of an agency, is when you enter a scenario when things have already gone wrong. This doesn’t even necessarily mean that the migration has been completed, but often you’ll be confronted with a “the timeframe is set, we can’t change anything anymore” attitude which then results in rushing things through, and that’s never a good idea.

Technically, I feel there’s not a lot that we haven’t seen yet: from missing redirects, to loops, broken canonicals, missing disavow files (so penalties return) and entirely blocking crawlers, to more tricky issues (e.g. different header directives for different user-agents) and the whole complexity surrounding JavaScript frontend frameworks. In short, a lot can go wrong! That’s one of the reasons why I repeatedly suggest building test and review routines based on individual needs way in advance!

Apart from making sure the technical implementation goes smoothly, what kinds of business considerations come into play when doing a migration?

Grimm: First and foremost, probably a general risk vs. reward analysis (I’d recommend planning at least three different scenarios and comparing them individually against potential savings, e.g. legacy systems and infrastructure, as well as growth opportunities). Also, seasonality is important (e.g. when’s a good time to do it?) as well as results from previous user acceptance tests (e.g. if you’re introducing new layouts, etc.).

Stox: Usually branding, announcements, personnel changes, costs, contracts, timing, resources, content consolidation, possibly changes and migration/forwarding of emails, even things like social media accounts and phone numbers. I would say it’s almost impossible to think of everything the first time and there’s almost always something new that comes up unexpectedly.

This is just a taste of the actionable information gained from extensive experience that Bastian and Patrick will be presenting at SMX West. To hear more of their valuable insights (and download their slides as a key takeaway) be sure to attend our SMX West conference in San Jose January 30-31, 2019.

About The Author

Leave a Reply

Your email address will not be published. Required fields are marked *