The M&A Migration Framework: Merging Websites Without Killing Business Value

This week, we welcome back David Carrasco Pamies, who shares what an SEO migration really looks like when your company is the one being absorbed. It's a candid field guide to the negotiation, pre-move clean-up, and how to keep brand signals coherent when two entities become one.

I pitched this article months ago, expecting to have a finished migration to build it around. A specific one, well underway, that I was fairly sure would be live by the time I sat down to write. It isn't. It's still stuck, held up by paperwork and the slow work of two organisations trying to become one.

For a piece about acquisition migrations, that actually turned out to be the most honest lesson available: what stalled it had almost nothing to do with checklists, and everything to do with people.

So the article changed shape. Instead of the clean before-and-after of one case, it draws on several of these migrations I've worked through, the one that's still stuck included. Some scars, a couple of wins, and the things I'd want to know before the next one. If nothing else, learning from someone else's bruises is cheaper than collecting your own.

The first thing I got wrong was assuming this was a technical project…

Why an acquisition migration isn't a replatforming

A replatforming moves an entity from an old system to a new one. The site changes shape, the business behind it doesn't. An acquisition works the other way around: the business changes, and the site has to absorb it.

The version I want to talk about is the one I've been through a few times, and the one that trips people up: you're the company being absorbed. Your site isn't the destination, it's the thing being folded into someone else's. You don't set the structure, you inherit it. The larger domain decides what slot it has for you, how its taxonomy works, what its CMS will and won't allow, and your job is to fit into that.

From the first meeting, that's the reality: you're a guest in a house you didn't build, and most of the important decisions are already half-made.

None of what follows is about redirect mechanics. You already know how a 301 behaves, and Sitebulb's guide to redirects for SEO covers that ground better than a recap would. Google also expects ranking fluctuation while it recrawls and reindexes, and you can move a large site in sections. The mechanics are complicated but they’re the kind of problem that has a known answer. The hardest part sits one level up, in decisions that look like business calls and only reveal themselves as SEO ones later.

And the most complex of those decisions starts the moment you sit down with the other team.

When your entire site becomes just another product line

What was your entire business, your whole website, the thing you spent years building, becomes one product line inside a house someone else built. It's the part I underestimated most, and it has almost nothing to do with technology.

In my case there was an added twist: the larger business, bigger by every commercial measure, had a thinner web presence than we did, at least in the corner of the market we came from. Fewer commercial pages dedicated to each product, and a blog that barely touched the field they had just bought us for. We arrived with more developed content and less authority to decide what happened to it. More to protect, and less power to protect it with. That gap is where the negotiation starts, and it is a negotiation, even when nobody in the room calls it that.

It also matters whether the two companies even serve the same market. Often they don't, and when the markets differ, the larger company's way of doing things tends to win by default, because it's bigger and its structure is already there.

But not always. It depends on what the parent actually wants from the thing it bought: a strategic bet to move into a market they were weak in, or a bolt-on to fold into what they already do. If you're the strategic bet, you have room to argue for what made your product work; if you're the bolt-on, you have less.

Working out which one you are, early, tells you how hard it's worth pushing.

Pick your battles

You won't win every argument, so you must decide in advance which ones matter. That was my read after the first of many calls, and it's how I approach it rather than a rule.

Before those conversations I mapped three versions of the outcome. The must-haves, the things I'll fight for because losing them costs the business real value. The ideal scenario, what I'd take if I had full say. And the nice-to-haves, the things I'll trade away to win the ones that count. Walking in with everything weighted equally is how you lose an important battle while defending a trivial one.

Not every migration decision deserves the same fight. Know what you need to protect, what you want to negotiate, and what you're willing to trade.

Speak their language, and not only to other SEOs

You also have to argue in the other team's terms. If they justify their structure with traffic, you can't rest your whole case on traffic, because they'll out-traffic you every time. They're the bigger domain. You translate what you're protecting into the currency the conversation actually runs on: revenue, pipeline, brand risk.

And it won't only be SEOs in the room. In a merger you're negotiating with development, with marketing, sometimes with product, each with its own priorities and its own read on what your content is for.

On top of that, you're doing it with people who are privately worried about their own jobs, yourself included. Redundancies, reporting lines, whose tooling survives: none of it gets said aloud, but all of it is in the room. Reading that undercurrent matters as much as any redirect.

You're also, very often, in a room full of nationalities. English is usually the shared language, but everyone brings their own culture with them, and that shapes how people offer an opinion, how they disagree, how blunt their feedback gets. What reads as healthy directness to one person reads as rudeness to another. Misreading that can cost you a decision as surely as a weak argument.

Part of speaking their language is making them feel the weight of getting this right, and the time it honestly needs. Not to pad the schedule, but so the work can be planned properly and, just as important, so it doesn't drag on for months. A migration left half-finished is a brand migration left half-finished, and the brand is what pays for the delay, stuck in the limbo where half the signals still say the old company and half say the new one.

Who owns the redirect map now?

The redirect map stops being your document, too. In a normal migration it's yours to own. In an acquisition it becomes a shared decision register between two teams, and it only holds together with a single owner keeping it honest while both sides sign off on what maps where.

This is where the old lesson about getting SEO into the project early stops being a platitude and becomes survival: a map nobody jointly owns is a map that quietly breaks the week before launch, usually because a decision got made in a room you weren't in.

That coordination gets harder in a merger, because you're usually managing two development teams rather than one, each with its own stack and its own idea of what "done" means. The map tells them where URLs go; it doesn't tell them who does what. So agree early and explicitly who implements the redirects and who tests them, since in a two-team setup that's the responsibility that falls through the cracks.

The map has a blind spot, too. A website is never just the pages you can see: underneath there are forms wired to a CRM, marketing automations, tracking, integrations that fire on specific URLs. When the URLs change, those move with them or break, and in a merger they're rarely written down in one place. They tend to surface weeks later, as the automation that stopped creating leads long after everyone agreed the migration was done.

And when the deadline is political, resist the pressure to let the developers ship it and fix the SEO afterwards, because that's usually how a broad server-level rule gets set without anyone checking it against the map.

Set expectations before you launch

The other half of coordination is expectation, and it's cheaper to set before launch than to defend after. A temporary dip while Google recrawls and reindexes is normal, and recovery tends to run in weeks, longer for competitive terms. Say that out loud, to everyone before you go live.

In a merger there are simply more people watching, and more of them have no SEO context, so the odds that someone panics on day three and demands you "fix" something are higher than usual. Panic-driven changes during the dip do more damage than the dip itself. The expectation you set up front is what buys you room to hold your nerve.

Editor’s Note: You might want to check out this practical guide to migration disaster recovery.

Budget for patience

All of this runs slower than you expect, which is the last thing to plan for. If getting an initiative approved used to take three meetings, in the merged organisation it takes twice that. More stakeholders, more sign-offs, more people who need to understand why a page structure matters before they'll let you change it. Budget for patience like a line item, because underfunding it is how good plans die in committee.

None of these conversations go well, though, if you walk in without having done the homework on your own site first.

The work on your own site

This is the unglamorous half, and it runs in a rough sequence: clean up what you've got, map what's worth protecting, merge the two blogs, then watch the launch closely.

Clean your own house before you move

Start by cleaning your own house, because the site you're moving is older and messier than you remember.

Websites age, like the rest of us. Migration or not, a growing share of the projects that reach me now need a serious content clean-up among the very first initiatives, and an acquisition only forces the issue, because someone finally has to decide what's worth carrying into a new home. Thin pages, dated posts, near-duplicates from a templating decision nobody revisited, whole sections that stopped earning their place: none of that is worth dragging across.

What you want is to kill cannibalisation, thin content and dated posts. What the people signing off want to hear is that every page you drop now is one fewer thing to map, migrate, test and maintain, so the move lands faster, costs less, and has fewer parts that can break on the day. Same task, two languages.

There's a less visible version of the same job. When your domain redirects into the parent, your history travels with it, not just your authority. If your site once carried a manual action, or leaned on a link profile that wouldn't survive a closer look, or has an old disavow file nobody has looked at in years, that becomes the parent's problem too, and the parent's team will notice. Clean it before you move, not after.

The way I get the real picture is to crawl my own site as if it were a stranger's, because after a few years it practically is. That crawl in Sitebulb is less about the redirect plan and more about inventory: what actually exists, what's indexed, what's thin, what's already orphaned, what points where.

Before deciding what moves, crawl what you actually have. Duplicate content, repeated metadata and other inherited problems are cheaper to clean up before the migration.

The risk map: what's load-bearing for the business, not just for traffic

Traffic seems to be the easy go-to metric for every team when they decide which pages matter in a migration. It's also the one most likely to mislead you.

The pages that keep a business standing aren't always the ones with the most sessions. A page can have almost no organic traffic and still matter: the one that holds your strongest backlinks, the one sales sends every prospect to, the trust page that closes deals nobody attributes in analytics. The risk isn't any single mapping decision. It's filtering the whole URL set by one metric and deciding in bulk.

Which is why I don't decide alone. Before I map redirects I rank URLs by business contribution, and to do that properly you have to ask the other teams what they actually value, because it won't all show up in your analytics.

Ask sales which pages they send prospects to. Ask marketing which assets close. The case studies with barely any traffic might be the strongest sales argument in the building, and you'd never know it from a sessions report.

Then I look at cumulative contribution rather than raw volume, because a small set of URLs usually carries most of the value, and those get the most careful mapping and the closest monitoring. Sitebulb's own migration planning guide frames a version of this as priority versus sensitivity, a useful second lens.

The crawl also shows where your architecture buries what matters. In Sitebulb, the crawl map and the internal link data tell me whether the commercially important pages are easy to reach or sitting four clicks deep behind whatever gets traffic. More than once the most valuable page for the business has been the hardest one for a crawler, or a user, to find, and that's a problem to fix on the way in, not reproduce.

Traffic alone doesn't tell you what matters. This commercially important sector landing page sits several clicks away from the core of the site.

The blog is its own migration

Merging two content libraries is a migration inside the migration, and it's mostly about fitting your content into a structure that was built without it in mind. I work it in three passes.

1. First, I clean my own blog, dropping the posts I wouldn't keep even if we were staying.
2. Second, I look at what the parent already has, to avoid cannibalising: if they already rank for something my content also targets, redirecting or consolidating the two into one stronger page beats publishing a rival to a page we now both own.
3. Third, I place what's left inside their categories and their taxonomy, which is slower and more manual than anyone expects. The temptation is to fold everything into their generic hubs for tidiness, but the pages ranking for specific, intent-heavy queries usually deserve to survive on their own terms instead.

One thing I could get ahead of was the ground itself. The parent was adjacent to what they had acquired us for, but not strong in it, with a blog that barely covered the field. So months before the migration I built a dedicated editorial calendar aimed squarely at that gap, warming up the topics and the internal structure our content would eventually land on.

By the time the migration came, the destination wasn't cold. When you can't control the timeline, controlling the preparation is the next best thing.

The safety net after launch

After launch you're watching for the failures that survive a clean staging test and break in production. Two of them catch people in messy merges.

1. Crawl checks

The first is a QA habit: crawl the old URL set, not the new site. Seeing 200s across the shiny new domain tells you the new site works, not whether the redirects do. So I crawl the frozen list of old URLs directly, check that each resolves in a single hop to where it was mapped, and diff the result against the map.

In an acquisition this matters more than usual, because the parent domain often has broad server-level rules already in place, and those can override your specific mappings without anyone checking. The spreadsheet says URL A goes to page B; a catch-all rule three lines up in the config sends it to a category page instead.

2. Semantic gate

The second is what I think of as the semantic gate. A 301 that returns cleanly isn't the same as a 301 that preserves value. Google is explicit that redirecting to a destination that isn't a genuine match can be treated as a soft 404, which means the equity you thought you passed gets discarded even though the redirect fires. In a merger this is the easiest way to lose value, because "close enough" mapping is tempting when you're reconciling two structures under time pressure.

There's also a tool worth a warning here, because it tempts people in exactly this scenario: the Change of Address tool in Search Console. It's built to move a whole domain to a new one, one to one, not to fold one site into another, so for a merge you lean on the redirect and site-move process itself rather than the tool.

In my case it didn't apply at all, since I was being absorbed into an existing domain rather than moving to a fresh one, which is the common case when you're the one acquired. If it does apply to you, Google asks for the request across every domain variant, not just the main one. Either way it doesn't replace the map: it won't fix homepage-only redirects, irrelevant destinations, or a disavow you forgot to re-upload.

This is also where orphan pages and redirect chains breed, since two sets of internal links are being stitched together and nobody holds the full map in their head. After launch I lean on Sitebulb's orphaned-pages list and the redirect Hints that flag chains and loops, and I compare the crawl map against the pre-launch one to see what moved and what got stranded.

Treat the first few weeks as an incident window, not a settling period, with a named person on call for redirects. "It's just SEO settling down" is the sentence that lets a real problem sit for a fortnight, and that's how a manageable launch can become a migration you have to rescue.

Post-launch checks need to look beyond whether a redirect fires. Loops and chained redirect loops can survive into production and leave pages inaccessible.

Getting the pages right, though, is only half of what the user experiences. The other half is whether the two brands tell them a coherent story.

Keeping the brand signals coherent

A migration can be technically flawless and still confuse everyone who cared about the old brand. When two companies become one, the signals about who you are have to move together, and they almost never do at the same speed.

The signals that fall out of sync

As Tom Spencer-Livingston points out in Sitebulb's migration guide, phasing a rebrand tends to backfire: change some pages to the new brand while others still carry the old one, and Google is left with conflicting signals it struggles to reconcile. The signals were never only on the pages, though. The domain changes but the social profiles still point at the old entity, the schema still names a company that on paper no longer exists, the old logo lingers in three places nobody remembered.

Usually not because anyone decided that, but because everyone's too busy in meetings working out the new policy on this or that. The integration stalls in the gap between the org chart and the website. So the real job here is coordination, and it runs across the same teams you negotiated with earlier.

Make the change legible for the user

For the user, the priority is reassurance. If the acquired brand still has real branded search demand, a silent 301 to the parent homepage throws that trust away.

A better move is to make the change legible. A bridge that says, in plain language, "formerly X, now part of Y", on the page, in the hero, even in the meta title, so someone who typed the old name knows they landed in the right place. The message that lands best is the reassuring one: what you valued is still here, and now there's more of it.

One message, one pace

Above all, the same message in every place, at the same pace. Domain, on-page copy, structured data, social bios, Google Business Profile, all of it moving together.

None of that is cosmetic. Coherent signals are how you avoid frustrating the users you just inherited, how you keep sending them and the crawlers to the new URLs, and how Google eventually understands that two entities have become one. Entity health is a technical SEO problem in its own right, which is the case I made in a separate Sitebulb piece on the brand-first technical audit.

Brand signals rarely change at the same speed. The longer copy, social profiles, business listings, schema and domain tell different stories, the longer two entities remain where there should be one.

Reconcile the two entities, not just the two sites

That entity-health problem takes a particular shape in an acquisition, because you're not moving one entity, you're merging two. Google holds both until you tell it otherwise: two brand SERPs, sometimes two Knowledge Panels, two trails through the Knowledge Graph and the sources that feed it. Redirects don't touch any of that. The work here is telling Google you're one entity now.

On a different acquisition I worked on, we declared the relationship in the schema, subOrganization and parentOrganization, consolidated the sameAs links, and then did the step most people skip: we went to the sources Google reads to build those entities, Wikidata and the wikis, where the information still described the absorbed company as if it stood alone, and corrected them.

There, Google merged the Knowledge Panel faster than I expected. I wouldn't bank on that speed, though. It depends on how much contradictory signal you leave lying around, and the whole point of the exercise is to leave as little as possible.

Do all of this and the migration holds. Which is the baseline, not the ambition. The more interesting question is whether it can do more than hold.

When the discipline pays off

Everything above is framed defensively, as protection, because in acquisitions, the downside is large. But the same discipline that protects value can release it, and it's worth ending there.

The clearest example I have is smaller than the migration that's still stuck, and it moved faster because there was far less politics in the room. Someone had acquired several hospitality businesses and wanted them under one roof, on a single site, instead of the scattered set of properties they'd bought. A consolidation more than a full M&A migration, and I'll flag that plainly.

Same framework, though: the same business-weighted risk map, the same insistence on intent-matched redirects, the same post-launch heartbeat. The difference was that we treated the migration as a chance to rebuild the site properly, fixing what had been holding each business back instead of carrying the problems across.

In the year after, direct bookings through the site were up 306%, clicks up 20% and impressions up 64% year over year, with no critical issues at launch.

I'm not going to claim a migration will three-x anyone's bookings. That number sits on top of a lot of other work, and I'd distrust anyone who sold it as a clean cause. What I'll stand behind is the direction. When you treat a migration as a business continuity event rather than a redirect task, and protect what holds the business up accordingly, the worst case gets smaller and the best case becomes possible.

A migration is a pain, there's no pretending otherwise, but it's also the rare moment when someone finally has permission to clean up and rebuild what years of drift left behind. It's just hard to see that from inside the paperwork. In an acquisition, where so much can go wrong in the gap between two companies, that shift in framing is most of the job.