Token Migration Checklist: How to Swap Contracts or Move Chains Safely

A token migration is the process of moving holders from an old token contract to a new one, either on the same chain (a contract swap) or on a different chain. To do it safely, you need to settle why you are migrating, design a one-way swap that holders can actually use, coordinate every exchange and liquidity venue before the swap opens, communicate through official channels only, and monitor the migration until the old token is effectively dead. This checklist covers each stage in order, with the mistakes that most often turn a routine upgrade into a support and security headache.

Should You Migrate at All?

Migration is expensive and risky: it asks every holder to act, it gives scammers a ready-made pretext, and it fragments liquidity for as long as two tokens exist. Do it only when the reason is strong. Common legitimate reasons:

• A critical bug or vulnerability in the original contract that cannot be patched.
• A tokenomics change that the old contract cannot support, such as new mint, burn or vesting logic.
• A move to a different chain where your users, liquidity or ecosystem support are.
• A rebrand or corporate restructuring that requires a new token identity.

If the aim is simply to be available on more chains, a native multichain deployment or a bridge may be better than a full migration. We compare the options in multichain token deployment: native vs bridged.

Phase 1: Planning

• Write down the reason for migration and the success criteria (for example, a target percentage of supply migrated by a given date).
• Decide the ratio. One-to-one is simplest and least confusing. Any other ratio needs a clear explanation and affects every price, balance and listing field.
• Decide whether the supply is fixed or whether new tokens can be minted. A migration is not an opportunity to quietly change supply; any change should be public and explained.
• Decide the deadline policy: a hard end, a long open window, or an indefinite swap. Open-ended swaps keep a standing attack surface alive.
• Decide what happens to locked and vested tokens. Vesting contracts, staking contracts and investor allocations all need a migration path of their own.
• Map every place the old token lives: exchanges, DEX pools, lending markets, bridges, custody providers, multisigs, staking contracts and vesting contracts.
• Assign an owner for each workstream and agree who has authority to pause the process.

Phase 2: Building the Swap

Contract design

• The new token contract is audited before any holders are asked to touch it. See smart contract audits before launch for scoping.
• The swap contract is audited as a separate component. It holds or burns value and is a high-value target.
• The swap is one-way and handles the old token in a defined way (burn, lock or escrow). Be explicit about which.
• Admin keys for the swap contract sit behind a multisig with sensible thresholds, and the ability to pause is documented. Custody options for token teams covers how to set this up.
• Test the full flow on a testnet, including edge cases: tiny balances, contract wallets, tokens held in staking or vesting.

Supply reconciliation

• Reconcile the old token's total supply against the new token's minted or reserved supply, and publish the numbers.
• Decide how unmigrated tokens are treated and whether the new supply is held in reserve for them.
• Keep a record of burned or locked old tokens so that circulating supply remains verifiable at every point.

Phase 3: Exchange and Venue Coordination

This is the stage that most often goes wrong, because the project controls the contract but not the venues.

• Contact every exchange listing the token, well before the announcement. Give them contract addresses, the migration plan and a timeline.
• Ask each exchange how it will handle the swap: will it perform the swap on behalf of users, suspend deposits and withdrawals, or require users to withdraw and swap themselves? Procedures differ, and some require notice periods.
• Agree the trading and deposit/withdrawal suspension windows in writing, and ensure they match the announcement.
• Confirm ticker and listing continuity: does the new token keep the symbol, or will it temporarily trade under a different one?
• Update data aggregators and trackers with the new contract and supply. The process is similar to the one in how to get listed on CoinGecko and CoinMarketCap.
• Tell your market maker early. They hold inventory in the old token and need to know when to swap it, when to pause quoting and when to restart. Build this into the plan rather than discovering it on swap day.
• If any exchange refuses or delays the swap, decide in advance how you will handle that venue. Projects that mismanage a migration can end up with a venue that holds a worthless old token, a situation that sometimes ends in a delisting. See why crypto exchanges delist tokens.

Phase 4: Liquidity Planning

Migration splits liquidity in two for a while. Plan for it deliberately.

• Decide when the old DEX pools are withdrawn and when the new pools are created. Withdrawing too early leaves holders unable to exit; too late keeps the old token tradable and confusing.
• Fund the new pools to a depth that matches the old market. The reasoning in how much liquidity a token needs at launch applies again.
• If you own liquidity positions, your migration plan should account for them. Protocol-owned liquidity positions need to be removed, swapped and redeployed under your custody controls.
• Decide on liquidity locks for the new pools and communicate them. See how to lock liquidity at token launch.
• Think through price continuity between the old and new tokens. If one trades at a discount to the other during the transition, arbitrageurs will close the gap, but only if the swap is easy and open.

Phase 5: Communication and Security

Migrations are a favourite pretext for phishing. Holders are being asked to approve contracts and connect wallets, which is exactly what scammers do.

• Publish the plan on official channels only and pin it. Use one canonical page for contract addresses and swap instructions.
• Announce clearly what the project will never do: ask for seed phrases, send direct messages with swap links, or run a swap on any site other than the official one.
• Prepare a step-by-step guide with screenshots for the swap.
• Moderate community channels closely during the migration. Remove impersonators and fake support quickly.
• Provide a support route for holders who hold tokens in exchanges, hardware wallets, or contracts.
• Brief your team so that nobody answers questions with improvised information that contradicts the plan.
• Consider a staged rollout for high-risk holder groups, such as investors with large allocations, so that issues are found early with a smaller group.

Phase 6: Execution

• Run a final check on addresses, ratios and permissions immediately before launch.
• Open the swap at the announced time, with the team monitoring the contract and community channels live.
• Verify the first swaps on-chain yourself before encouraging others.
• Update your official website, docs, token lists and explorers with the new contract as soon as the swap is live.
• Keep a clear incident plan with a decision on when to pause and who can call it.

Phase 7: After the Swap

• Track the percentage of supply migrated daily and share the progress.
• Follow up with large unmigrated holders directly where possible.
• Watch for scam contracts that mimic the new token, and report them.
• Monitor the old token's remaining activity. If it still trades, make sure exchanges and aggregators label it correctly.
• Decide when to close the swap window and announce it with notice.
• Publish a final report: migrated supply, remaining supply, burned or locked tokens and any issues encountered.
• Review spreads and depth on the new token for at least several weeks. A migration can quietly worsen liquidity even when the swap itself went well.

Common Mistakes

1. Telling exchanges too late. Many have processes that need lead time, and a rushed swap risks suspended markets.
2. Forgetting vesting and staking contracts. Locked allocations are easy to miss and hard to fix afterwards.
3. Leaving the swap open indefinitely. A permanent swap contract is a permanent target.
4. Unclear communication. Multiple posts with conflicting details create the confusion that scammers rely on.
5. Ignoring market making. A market maker with stranded old-token inventory cannot quote properly, and spreads widen exactly when attention is highest.
6. Treating it as a technical project only. The hard parts are coordination and trust, not the contract.

Migration Is a Launch in Disguise

For holders and exchanges, a migration looks a lot like a second token launch: new contract, new liquidity, new listings, a new security perimeter. Projects that treat it with the same discipline as a TGE tend to handle it well. Fibonacci Capital supports token teams with launch liquidity, exchange coordination and market making through transitions like this one, so if you are weighing a migration, talk to us before you set the date.