Upgrade and Migration Failure

How it happens

Networks change consensus rules through coordinated upgrades that node operators must adopt within a window, and issuers migrate holders from an old token contract to a new one through a swap. Both depend on people acting: operators upgrading in time, exchanges and custodians crediting the new asset, integrators repointing to new addresses. If adoption is partial, two versions of the ledger or two versions of the token circulate at once, each with its own price, liquidity, and claim to the name. Migration deadlines separately strand holders who are inattentive, who hold through an intermediary that ignores the swap, or whose tokens sit inside a contract that cannot be told to move them.

What you can actually observe

Read the activation mechanism and the share of nodes or stake signaling readiness before the fork block, and read client release notes, public testnet runs, and shadow-fork results to see how much rehearsal happened. For a token migration, check whether the old contract still has supply outstanding, whether the swap has a hard deadline, and which venues and custodians have confirmed support. After the event, a persistent minority chain or a lingering old-contract balance is an observable fact rather than a forecast.

Precedent

Ethereum's 2022 Merge moved the network from proof of work to proof of stake without halting the chain after extended testnet rehearsal, while the 2016 DAO fork is the counterexample, producing two chains that both persist to this day.

What makes it more or less material

Look at how many independent client teams must ship the change, whether the upgrade is backward compatible, whether a rollback path exists, how much value sits in contracts that cannot be migrated, and how concentrated the operator set is.