Wallet Migration: Moving Without a Window of Exposure

A wallet migration is a sequence of state changes, not one transfer. That distinction matters, because each step leaves a short interval in which the old key and the new key can both sign, and a careful wallet migration is mostly about closing those intervals in the right order.

Most people describe a wallet migration as copying twelve words into a new app. The balance does not move at that moment. What changes is which key controls it, and how many copies of that key exist while the change is in progress.

• Move the key, not the coins. A migration changes signing authority. The on-chain balance stays where it was unless you deliberately sweep it.
• The exposure window is the interval when two wallets can both authorise spending. Shorten it, and watch it while it is open.
• Restore before you trust a backup. One signed transaction from the restored wallet proves the written copy is complete.
• Permissions outlive apps. Token approvals and connected sites follow the address, so they need their own cleanup pass.

What a wallet migration actually changes

A migration changes three things: where the private key lives, which addresses you watch, and which applications hold permission to act for you. Only the first is obvious, and the other two generate most of the cleanup work afterwards.

Keys are the account

An address is derived from a public key. Holding a token “inside” a wallet is never literal — the ledger records a balance against the address, and the key is the only thing that can instruct a change to that balance. This is why a migration can be prepared with a paper backup and no network connection, and why a leaked key cannot be repaired by reinstalling software.

The three objects that must arrive in the new wallet

A migration is finished only when all three of these are true in the destination, not just the first one.

• The signing key. Seed phrase, private key, or hardware device, restored and confirmed by an actual signature rather than by the app’s own display.
• The account list. Every address derived under that key, including accounts you added later and any address that received a transfer from an exchange.
• The permission list. Token approvals, connected sites, and any standing authorisation that names your address as the spender.

The first is checked in minutes. The second is checked by comparing address lists side by side. The third is usually forgotten, and it is the part that stays live after the migration looks complete.

Where migration plans fail

Failures cluster around three moments: the gap between writing a backup and verifying it, the period when two devices hold the same key, and the assumption that moving funds also moves permissions.

The unverified backup

A seed phrase written down but never used is a guess. People transpose two words, drop an optional passphrase, or copy the words in a different order, then discover the error months later when the original device fails. The only reliable test is restoration: open a clean profile or a spare device, restore from the written copy alone, and sign something small. If that signature appears on-chain, the backup is real.

A backup you have never restored from is a hypothesis. A migration that skips the restore step is a hypothesis with a deadline attached.

The overlapping-device period

During a migration both the old and the new wallet hold the same key, often for days. That overlap is the exposure window. It is not catastrophic on its own, but it doubles the number of places where a compromised machine, a malicious browser extension, or an observed screen can cost you the account. Treat it as a countdown rather than a background task.

Permissions that stay behind

Token approvals are stored by each token contract and name your address as the spender. Installing a different app does not revoke them. If you are migrating because a device may be compromised, every approval tied to that address remains usable until you revoke it explicitly or move the balance to an address with a fresh key.

Comparing the main migration routes

There is no single correct route. The choice depends on why you are migrating: a software change, a device upgrade, or a suspicion that the key is exposed.

Two rows deserve emphasis. A seed restore is the fastest route and the weakest one, because it ends with the same key in more places than it started. A sweep is slower and costs network fees, but it retires the old key instead of duplicating it.

Running a wallet migration without a live window

The sequence below keeps dual authority as brief as the network allows. It assumes a sweep to a new address, which is the route that ends with the old key genuinely retired.

1. Prepare the destination offline. Generate a new wallet on a device that has never held the old key, write the backup, restore it once, and confirm the addresses match.
2. Record the inventory. List every address, token balance, and approval attached to the old wallet before anything moves.
3. Fund the destination with a small amount of the native asset, so it can pay for its own future transfers.
4. Send one small test transaction and wait for confirmation. Never continue on a transaction that is still pending.
5. Sweep the token balances first, then the native asset last if the old address needs it to pay for those transfers.
6. Revoke approvals on the old address one contract at a time, and check each revocation rather than assuming it applied.
7. Disconnect the old wallet from every site that lists it, then remove it from those sessions.
8. Destroy the old key material: wipe the device, delete the imported key, and retire the written backup if you no longer need it.

Step eight is the one people skip, and it is the only step that actually closes the window. As long as the old key exists in any form, the exposure stays open regardless of what the balances show.