Every so often a project you hold a token from announces that the token is changing. A new contract is going live, and holders are asked to swap their old balance for the new one before some cutoff date. This is called a token migration, and it is a normal, sometimes necessary part of a project's life. It is also one of the more convincing disguises a scam can wear, because it borrows the exact language and steps that a real migration uses. Knowing how the legitimate version works is the best way to catch the fake one.
Why a project migrates in the first place
Smart contracts are usually immutable once deployed. A team cannot just edit the original token contract to fix a bug, change its supply mechanics, or move it to a different chain. If something about the original contract needs to change in a way the contract itself cannot support, the only option is to deploy a new contract and move holders over to it.
Common reasons include a security flaw discovered in the old contract, a decision to redesign tokenomics such as supply or fee behavior, consolidating multiple versions of a token into one, or relaunching on a different network. None of these are inherently suspicious. What matters is how the move is carried out and verified.
How a legitimate migration usually works
Most migrations follow one of two patterns.
In a burn and mint migration, you send your old tokens to a migration contract, which either burns them or locks them permanently, and mints an equivalent amount of the new token to your wallet in the same transaction. In a claim based migration, the team takes a snapshot of every holder's balance at a specific block, and the new contract lets each address claim its allotted amount of the new token, sometimes without you needing to touch the old token at all.
A well run migration usually shares a few traits. The new contract address is published on the project's official channels and, ideally, cross posted somewhere that would be hard for an attacker to also compromise, such as a verified social account and the project's own documentation. The contract is verified on Basescan, so its source code is readable rather than a black box. There is a public swap ratio, most often one to one, stated clearly and consistently everywhere it is mentioned. There is usually a migration window measured in weeks or months, not hours, because rushing holders is not something a project confident in its process needs to do.
What a fake migration tries to get you to do
A scam migration copies the surface details, a countdown, an official looking announcement, a slick landing page, but changes what actually happens when you interact with it. The most common versions ask you to approve an unlimited spending allowance on your old token to a contract that then drains it, ask you to send your old tokens directly to a wallet address rather than a contract, claiming the swap happens automatically afterward, or link to a site that looks like the project's but sits on a copycat domain, often one character off from the real one.
The tell is usually urgency paired with an unusual request. A real migration contract does the swap for you in a single transaction you can inspect beforehand. It never needs you to send tokens to a plain wallet address and wait, and it never needs a spending approval larger than the balance you are actually migrating.
How to check a migration before you touch it
Before approving or sending anything, pull up the migration contract on a block explorer and confirm it is verified, so you can at least see what the code claims to do. Compare the contract address across two or three independent official sources rather than trusting a single link, since a compromised social account or a sponsored search result is exactly how many of these scams start. Read what you are being asked to sign. If a wallet prompt shows an approval for an amount far larger than your actual balance, or for a token you were not expecting to interact with, stop and look closer. If you can, use Simple Base Swap or another interface that lets you simulate the transaction first, so you can see the expected outcome before it is final.
It also helps to remember that a migration deadline, if it is real, is rarely as tight as it is made to feel. Projects that are serious about the process build in months of overlap, and most will honor late claims through a separate process even after a soft deadline passes. There is very little a real project needs from you in the next ten minutes.
The simple rule
A migration should always move tokens into your wallet, not just out of it, and it should happen through a contract you can verify, not a plain address you are asked to trust. If either of those is missing, treat the request the same way you would treat any other unsolicited transfer instruction, with default skepticism until you can confirm it through more than one independent source.