The 6 Signals a Forced Migration Is Going Badly

Every forced migration produces a complaint spike. That part is not a signal, it is arithmetic: you moved people who did not ask to be moved, and some of them will say so. The spike is expected, and treating it as the diagnosis is why teams spend the first three weeks of a migration arguing about whether the reaction is normal. The diagnosis is not the spike. It is what the curve does after it.

The six signals a forced migration is going badly are: complaint volume plateaus instead of decaying, the language shifts from cannot find to cannot do, contact rate per migrated account stays flat past week three, complaints concentrate in one segment, users report building workarounds outside your product, and requests for the old behavior rise after cutover. Each is measurable from feedback you are already receiving. Together they answer the only question that matters mid-migration, which is whether to continue, extend, or roll back.

How to read a migration curve

1. Decay rate over peak height. A healthy migration produces a sharp spike that decays substantially within two to three weeks as users learn the new path. A failing one produces a lower spike that does not decay. Peak height measures disruption. Decay rate measures whether the new thing actually works.
2. Taxonomy adaptiveness. Can your system distinguish a navigation complaint from a capability complaint automatically, in language nobody predicted? Migration feedback arrives in vocabulary that did not exist before cutover, and a taxonomy authored pre-migration files all of it under one bucket. An adaptive taxonomy surfaces the new theme as it forms, which is the difference between a week-two diagnosis and a week-eight one.
3. Context depth. Are complaints tied to segment, plan tier, and account value? Migration pain is almost never uniform, and the aggregate curve hides the segment that is actually failing.
4. Cohort comparability. If you are rolling out in waves, can you compare wave two's curve to wave one's? That comparison is the cheapest signal available and most teams do not set it up.

The differentiator is granularity over speed. Knowing complaint volume doubled tells you nothing you did not expect. Knowing which capability complaint is not decaying in which segment tells you what to fix.

The 6 signals a forced migration is going badly

1. Complaint volume plateaus instead of decaying

Plot migration-related feedback daily from cutover. The expected shape is a spike within 48 hours followed by meaningful decay across two to three weeks. A plateau means users are not adapting, they are repeatedly hitting the same wall.

How to measure it: complaints per thousand migrated accounts, by day, with a decay rate calculated weekly. If week three is not materially below week one, the migration is not landing.

Severity: highest. This is the master signal and the other five explain it.

2. The language shifts from "cannot find" to "cannot do"

Early migration complaints are navigational: where did X go, how do I get back to Y. Those decay on their own as users relearn. Capability complaints do not, because no amount of familiarity restores a function that is missing.

How to measure it: split migration complaints into navigation and capability themes and trend the ratio. A rising capability share is the signal, even when total volume falls.

Severity: high. A falling total volume with a rising capability share is the most commonly misread pattern in a migration, because the headline number looks like recovery.

3. Contact rate per migrated account stays flat past week three

Normalize support contacts by the number of migrated accounts rather than counting raw tickets. Raw counts rise as you migrate more people, which makes every wave look worse and tells you nothing.

How to measure it: contacts per migrated account per week, compared against the pre-migration baseline for the same population. A return toward baseline by week four is healthy. Flat elevation is a permanent cost you have just added to support.

Severity: high, and it is the signal finance will eventually notice on its own.

4. Complaints concentrate in one segment

Check whether migration pain clusters by plan tier, company size, region, integration, or workflow. Aggregate curves routinely look acceptable while one segment is failing completely, and the segment that fails is frequently the one with the most customization on the old system.

How to measure it: the same decay curve, split by segment, with revenue attached through a customer context graph. A concentrated failure in a segment worth 20% of ARR is a different decision than a diffuse one.

Severity: high. This signal changes what you do rather than whether you worry.

5. Users report building workarounds outside your product

Watch for feedback describing exports to spreadsheets, manual re-entry, scripts, or keeping a parallel process alive. A workaround is a customer solving your migration problem at their own cost, and it converts an active complaint into silent dissatisfaction, which is worse because the complaint stops arriving.

How to measure it: a workaround theme in your taxonomy, trended from cutover. Volume is usually low and significance is high, so read the verbatims rather than watching the count.

Severity: medium-high, and badly underweighted because the metric looks small.

6. Requests for the old behavior rise after cutover

Distinguish two things: complaints about the migration, which decay, and requests to restore specific old behavior, which do not. Sustained restoration requests weeks after cutover mean the new system is missing something real, not that users are nostalgic.

How to measure it: trend feature requests naming the old system or old behavior. If they are still arriving at week six, the gap is genuine, and the honest response is to build it rather than to keep explaining the new path. When you do close it, tell the people who asked, using the approach in telling customers the feature they requested shipped.

Severity: medium-high. This is the signal that most often turns out to be correct.

Why the decay curve is the whole diagnosis

A migration is a forced change, and forced change produces a predictable emotional response that has nothing to do with product quality. Research on the abrupt transition from GPT-4o to GPT-5 documented exactly this: users framed the change as a loss, at markedly different rates across language groups, and the backlash was steepest where attachment had formed and no overlap period was offered. Some share of your complaint spike is that, and it will decay on its own.

Which is why the decay rate, not the volume, carries the information. Adjustment complaints decay because adjustment happens. Capability gaps do not decay, because nothing about the passage of time restores a missing function. Separating the two is a classification problem, and it is the only reliable way to know whether you are watching a migration land or a migration fail.

That framing also settles the internal argument. Mid-migration, product reads the falling total volume as recovery and support reads the sustained contact rate as failure, and both are looking at real data. The reconciliation is the split: total volume is falling because navigation complaints are decaying, and contact rate is flat because capability complaints are not. Once the two themes are separated, there is nothing left to argue about, only something to build.

Worth naming the limit: none of these signals sees the customer who migrated, disliked it, said nothing, and started evaluating alternatives. For that population you need public channels and cancellation reasons, which is the same blind spot described in diagnosing a broken customer feedback loop.

How to decide whether to continue, extend, or roll back

Run the checks in this order and let them decide.

Split navigation from capability. If capability complaints are under a quarter of migration feedback and falling, continue. This is a communication and enablement problem.

Check the decay rate at week three. Materially below week one, continue. Flat, stop migrating new waves while you diagnose. Rising, pause the rollout.

Split by segment. A concentrated failure means extend the timeline for that segment rather than pausing globally. Segment-specific extensions are cheap. Global pauses are expensive and they signal indecision to everyone who already migrated successfully.

Count restoration requests at week six. Still arriving in volume means a real gap. Build it, and stop treating it as an adoption problem.

Roll back only on capability plus concentration plus revenue. A rollback is justified when capability complaints are not decaying, the failure concentrates in a segment carrying meaningful revenue, and no migration path exists for that segment. Two out of three is an extension, not a rollback.

The decision rule: weight non-decaying capability complaints over total volume, and weight revenue-weighted concentration over complaint count. The migration that looks worst in aggregate is often fine, and the one that looks acceptable in aggregate is often failing in one place that matters.

Plot your daily migration complaint curve and split it into those two themes. If you cannot split it, that is the first thing to fix, because every other number here is uninterpretable without it.

FAQ

How long should migration complaints take to decay?

Expect a spike within 48 hours of cutover and meaningful decay across two to three weeks as users relearn workflows. By week four, contact rate per migrated account should be trending back toward its pre-migration baseline. Flat elevation past that point is a permanent cost rather than a transition cost.

How do I tell adjustment complaints from real problems?

Read the verb. Cannot find, where did it go, and how do I get back are adjustment complaints and they decay. Cannot do, no longer supports, and there is no way to are capability complaints and they do not. Trend the ratio rather than the total.

When should you roll back a migration?

When capability complaints are not decaying, the pain concentrates in a segment carrying meaningful revenue, and no migration path exists for that segment. If only one or two of those hold, extend the timeline for the affected segment instead. Global rollbacks are expensive and they undermine the users who already adapted.

How does Enterpret help monitor a migration?

Enterpret's adaptive taxonomy surfaces migration themes as they form, in the language customers actually use after cutover, so navigation and capability complaints separate without anyone defining categories in advance. The customer context graph attaches segment, plan tier, and revenue to each complaint, which is what reveals a concentrated failure hiding inside an acceptable aggregate curve.

Should we run migrations in waves or all at once?

Waves, when you can, specifically because they give you a comparison. Wave one's decay curve is the baseline that makes wave two's curve interpretable, and a wave that performs worse than its predecessor is a clear stop signal that a single cutover never produces.

If you are mid-migration and cannot tell adjustment from failure, see how Enterpret's adaptive taxonomy separates the two as complaints arrive.

‍