A token migration announcement tends to produce the same three questions in every holder who reads one: do I have to do something, is there a deadline, and what happens to my tokens if I ignore this? The announcements themselves rarely answer cleanly. They talk about "upgrading to the new contract" or "transitioning to mainnet" as if the token were a piece of software receiving a patch — which is exactly what a token is not.
A token migration is the process of moving holder balances from one token contract to another, or from one blockchain to another. The original token doesn't change. It can't — that's the whole reason migrations exist. What actually happens is that a new token is created and the project orchestrates a coordinated swap out of the old one. Understanding that distinction answers most of the practical questions on its own.
One scoping note: a migration is not a fork. A fork splits a chain's history into two live versions, covered in what happens during a blockchain fork. A migration replaces one token with another, deliberately, with the old one intended to die.
Why Migrations Happen at All
The forcing function is immutability. Once a token contract is deployed, its code is fixed — as covered in can smart contracts be changed, there's no edit button. So when a project needs its token to be something the current contract can't be, deployment of a new contract is the only path. Three situations produce most migrations.
The first is the mainnet launch. Many projects launch their token as an ERC-20 on Ethereum before their own blockchain exists, because issuing on Ethereum is cheap and the infrastructure is ready-made. When the project's own chain goes live, the placeholder token migrates to become the native coin. BNB did this. So did TRON and EOS. The ERC-20 was always scaffolding.
The second is a contract upgrade or redesign. The token works, but the project wants new functionality — a different standard, fixed supply mechanics, staking hooks, or a repaired vulnerability. Polygon's MATIC-to-POL transition is the recent reference case: same ecosystem, new contract with different capabilities.
The third is consolidation. Projects merge, and their separate tokens collapse into one. The 2024 merger of Fetch.ai, SingularityNET, and Ocean Protocol into a single ASI token is the largest example to date — three communities, three contracts, one destination token at fixed conversion ratios.
The Mechanism: How Balances Actually Move
Since the old contract can't push balances anywhere, every migration is some arrangement of burn-and-mint. The project deploys the new token, then provides a path for holders to exchange old for new — almost always at a fixed ratio, usually 1:1. The variations are about who does the work.
Swap contracts are the self-custody path. The project deploys a migration contract; you send old tokens in, and it sends new tokens back. The old tokens are either burned outright or locked permanently in the contract, which is functionally the same thing — supply of the old token shrinks as supply of the new token enters circulation. If you hold tokens in your own wallet, this is usually the route you'll take, and it's the only step where you actively do anything.
Exchange-handled conversion covers everyone else. Custodial platforms typically perform the swap on behalf of users — balances are converted automatically on an announced date, and depositors wake up holding the new ticker. This is why migration announcements often say "no action required for exchange users." It's true, but it's worth noticing what it means: the convenience exists because the exchange controls the keys, not because the migration is automatic at the protocol level.
Snapshot and distribution handles cases where an active swap isn't practical — typically cross-chain migrations. The project records every holder's balance at a specific block height, then issues the new token on the destination chain to matching addresses or through a claim portal.
Whichever route applies, the accounting is the same: old supply retired, new supply issued, ratio fixed in advance. If the ratio is anything other than 1:1, that's a redesign decision worth reading closely, not a technical detail.
Where the Risk Actually Sits
The mechanism is simple. The risk is almost entirely in coordination and timing.
Deadlines are the sharp edge. Some migrations keep the swap open indefinitely; others sunset it, after which unmigrated tokens are stranded — still in your wallet, still technically yours, but no longer convertible and no longer listed anywhere. The difference between those two policies is the difference between "migrate whenever" and "this is a use-it-or-lose-it window," and projects don't always make it prominent.
The scam surface is the other edge, and it's predictable enough to plan for. Every significant migration produces a wave of fake swap portals, fake support accounts, and fake "migration assistance" messages — because a migration is the one moment a legitimate project genuinely is asking holders to interact with a new contract. That's ideal cover. The attack pattern is the standard one covered in how to protect against phishing in crypto, but migration windows concentrate it. The only reliable defense is sourcing the swap contract address from the project's verified channels and nothing else. No legitimate migration ever requires your seed phrase.
There's also a quieter market-structure effect: during the transition window, both tokens can trade simultaneously on different venues, with liquidity fragmenting between them. Price discrepancies between old and new versions during this period are usually plumbing, not signal.
What's Changing
Migrations of the "we deployed something we now regret" variety are slowly becoming less common, because upgradeable proxy patterns let newer projects modify token behavior without redeploying — a trade-off against immutability with its own trust costs. Working in the other direction, token consolidations and cross-chain repositioning are becoming more common as projects merge or follow liquidity to other ecosystems. The migration mechanism isn't disappearing; the reasons for using it are shifting.
Confirmation, Invalidation, Timing
Confirmation that a migration is proceeding healthily: swap volume moving steadily through the official contract, major exchanges announcing support and conversion dates, old-token liquidity winding down on schedule.
Invalidation: exchanges declining to support the new token, the swap contract being exploited or paused, or large holders conspicuously not migrating — any of these suggests the coordination layer is failing even if the code works.
Now: if you hold a token announcing a migration, the first fact to establish is whether the swap window closes. Next: exchange conversion dates and the wind-down of old-token liquidity. Later: stranded-token cleanup and whatever long tail of unclaimed balances remains.
Boundary
This explains the mechanism by which token balances move from one contract or chain to another. It is not a view on whether any particular migration improves a token's design, not guidance on whether to hold through one, and not a review of any specific project's transition. Migration mechanics are neutral. What a project does with the opportunity is a separate question, and it's the one that actually matters.
