Competitor Acquisitions: The Migration Playbook

How to migrate customers without destroying value

SaaS consolidation is accelerating, and the timing isn’t an accident. With many public and private SaaS assets trading in the ~3x to 5x revenue range, investors can’t count on multiple expansion or breakout organic growth to carry returns.

So the play shifts to what you can control: scale through consolidation and margin improvement through cost takeouts, with a clearer path to EBITDA. Therefore, expect a wave of M&A where acquirers try to consolidate the market by acquiring smaller competitors or investors deciding to execute a merger of equals.

There’s also a second-order benefit that matters more every quarter: a larger install base means more customers, more usage, and more workflow data, which is exactly what you want if you’re trying to buy and build credible AI capabilities inside the platform.

But the part that most models still underweight is the hardest part: a competitor acquisition only pays off if the customer migration works.

If the plan is to consolidate customers onto one platform and sunset the other, the upside depends on three things:

• How many customers do you retain

• How quickly you move them

• How much does it cost to get them there without breaking customer trust

That’s why this is different from a cross-sell integration. A cross-sell play can tolerate ambiguity and gradual adoption. A migration cannot. Customers are being asked to change vendors, retrain teams, rewire integrations, and take on risk they did not sign up for. You either manage that transition with discipline, or you bleed value slowly in the form of churn, support load, and a permanent dual-stack tax.

I’ve lived through many situations where migration was the primary value driver. Perhaps the most significant was the massive platform consolidation and migration that occurred in the aftermath of Thomson acquiring Reuters (now LSEG). At Sitecore, the M&A program also caused overlap in some platform capabilities. I’ve also compared notes with operators running similar consolidation plays. There are several consistent patterns, with a few early decisions determining whether migration becomes a controlled program or a drawn-out recovery effort.

Why consolidation is speeding up

A lot of the “why now” is less about clever strategy and more about timing.

Horizontal categories that used to support dozens of point solutions are maturing. Growth rates are normalizing, buyers are rationalizing their stacks, and procurement is pushing for fewer vendors that can cover more of the workflow. When customers have renewal fatigue, and platforms start to look similar, consolidation becomes the path of least resistance for vendors and sponsors.

AI is also changing what “scale” means. For many products, data isn’t valuable in the abstract. The valuable part is the signal tied to workflow, budget decisions, and outcomes. That makes vendors with real usage density more attractive assets. It also raises the pressure to unify product stacks after a deal, because splitting customers across two platforms dilutes the signal you’re trying to capture.

And private equity buy-and-build strategies increasingly depend on simplification. It’s not enough to own multiple products in the same category. At some point, you have to rationalize engineering, support, roadmap, and pricing. The moment you admit that, you’re underwriting a migration even if the investment memo never uses the word.

Three decisions that drive outcomes

Before you build a migration plan, you need clarity on three things.

1) Which platform do you migrate to, and when does the other end?

Teams routinely waste 6 to 12 months running two roadmaps and two platforms because they want more time to “see what customers want.” Customers interpret that as optionality, and they delay. Sometimes the real issue is internal: people worry about what happens to their org if a platform is sunset.

Meanwhile, the organization is stuck maintaining legacy code while trying to build net-new integration work. GTM tells two stories. Support carries two knowledge bases. None of that is free.

The decision is straightforward:

• Platform A is the go-forward platform

• Platform B has a published end-of-life timeline

Publish the sunset timeline early. Customers don’t need every detail on day one, but they do need a date, a path, and a support model. Without that, urgency never forms, and migration becomes the thing you keep postponing because other fires feel more immediate.

2) What will you not rebuild?

Every acquired platform has edge-case features, bespoke workflows, and a handful of customers who are loud because they are uniquely dependent on those quirks. The common mistake is trying to “de-risk churn” by promising feature parity across everything.

That promise almost always backfires. It slows the whole program, it overloads the roadmap with one-offs, and it creates a trust problem when you later reprioritize.

The only scalable approach is to define early:

• What will be rebuilt

• What gets a workaround

• What will not be replicated

Then communicate it plainly. This is uncomfortable, but it’s healthier than letting customers discover gaps mid-cutover.

3) How much will you spend to save customers versus accept attrition?

Migration is not just a technical exercise. It’s time, incentives, and concessions. It’s export/import tooling, validation, implementation support, and customer success capacity. If you don’t set explicit thresholds, you end up spending heroic effort on accounts that will never be healthy on the new platform, while under-serving the accounts that would have migrated cleanly with modest help.

The decision you need is not “retain as much as possible.” It’s:

• A migration budget tied to acquired ARR

• Retention targets by segment, not one blended number

• Guardrails on how much bespoke work you will fund at each tier

That forces the organization to make tradeoffs intentionally instead of by escalation volume.

Turning strategy into execution: segment, tailor, equip

Once the three decisions are set, execution becomes much more mechanical, in a good way.

Step 1: Segment customers using a 2x2 that forces prioritization

I prefer to use a simple segmentation approach that divides customers across two axes:

• Ease of migration: integrations, data volume, customization depth, compliance constraints, contract terms

• Value: ARR is fine, but gross margin dollars is often the more honest lens

Make “ease” a real score with a rubric. If it’s a debate, you’re already losing. A simple 1 to 5 scoring model across a few attributes is enough to rank every account and see where the work actually sits.

You end up with four groups:

• High value / Easy to migrate

• High value / Difficult to migrate

• Low value / Easy to migrate

• Low value / Difficult to migrate

Each cohort deserves different levels of investment and a tailored migration approach.

One practical add that improves execution: treat migration like a sales cycle, not a project plan. Discovery, internal budget timing, approvals, contract changes, and implementation all sit on the critical path. That reality should shape your incentives, staffing model, and timeline assumptions.

Step 2: Run different plays by quadrant

High value / Easy to migrate
Move fast, but don’t treat them as “automatic.” These customers still need confidence in the roadmap, clarity on what changes, and a frictionless path. Use a standard runbook, but communicate like it’s a high-stakes renewal. If you offer concessions, tie them to completion milestones rather than vague “relationship” discounts.

High value / Difficult to migrate
These accounts require controlled sequencing. Start with a technical discovery window, then a phased cutover plan with explicit success criteria. Assign an executive sponsor and a dedicated project team. If you need parallel-run, use it as a short risk-reduction period with a defined exit, not a permanent crutch.

The predictable failure mode here is avoiding hard conversations by promising to rebuild everything. That delays the program and still doesn’t prevent churn if the product direction is wrong for the account.

Low value / Easy to migrate
This is where you either build leverage or you drown. If you expect to migrate hundreds of accounts, self-serve needs to feel like a product: tooling, templates, validation checks, webinars, office hours, automated reminders. If the process is clunky, customers churn, and support load collapses the economics.

These accounts are also good candidates for implementation partners. The best versions of this look like a “factory model” where partners run standardized migrations using approved patterns, while you keep the complex edge cases inside.

Low value / Difficult to migrate
Triage early. Offer a simplified migration path with reduced scope and clear boundaries, or offer an end-of-life timeline and clean data export. Avoid bespoke rebuilds unless the customer’s economics change in a meaningful way. This is where “saving everyone” quietly turns into technical debt, support drag, and roadmap pollution.

Step 3: Give every function rules, not improvisation

Migration breaks when customers hear one story from sales, a different story from customer success, and a third story from support. The fix is not “alignment.” The fix is policy.

Each function needs a defined playbook and escalation path:

• Sales: offer rules, approvals, ownership, comp treatment, scripts

• Marketing: comms plan, cohort campaigns, reassurance assets

• Pricing and packaging: mapping policy, time-bound concessions, milestone-based incentives

• Customer success: segment-based success plans, churn-risk heatmap, sponsor model

• Services: standard assessment/SOW, repeatable cutover checklist, capacity plan

• Onboarding: standard vs complex tracks, consistent “go-live” definition

• Support: legacy ticket policy during sunset, migration troubleshooting guides, escalation criteria

If you want a single practical habit that prevents panic later, publish the sunset timeline and migration paths early, then run weekly governance against a scoreboard. Most late-stage fire drills are just delayed decisions showing up with interest.

Why AI changes the migration calculus

Pre-AI, running two platforms was expensive but tolerable. Post-AI, it is value-destructive.

Every quarter you delay migration is another quarter where:

• Your models train on split datasets (Platform A users plus Platform B users)

• Workflow patterns fail to generalize across the full base

• AI features ship to one platform but not the other, fragmenting adoption, feedback, and ROI proof

The companies moving fastest on AI-driven consolidation are the ones that treat migration as a data unification project, not just a cost play. The goal is to get to one set of workflows, one set of signals, and one feedback loop that improves product quality over time.

A subtle blocker here is data quality. If your CRM and telemetry cannot reliably tell you who is on what version, what integrations exist, and who owns the relationship, your segmentation and forecasting become storytelling. AI raises the penalty for that sloppiness because it amplifies the cost of fragmented signals.

The talent angle most teams mishandle

Most deals assume cost synergies in engineering and support. That’s real, but the sequencing matters. During migration, you often need more capacity, not less. And the acquired teams tend to be the people who know Platform B best, which makes them uniquely valuable at exactly the moment they are most likely to disengage.

Acquired engineering and support teams are often emotionally attached to Platform B. If you announce a sunset without a transition plan for those teams, you get:

• attrition of the people who know the legacy platform best, exactly when you need them for migration support

• passive resistance, slow-walking migration, because it feels like sunsetting their work

• knowledge loss, undocumented edge cases that surface mid-migration

The fix is to treat talent like part of the migration plan, not a post-close clean-up step:

• Give acquired teams a clear role in the migration program (they become migration SMEs, not legacy maintainers)

• Pair them with Platform A engineers, so knowledge transfers in both directions

• Create retention packages tied to migration milestones, not just time served

• Make the “after” explicit: a path to meaningful work on the go-forward platform once migration is complete

Then rationalize. Once the platform is unified and the runbooks are stable, you can cherry-pick the strongest talent and take costs out without risking the program.

Some first-hand insights

If the playbook above is the structure, these are the things that determine whether it survives first contact with real customers.

1) Migration economics degrade fast if the timeline stretches

Dual infrastructure costs, split engineering attention, and customer uncertainty don’t just linger. They drag down NRR and roadmap velocity, and they turn renewals into negotiations.

2) Gross retention is the wrong obsession

The real question is: which customers will be healthy on the go-forward platform? For bad-fit accounts, forcing migration often just delays churn while consuming disproportionate support, customer success, and product time.

A contrarian point that’s often true in practice: it is fine if some low-value, high-cost customers churn to a competitor. If they require heavy bespoke work to recreate a legacy setup, they are likely to remain support-heavy even after they migrate. Let them become someone else’s headache, and protect your team’s capacity for the customers who can scale on the new platform.

Give them a clean exit: data export, documentation, a clear timeline, and no drama.

3) Migration velocity is an incentives problem as much as a tooling problem

Most teams over-index on “build the importer” and under-invest in the sticks and carrots that make it rational for customers to move early.

Carrots that work because they reduce risk and create urgency:

• Time-bound pricing incentives (migrate by X, keep legacy pricing for 12 months, or 10 to 15% off for 12 months)

• First-party white-glove migration packages for high-value cohorts (with clear scope and success criteria)

• Priority support queues and named technical contacts during cutover

• Concessions tied to completion milestones (cutover complete, adoption stable), not open-ended discounts

• Partner SPIFFs or MDF boosts tied to migrated customers, when partners are part of the factory model

Sticks that work because they create certainty, not hostility:

• Published end-of-support dates for bug fixes, security patches, and technical support on the legacy platform

• A maintenance-only posture on legacy, with new capabilities shipping only on the go-forward platform

• Compliance posture changes as standards evolve (legacy no longer meets updated requirements after a date)

• Operational limits (reduced SLA tiers or escalation paths after specific dates)

4) You need a weekly scoreboard that shows friction before churn shows up

Track by quadrant:

• Migration completion rate

• Time-to-first-value post-cutover

• Support tickets per migrated customer versus baseline

• Activation at 30 days

• Churn and NRR for migrated cohorts versus those still on legacy

If time-to-first-value stretches or tickets spike, speed is not your friend. Pause, fix the process, then resume.

Pricing tends to decide migration velocity. Time-bound incentives create urgency. Temporary legacy pricing reduces sticker shock. But open-ended grandfathering and surprise repricing at cutover both create the same outcome: delay, resentment, and churn.

Concluding thoughts

We’re likely to see more of such consolidation M&A moves, not fewer, in the next 12 to 18 months.

As SaaS growth stays uneven and valuations remain anchored, consolidation will continue to look like the most controllable path to scale, margin expansion, and AI readiness. But the gap between deals that look good on paper and deals that actually work in practice is going to widen. The difference won’t be creativity in the investment thesis. It will be realism about migration.

The teams that get this right are already shifting the work left. They’re pressure-testing migration during diligence, not after close. They’re asking how much of the base can actually move, what it will cost, where churn is acceptable, and how long dual-stack really lasts once customer behavior and internal incentives are factored in. That discipline shows up directly in valuation, synergy timelines, and the credibility of the EBITDA bridge.

In a market where returns increasingly come from execution rather than growth, migration isn’t an integration detail. It’s the deal.

If you’re buying, building, or integrating in this space, I’d love to compare notes.

You can reach me at faraaz@inorganicedge.com or on LinkedIn.