There's no such thing as a Site Migration

Websites, like the busi­nesses who oper­ate them, are often decept­ively complic­ated machines.

They’re fragile systems, and chan­ging or repla­cing any one of the parts can easily affect (or even break) the whole setup — often in ways not imme­di­ately obvi­ous to stake­hold­ers or developers.

Even seem­ingly simple sites are often powered by complex tech­no­logy, like content manage­ment systems, data­bases, and templat­ing engines. There’s much more going on behind the scenes — tech­nic­ally and organ­iz­a­tion­ally — than you can easily observe by crawl­ing a site or view­ing the source code.

When you change a website and remove or add elements, it’s not uncom­mon to intro­duce new errors, flaws, or faults.

That’s why I get extremely nervous whenever I hear a client or busi­ness announce that they’re intend­ing to undergo a “site migration.”

Chances are, and exper­i­ence suggests, that something’s going to go wrong.

Migrations vary wildly in scope

As an SEO consult­ant and prac­ti­tioner, I’ve been involved in more “site migra­tions” than I can remem­ber or count — for char­it­ies, star­tups, inter­na­tional e‑commerce sites, and even global house­hold brands. Every one has been uniquely chal­len­ging and stressful.

In each case, the busi­nesses involved have under­es­tim­ated (and in some cases, increased) the complex­ity, the risk, and the details involved in success­fully execut­ing their “migra­tion.”

As a result, many of these projects negat­ively impacted perform­ance and poten­tial in ways that could have been easily avoided.

This isn’t a case of the scope of the “migra­tion” being too big, but rather, a misalign­ment of under­stand­ing, object­ives, meth­ods, and prior­it­ies, result­ing in stake­hold­ers work­ing on entirely differ­ent scopes.

The migra­tions I’ve exper­i­enced have varied from simple domain trans­fers to complete over­hauls of server infra­struc­ture, content manage­ment frame­works, templates, and pages — some­times even scal­ing up to include the consol­id­a­tion (or frag­ment­a­tion) of multiple websites and brands.

In the minds of each organ­iz­a­tion, however, these have all been “migra­tion” projects despite their signi­fic­antly vary­ing (and poorly defined) scopes. In each case, the defin­i­tion and under­stand­ing of the word “migra­tion” has varied wildly.

We suck at definitions

As an industry, we’re used to strug­gling with labels. We’re still not sure if we’re SEOsinbound marketersdigital marketers, or just… marketers. The prob­lem is that, when we speak to each other (and those outside of our industry), these words can carry differ­ent mean­ing and expectations.

Even amongst ourselves, a conver­sa­tion between two digital marketers, analysts, or SEOs about their fields of expert­ise is likely to reveal that they have surpris­ingly differ­ent defin­i­tions of their roles, respons­ib­il­it­ies, and remits. To them, words like “content” or “plat­form” might mean differ­ent things.

In the same way, “site migra­tions” vary wildly, in form, func­tion, and execu­tion — and when we discuss them, we’re not neces­sar­ily talk­ing about the same thing. If we don’t clarify our mean­ings and have shared defin­i­tions, we risk misun­der­stand­ings, errors, or even offense.

Ambiguity creates risk

Poorly managed migra­tions can have a number of consequences beyond just drops in rank­ings, traffic, and perform­ance. There are second­ary impacts, too. They can also inadvertently:

  • Provide a poor user exper­i­ence (e.g., old URLs now 404, or error states are confus­ing to users, or a user reaches a page differ­ent from what they expected).
  • Break or omit track­ing and/​or analyt­ics imple­ment­a­tionsresult­ing in loss of busi­ness intelligence.
  • Limit the size, shape, or scalab­il­ity of a site, result­ing in static, stag­nant, or inflex­ible templates and content (e.g., omit­ting the abil­ity to add or edit pages, content, and/​or sections in a CMS), and a site which struggles to compete as a result.
  • Miss oppor­tun­it­ies to bene­fit from what SEOs do best: blend­ing an under­stand­ing of consumer demand and beha­vior, the market and compet­it­ors, and the brand in ques­tion to create more effect­ive strategies, func­tion­al­ity and content.
  • Create conflict between stake­hold­ers, when we need to “hustle” at the last minute to retro­fit our require­ments into an already complex project (“I know it’s about to go live, but PLEASE can we add analyt­ics conver­sion track­ing?”) — often at the cost of our reputation.
  • Waste future resource, where mistakes require that future resource is spent recoup­ing equity result­ing from faults or omis­sions in the process, rather than build­ing on and enhan­cing performance.

I should point out that there’s noth­ing wrong with hustle in this case; that, in fact, begging, borrow­ing, and steal­ing can often be a viable solu­tion in these kinds of scen­arios. There’s been more than one occa­sion when, late at night before a site migra­tion, I’ve aver­ted disaster by liter­ally beggingdevelopers to include template review processes, to imple­ment redir­ects, or to stall deployments.

But this isn’t a sens­ible or sustain­able or reli­able way of working.

Mistakes will inev­it­ably be made. Resources, favors, and patience are finite. Too much reli­ance on “hustle” from indi­vidu­als (or multiple indi­vidu­als) may in fact further widen the gap in under­stand­ing and scope, and posi­tions the hust­ler as a single point of failure.

More import­antly, hustle may only fix the symp­toms, not the cause of these issues. That means that we remain stuck in a role as the disrupt­ive outsiders who constantly squeeze in extra unscoped require­ments at the elev­enth hour.

Where things go wrong

If we’re to begin to address some of these chal­lenges, we need to under­stand when, where, and why migra­tion projects go wrong.

The root cause of all less-​than-​perfect migra­tions can be traced to at least one of the follow­ing scenarios:

  • The migra­tion project occurs without consultation.
  • Consultation is sought too late in the process, and/​or after the migration.
  • There is insuf­fi­cient planned resource/​time/​budget to add require­ments (or processes)/make recom­men­ded changes to the brief.
  • The scope is changed mid-​project, without consulta­tion, or in a way which de-​prioritizes requirements.
  • Requirements and/​or recom­men­ded changes are axed at the elev­enth hour (due to resource/​time/​budget limit­a­tions, or educational/​political conflicts).

There’s a common theme in each of these cases. We’re not involved early enough in the process, or our opin­ions and prior­it­ies don’t carry suffi­cient weight to impact timelines and resources.

Chances are, these mistakes are rarely the product of spite or of inten­tional omis­sion; rather, they’re born of gaps in the educa­tion and exper­i­ence of the stake­hold­ers and decision-​makers involved.

We can address this, to a degree, by elev­at­ing ourselves to senior stake­hold­ers in these kinds of projects, and by being consul­ted much earlier in the timeline.

Let’s be more specific

I think that it’s our respons­ib­il­ity to help the organ­iz­a­tions we work for to avoid these mistakes. One of the easi­est oppor­tun­it­ies to do that is to make sure that we’re talk­ing about the same thing, as early in the process as possible.

Otherwise, migra­tions will continue to go wrong, and we will continue to spend far too much of our collect­ive time fixing broken links, recom­mend­ing changes or improve­ments to templates, and hold­ing together bruised-​and-​broken websites — all at the expense of doing mean­ing­ful, impact­ful work.

Perhaps we can begin to answer to some of these chal­lenges by creat­ing better defin­i­tions and help­ing to clarify exactly what’s involved in a “site migra­tion” process.

Unfortunately, I suspect that we’re stuck with the word “migra­tion,” at least for now. It’s a term which is already widely used, which people think is a correct and appro­pri­ate defin­i­tion. It’s unreal­istic to try to change every­body else’s language when we’re already too late to the conversation.

Our next best oppor­tun­ity to reduce ambi­gu­ity and risk is to codify the types of migra­tion. This gives us a chance to prompt further explor­a­tion and better definitions.

For example, if we can say “This sounds like it’s actu­ally a domain migra­tion paired with a templatemigra­tion,” we can steer the conver­sa­tion a little and rely on a much better shared frame of reference.

If we can raise a chal­lenge that, e.g., the “trans­la­tion project” a differ­ent part of the busi­ness is work­ing on is actu­ally a whole bunch of inter­woven migra­tion types, then we can raise our concerns earlier and pursue more appro­pri­ate resource, budget, and author­ity (e.g., “This project actu­ally consists of a series of migra­tions involving templatescontent, and domains. Therefore, it’s imper­at­ive that we also consider X and as part of the project scope.”).

By persist­ing in labelling this way, stake­hold­ers may gradu­ally come to under­stand that, e.g., chan­ging the design typic­ally also involves chan­ging the templates, and so the SEO folks should really be involved earlier in the process. By chal­len­ging the language, we can chal­lenge the thinking.

Let’s codify migration types

I’ve iden­ti­fied at least seven distinct types of migra­tion. Next time you encounter a “migra­tion” project, you can invest­ig­ate the proposed changes, map them back to these types, and flag any gaps in under­stand­ing, expect­a­tions, and resource.

You could argue that some of these aren’t strictly “migra­tions” in a tech­nical sense (i.e., chan­gingsome­thing isn’t the same as moving it), but group­ing them this way is intentional.

Remember, our goal here isn’t to neatly categor­ize all of the require­ments for any possible type of migra­tion. There are plenty of resources, guides, and lists which already try do that.

Instead, we’re trying to provide neat, univer­sal labels which help us (the SEO folks) and them (the busi­ness stake­hold­ers) to have shared defin­i­tions and to remove unknown unknowns.

They’re a set of shared defin­i­tions which we can use to trig­ger early warn­ing signals, and to help us better manage stake­holder expectations.

Feel free to suggest your own, to grow, shrink, combine, or bin any of these to fit your own exper­i­ence and requirements!

1. Hosting migrations

A broad bund­ling of infra­struc­turehard­ware, and server consid­er­a­tions (while these are each broad categor­ies in their own right, it makes sense to bundle them together in this context).

If your migra­tion project contains any of the follow­ing changes, you’re talk­ing about a host­ing migra­tion, and you’ll need to explore the SEO implic­a­tions (and devel­op­ment resource require­ments) to make sure that changes to the under­ly­ing plat­form don’t impact front-​end perform­ance or visibility.

  • You’re chan­ging host­ing provider.
  • You’re chan­ging, adding, or remov­ing server locations.
  • You’re alter­ing the specific­a­tions of your phys­ical (or virtual) serv­ers (e.g., RAM, CPU, stor­age, hard­ware types, etc).
  • You’re chan­ging your server tech­no­logy stack (e.g., moving from Apache to Nginx).*
  • You’re imple­ment­ing or remov­ing load balan­cing, mirror­ing, or extra server environments.
  • You’re imple­ment­ing or alter­ing cach­ing systems (data­base, static page caches, varnish, object, memcached, etc).
  • You’re alter­ing the phys­ical or server secur­ity proto­cols and features.**
  • You’re chan­ging, adding or remov­ing CDNs.***

*Might over­lap into a soft­ware migra­tion if the changes affect the config­ur­a­tion or beha­vior of any front-​end compon­ents (e.g., the CMS).

**Might over­lap into other migra­tions, depend­ing on how this mani­fests (e.g., template, soft­ware, domain).

***Might over­lap into a domain migra­tion if the CDN is presen­ted as/​on a distinct host­name (e.g., AWS), rather than invis­ibly (e.g., Cloudflare).

2. Software migrations

Unless your website is comprised of purely static HTML files, chances are that it’s running some kind of soft­ware to serve the right pages, beha­vi­ors, and content to users.

If your migra­tion project contains any of the follow­ing changes, you’re talk­ing about a soft­ware migra­tion, and you’ll need to under­stand (and input into) how things like managing error codes, site func­tion­al­ity, and back-​end beha­vior work.

  • You’re chan­ging CMS.
  • You’re adding or remov­ing plugins/​modules/​add-​ons in your CMS.
  • You’re upgrad­ing or down­grad­ing the CMS, or plugins/​modules/​addons (by a signi­fic­ant degree/​major release) .
  • You’re chan­ging the language used to render the website (e.g., adopt­ing Angular2 or NodeJS).
  • You’re devel­op­ing new func­tion­al­ity on the website (forms, processes, widgets, tools).
  • You’re merging plat­forms; e.g., a blog which oper­ated on a separ­ate domain and system is being integ­rated into a single CMS.*

*Might over­lap into a domain migra­tion if you’re absorb­ing soft­ware which was previ­ously located/​accessed on a differ­ent domain.

3. Domain migrations

Domain migra­tions can be pleas­antly straight­for­ward if executed in isol­a­tion, but this is rarely the case. Changes to domains are often paired with (or the result of) other struc­tural and func­tional changes.

If your migra­tion project alters the URL(s) by which users are able to reach your website, contains any of the follow­ing changes, then you’re talk­ing about a domain migra­tion, and you need to consider how redir­ects, proto­cols (e.g., HTTP/​S), host­names (e.g., www/​non-​www), and brand­ing are impacted.

  • You’re chan­ging the main domain of your website.
  • You’re buying/​adding new domains to your ecosystem.
  • You’re adding or remov­ing subdo­mains (e.g., remov­ing domain sharding follow­ing a migra­tion to HTTP2).
  • You’re moving a website, or part of a website, between domains (e.g., moving a blog on a subdo­main into a subfolder, or vice-versa).
  • You’re inten­tion­ally allow­ing an active domain to expire.
  • You’re purchas­ing an expired/​dropped domain.

4. Template migrations

Chances are that your website uses a number of HTML templates, which control the struc­ture, layout, and peri­pheral content of your pages. The logic which controls how your content looks, feels, and behaves (as well as the beha­vior of hidden/​meta elements like descrip­tions or canon­ical URLs) tends to live here.

If your migra­tion project alters elements like your internal navig­a­tion (e.g., the header or footer), elements in your <head>, or other­wise changes the page struc­ture around your content in the ways I’ve outlined, then you’re talk­ing about a template migra­tion. You’ll need to consider how users and search engines perceive and engage with your pages, how context, relev­ance, and author­ity flow through internal link­ing struc­tures, and how well-​structured your HTML (and JS/​CSS) code is.

  • You’re making changes to internal navigation.
  • You’re chan­ging the layout and struc­ture of import­ant pages/​templates (e.g., homepage, product pages).
  • You’re adding or remov­ing template compon­ents (e.g., side­bars, interstitials).
  • You’re chan­ging elements in your <head> code, like titlecanon­icalor hreflang tags.
  • You’re adding or remov­ing specific templates (e.g., a template which shows all the blog posts by a specific author).
  • You’re chan­ging the URL pattern used by one or more templates.
  • You’re making changes to how device-​specific render­ing works*

*Might involve domain, soft­ware, and/​or host­ing migra­tions, depend­ing on imple­ment­a­tion mechanics.

5. Content migrations

Your content is everything which attracts, engages with, and convinces users that you’re the best brand to answer their ques­tions and meet their needs. That includes the words you use to describe your products and services, the things you talk about on your blog, and every image and video you produce or use.

If your migra­tion project signi­fic­antly changes the tone (includ­ing language, demo­graphic target­ing, etc), format, or quantity/​quality of your content in the ways I’ve outlined, then you’re talk­ing about a content migra­tion. You’ll need to consider the needs of your market and audi­ence, and how the words and media on your website answer to that — and how well it does so in compar­ison with your competitors.

  • You signi­fic­antly increase or reduce the number of pages on your website.
  • You signi­fic­antly change the tone, target­ing, or focus of your content.
  • You begin to produce content on/​about a new topic.
  • You trans­late and/​or inter­na­tion­al­ize your content.*
  • You change the categor­iz­a­tion, tagging, or other clas­si­fic­a­tion system on your blog or product content.**
  • You use tools like canon­ical tags, meta robots index­a­tion direct­ives, or robots.txt files to control how search engines (and other bots) access and attrib­ute value to a content piece (indi­vidu­ally or at scale).

*Might involve domain, soft­ware and/​or host­ing, and template migra­tions, depend­ing on imple­ment­a­tion mechanics.

**May over­lap into a template migra­tion if the layout and/​or URL struc­ture changes as a result.

6. Design migrations

The look and feel of your website doesn’t neces­sar­ily directly impact your perform­ance (though user signals like engage­ment and trust certainly do). However, simple changes to design compon­ents can often have unin­ten­ded knock-​on effects and consequences.

If your migra­tion project contains any of the follow­ing changes, you’re talk­ing about a design migra­tion, and you’ll need to clarify whether changes are purely cosmetic or whether they go deeper and impact other areas.

  • You’re chan­ging the look and feel of key pages (like your homepage).*
  • You’re adding or remov­ing inter­ac­tion layers, e.g. condi­tion­ally hiding content based on device or state.*
  • You’re making design/​creative changes which change the HTML (as opposed to just images or CSS files) of specific elements.*
  • You’re chan­ging key messaging, like logos and brand slogans.
  • You’re alter­ing the look and feel to react to chan­ging strategies or monet­iz­a­tion models (e.g., intro­du­cing space for ads in a side­bar, or remov­ing ads in favor of using inter­sti­tial popups/​states).
  • You’re chan­ging images and media.**

*All template migrations.

**Don’t forget to 301 redir­ect these, unless you’re repla­cing like-​for-​like file­names (which isn’t always best prac­tice if you wish to inval­id­ate local or remote caches).

7. Strategy migrations

A change in organ­iz­a­tional or market­ing strategy might not directly impact the website, but a widen­ing gap between a brand’s audi­ence, object­ives, and plat­form can have a signi­fic­ant impact on performance.

If your market or audi­ence (or your under­stand­ing of it) changes signi­fic­antly, or if your mission, your repu­ta­tion, or the way in which you describe your products/​services/​purpose changes, then you’re talk­ing about a strategy migra­tion. You’ll need to consider how you struc­ture your website, how you target your audi­ences, how you write content, and how you campaign (all of which might trig­ger a set of new migra­tion projects!).

  • You change the company mission statement.
  • You change the website’s key object­ives, goals, or metrics.
  • You enter a new market­place (or leave one).
  • Your chan­nel focus (and/​or your audience’s) changes significantly.
  • A compet­itor disrupts the market and/​or takes a signi­fic­ant amount of your market share.
  • Responsibility for the website/​its performance/​SEO/​digital changes.
  • You appoint a new agency or team respons­ible for the website’s performance.
  • Senior/​C‑level stake­hold­ers leave or join.
  • Changes in legal frame­works (e.g. privacy compli­ance or new/​changing content restric­tions in prescript­ive sectors) constrain your publishing/​content capabilities.

Let’s get in earlier

Armed with better defin­i­tions, we can begin to force a more considered conver­sa­tion around what a “migra­tion” project actu­ally involves. We can use a shared language and ensure that stake­hold­ers under­stand the risks and oppor­tun­it­ies of the changes they intend to make.

Unfortunately, however, we don’t always hear about proposed changes until they’ve already been decided and signed off.

People don’t know that they need to tell us that they’re chan­ging domain, templates, host­ing, etc. So it’s often too late when — or if — we finally get involved. Decisions have already been made before they trickle down into our awareness.

That’s still a problem.

By the time you’re aware of a project, it’s usually too late to impact it.

While our new-​and-​improved defin­i­tions are a great start­ing place to catch risks as you encounter them, avoid­ing those risks alto­gether requires us to develop a much better under­stand­ing of how, where, and when migra­tions are planned, managed, and start to go wrong.

Let’s identify trigger points

I’ve iden­ti­fied four common scen­arios which lead to organ­iz­a­tions decid­ing to undergo a migra­tion project.

If you can keep your ears to the ground and spot these types of events unfold­ing, you have an oppor­tun­ity to give your­self permis­sion to insert your­self into the conver­sa­tion, and to inter­rog­ate to find out exactly which types of migra­tions might be looming.

It’s worth find­ing ways to get added to deploy­ment lists and noti­fic­a­tions, internal project manage­ment tools, and other systems so that you can look for early warn­ing signs (without creat­ing unne­ces­sary over­head and comms processes).

1. Mergers, acquisitions, and closures

When brands are bought, sold, or merged, this almost univer­sally trig­gers changes to their websites. These require­ments are often dictated from on-​high, and there’s limited (or no) oppor­tun­ity to impact the brief.

Migration strategies in these situ­ations are rarely comfort­able, and almost always defens­ive by nature (focus­ing on minim­iz­ing impact/​cost rather than capit­al­iz­ing upon opportunity).

Typically, these kinds of scen­arios mani­fest in a small number of ways:

  • The “parent” brand absorbs the website of the purchased brand into their own website; either by “bolt­ing it on” to their exist­ing archi­tec­ture, moving it to a subdomain/​folder, or by distrib­ut­ing salvage­able content through­out their exist­ing site and killing the old one (often trig­ger­ing most, if not every type of migra­tion).
  • The purchased brand website remains where it is, but under­goes a design migra­tion and possibly template migra­tions to align it with the parent brand.
  • A brand website is retired and redir­ec­ted (a domain migra­tion).

2. Rebrands

All sorts of pres­sures and oppor­tun­it­ies lead to rebrand­ing activ­ity. Pressures to remain relev­ant, to repos­i­tion within market­places, or change how the brand repres­ents itself can trig­ger migra­tion require­ments — though these activ­it­ies are often led by brand and creat­ive teams who don’t neces­sar­ily under­stand the implications.

Often, the outcome of brand­ing processes and initi­at­ives creates new a or altern­ate under­stand­ing of markets and consumers, and/​or creates new guidelines/​collateral/​creative which must be reflec­ted on the website(s). Typically, this can result in:

  • Changes to core/​target audi­ences, and the content or language/​phrasing used to commu­nic­ate with them (strategy and content migra­tions -—more if this involves, for example, open­ing up to inter­na­tional audiences).
  • New collat­eral, repla­cing or adding to exist­ing media, content, and messaging (content and design migrations).
  • Changes to website struc­ture and domain names (template and domain migra­tions) to align to new brand­ing requirements.

3. C‑level vision

It’s not uncom­mon for senior stake­hold­ers to decide that the strategy to save a strug­gling busi­ness, to grow into new markets, or to make their mark on an organ­iz­a­tion is to launch a brand-​new, shiny website.

These kinds of decisions often involve a scorched-​earth approach, tear­ing down the work of their prede­cessors or of previ­ously under-​performing strategies. And the more senior the decision-​maker, the less likely they’ll under­stand the implic­a­tions of their decisions.

In these kinds of scen­arios, your best oppor­tun­ity to avert disaster is to watch for warn­ing signs and to make your­self heard before it’s too late. In partic­u­lar, you can watch out for:

  • Senior stake­hold­ers with market­ing, IT, or C‑level respons­ib­il­it­ies join­ing, leav­ing, or being replaced (in partic­u­lar if in rela­tion to poor performance).
  • Boards of direct­ors, investors, or similar pres­sur­ing web/​digital teams for unreal­istic perform­ance goals (based on current performance/​constraints).
  • Gradual reduc­tion in budget and resource for day-​to-​day manage­ment and improve­ments to the website (as a likely prelude to a big strategy migra­tion).
  • New agen­cies being brought on board to optim­ize website perform­ance, who’re hindered by the current framework/​constraints.
  • The adop­tion of new martech and market­ing auto­ma­tion software.*

*Integrations of solu­tions like SalesForce, Marketo, and similar some­times rely on util­iz­ing prox­ied subdo­mains, embed­ded forms/​content, and other mech­an­ics which will need care­ful consid­er­a­tion as part of a template migration.

4. Technical or financial necessity

The current website is in such a poor, restrict­ive, or cost-​ineffective condi­tion that it makes it impossible to adopt new-​and-​required improve­ments (such as compli­ance with new stand­ards, an integ­ra­tion of new martech stacks, changes follow­ing a brand purchase/​merger, etc).

Generally, like the kinds of C‑level “new website” initi­at­ives I’ve outlined above, these result in scorched earth solutions.

Particularly frus­trat­ing, these are the kinds of migra­tion projects which you your­self may well argue and fight for, for years on end, only to then find that they’ve been scoped (and maybe even begun or completed) without your input or awareness.

Here are some danger signs to watch out for which might mean that your migra­tion project is immin­ent (or, at least, defin­itely required):

  • Licensing costs for parts or the whole plat­form become cost-​prohibitive (e.g., enter­prise CMS plat­forms, user seats, developer train­ing, etc).
  • The soft­ware or hard­ware skill set required to main­tain the site becomes rarer or more expens­ive (e.g., outdated technologies).
  • Minor-​but-​urgent tech­nical changes take more than six months to implement.
  • New tech­nical implementations/​integrations are agreed upon in prin­ciple, budgeted for, but not implemented.
  • The tech­nical back­log of tasks grows faster than it shrinks as it fills with break­ages and fixes rather than new features, initi­at­ives, and improvements.
  • The website ecosys­tem doesn’t support the organization’s ways of work­ing (e.g., the organ­iz­a­tion adopts agile meth­od­o­lo­gies, but the website only supports waterfall-​style code­base releases).
  • Key tech­no­logy which under­pins the site is being deprec­ated, and there’s no easy upgrade path.*

*Will likely trig­ger host­ing or soft­ware migrations.

Let’s not count on this

While this kind of labelling undoubtedly goes some way to help­ing us spot and better manage migra­tions, it’s far from a perfect or complete system.

In fact, I suspect it may be far too ambi­tious, and unreal­istic in its aspir­a­tion. Accessing conver­sa­tions early enough — and being listened to and empowered in those conver­sa­tions — relies on the good­will and open­ness of compan­ies who aren’t always completely bought into or enam­ored with SEO.

This will only work in an organ­iz­a­tion which is open to this kind of think­ing and internal chal­len­ging — and chances are, they’re not the kinds of organ­iz­a­tions who are routinely break­ing their websites. The very people who need our help and this kind of system are funda­ment­ally unsuited to receive it.

I suspect, then, it might be impossible in many cases to make the kinds of changes required to shift beha­vi­ors and catch these prob­lems earlier. In most organ­iz­a­tions, at least.

Avoiding disasters result­ing from ambigu­ous migra­tion projects relies heav­ily on broad educa­tion. Everything else aside, people tend to change compan­ies faster than you can build deep enough tribal knowledge.

That doesn’t mean that the struc­ture isn’t still valu­able, however. The types of changes and trig­gers I’ve outlined can still be used as alarm bells and direc­tion for your own use.

Let’s get real

If you can’t effect­ively educate stake­hold­ers on the complex­it­ies and impact of them making changes to their website, there are more “light­weight” solutions.

At the very least, you can turn these kinds of items (and expand with your own, and in more detail) into simple lists which can be prin­ted off, lamin­ated, and stuck to a wall. At the very least, perhaps you’ll remind some­body to pick up the phone to the SEO team when they recog­nize an issue.

In a more prag­matic world, stake­hold­ers don’t neces­sar­ily have to under­stand the nuance or the detail if they at least under­stand that they’re meant to ask for help when they’re chan­ging domain, for example, or adding new templates to their website.

Whilst this doesn’t solve the under­ly­ing prob­lems, it does provide a mech­an­ism through which the damage can be system­at­ic­ally avoided or limited. You can identify prob­lems earlier and be part of the conversation.

If it’s still too late and things do go wrong, you’ll have some­thing you can point to and say “I told you so,” or, more construct­ively perhaps, “Here’s the resource you need to avoid this happen­ing next time.”

And in your moment of self-​righteous vindic­a­tion, having success­fully made it through this post and now armed to save your company from a botched migra­tion project, you can migrate over to the bar. Good work, you.

Originally posted on

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x