Hardware Wallet Seed Phrase Migration: Step by Step

When and Why to Migrate Your Hardware Wallet

Migrating Bitcoin between hardware wallets is one of the most security-critical operations you will perform as a self-custody holder. Whether you are upgrading to a newer device, switching manufacturers for better features, or replacing a wallet you suspect may be compromised, understanding the correct migration procedure is essential for protecting your funds throughout the transition.

There are several common scenarios that trigger a hardware wallet migration. Your current device may be approaching end-of-life, with the manufacturer discontinuing firmware support. You might want to upgrade to a device with better security features — perhaps moving from a USB-connected wallet to an air-gapped model, or from a closed-source device to one with fully auditable open-source firmware. In some cases, the motivation is simpler: your device is physically damaged, or you want to consolidate holdings from multiple wallets.

Regardless of the reason, the rule this guide follows is clear: move your coins, not your words. Restoring your words on a replacement device is normal recovery when a device breaks and the words were never exposed. If a device is lost or stolen, restore the wallet from your words and move the coins at once to a new wallet with fresh words, as Trezor advises: treat a missing device as a threat to your coins. For a planned migration, or whenever the old seed may have been exposed, generate a fresh seed on the new device and send your Bitcoin through a standard on-chain transaction from the old wallet to the new one. This approach ensures that the private keys on your new device have been generated in a verified, secure environment and have never existed on any other hardware.

Two ways to get to a new hardware wallet. Move the coins: the new device makes new recovery words, and the old wallet sends your coins to it in a normal transaction that pays a small fee to the miner. The old coins are spent and your coins now sit at new addresses, under keys that have never been anywhere else; the old words are never typed in. Copy the words: typing the old words into the new device gives it the same keys as before, so it opens the same coins at the same old addresses; the coins never move, and any leak of the old words comes along too. — **Move the coins, not the words.** Typing the old words into the new device copies the old keys: it shows the same coins at the same addresses, along with any leak those words ever had (tampered firmware, a photo, a typed copy). Fresh words and a normal transaction leave all of that behind, at the cost of a transaction fee.

Understanding Seed Phrases and Key Derivation

Before diving into the migration process, it is important to understand what your seed phrase actually represents and why it should not be reused across devices. A BIP39 seed phrase — your 12 or 24 recovery words — is a human-readable encoding of a master entropy source from which all your private keys are mathematically derived.

The derivation process is hierarchical and deterministic: from the master seed, a series of child keys are generated according to standardized derivation paths (like m/84’/0’/0’ for native SegWit addresses). Each derivation path produces a complete set of addresses and their corresponding private keys. This architecture means your single seed phrase controls every address your wallet has ever generated.

BIP39 passphrases add another layer to this system. When you add a passphrase (sometimes called the “25th word”) to your seed phrase, the combination produces an entirely different master seed, which in turn generates a completely separate set of addresses and keys. This means that the same 24-word seed phrase with different passphrases controls different wallets with different balances — a powerful feature for security and plausible deniability.

Understanding this structure is critical for migration because it explains why you need to account for all derivation paths and passphrases when moving funds. If you have used a passphrase to create hidden wallets, those wallets exist only when the correct passphrase is applied to the seed — and you must remember to migrate funds from each passphrase-derived wallet separately.

A grid of the wallets one old seed opens. Columns are the four address types, each with its own derivation path: Legacy (1…, m/44'), Nested SegWit (3…, m/49'), Native SegWit (bc1q, m/84') and Taproot (bc1p, m/86'). Rows are the base wallet with no passphrase and two hidden wallets, passphrase A and passphrase B. In this example coins sit in four cells: the base wallet's Legacy and Native SegWit addresses, passphrase A's Native SegWit and passphrase B's Nested SegWit; the rest are empty. A last row, a passphrase not in your notes, is all question marks. Address types: software finds them, as Sparrow's Discover Wallet, run with the old device plugged in, checks every address type, once per passphrase you enter. Passphrases: no tool finds them, because any text is a valid passphrase, so only your own notes can list the ones you used. Empty every cell with coins: here, one transaction from each of the four. — **Your old wallet is empty only when every one of these is empty.** Each passphrase opens a separate wallet, and inside each one every address type has its own addresses. Software can scan the address types for you; only your own notes can list the passphrases. The coins in this grid are an example.

Pre-Migration Checklist

Before beginning any migration, complete the following preparation steps to ensure a smooth and secure transition.

Verify your backup of the old wallet’s seed phrase. Even though you will not be importing this seed into the new device, you need a verified backup as a safety net in case anything goes wrong during migration. If you have not tested your backup recently, now is the time: run the old device’s built-in backup check, which compares your written words with the wallet on the device without erasing anything. Never type the words into a computer or phone.

Document all derivation paths and passphrases. Review your wallet configuration to identify every derivation path in use and every passphrase-protected wallet. Common derivation paths include m/44’/0’/0’ (legacy), m/49’/0’/0’ (nested SegWit), and m/84’/0’/0’ (native SegWit). If you have used your wallet with multiple software interfaces, different paths may have been used at different times.

Verify and update the new wallet’s firmware. Before you generate the seed you will fund, confirm the device is running authentic firmware from the manufacturer and install the current version, verifying it as the maker describes. Buy the device from the maker’s own store; if it came from a reseller, this check matters even more. An update fixes the device, not a seed it already made (see our guide to the Coldcard seed flaw), so if setup made you create a seed before updating, make a new one on the updated firmware before you fund it.

Initialize your new hardware wallet with a fresh seed. Set up the new device following the manufacturer’s instructions. Generate a new seed phrase, record it on a metal backup, verify the backup through the device’s built-in verification feature, and set a strong PIN. If you plan to use a passphrase on the new device, configure it now and record it securely. The backup check covers only the words, so before funding that wallet, note its first receive address, reopen the wallet by typing the passphrase from your written copy, and check that the device shows the same address.

Plan your transaction timing and fees. On-chain Bitcoin transactions require fees, and these fees vary based on network congestion. Check current fee rates and plan your migration for a period of low network activity if the fee savings are meaningful relative to the amount being transferred. For large amounts, the transaction fees are a small price to pay for proper security hygiene.

The fee for a migration is the size of the transaction times the fee rate. Each transaction sends everything to one address in your new wallet. Moving 1 coin from a bc1q address takes about 110 vB: 110 sats at 1 sat/vB, the usual rate in November 2026, or 1,100 sats if fees rose tenfold to 10 sat/vB. Moving 30 coins from bc1q addresses takes about 2,080 vB: 2,080 or 20,800 sats. Moving 30 coins from old addresses starting with 1 takes about 4,480 vB: 4,480 or 44,800 sats. Each coin adds about 68 vB from bc1q and 148 vB from a 1 address; the rest of the transaction is about 41 vB. — **The fee follows your coins, not the amount.** Each coin you move adds its own slice of space, and coins on old 1… addresses take about twice as much. Moving 1 BTC in one coin costs less than moving 0.01 BTC spread over thirty. Coins spent together are also linked publicly, so move coins you keep apart (from an exchange that knows you, from a peer-to-peer trade) in separate transactions.

The Migration Process Step by Step

With your preparation complete, the actual migration follows a straightforward process.

Step 1: Generate receiving addresses on the new wallet. Connect your new hardware wallet to your preferred wallet software (Sparrow Wallet is recommended for its excellent hardware wallet support). Generate a new receiving address and verify it on the hardware wallet’s screen. The address shown on the device screen is the source of truth — if it does not match what the software displays, do not proceed.

Step 2: Start with a small test transaction. From your old wallet, send a small amount of Bitcoin — enough to cover future transaction fees — to the new wallet’s verified receiving address. Wait for the transaction to confirm on the blockchain (at least one confirmation, preferably three to six). Then verify that the balance appears correctly in your new wallet.

Step 3: Verify you can spend from the new wallet. This step is crucial and often skipped. Send a small portion of the test funds to another address in your new wallet, not back to the old one, which you are emptying. This confirms that your new device can successfully sign transactions. It does not test your seed phrase backup, because the device signs with the copy stored inside it; the built-in backup check in the checklist above does that. If you cannot send from the new wallet, investigate before moving more funds.

Step 4: Transfer the remaining balance. Once you have confirmed that the new wallet can both receive and send, transfer the rest of your Bitcoin from the old wallet. Coins on several addresses in the same wallet can all go in one transaction, but each derivation path and each passphrase-protected wallet usually opens as a separate wallet in your software, so send a separate transaction from each. Use your wallet software’s coin control features if available to ensure you are sending from all relevant addresses. Coins spent in one transaction are linked publicly, so if you keep some coins apart, such as coins from an exchange that knows you and coins from a peer-to-peer trade, move each group in its own transaction (see UTXO Management and Coin Control).

Step 5: Verify the final balances. After all transactions have confirmed, verify that the full expected balance appears in your new wallet and that the old wallet shows a zero balance across all derivation paths and passphrases.

Five steps, with the old wallet drawn above the new one. 1 Check the address: read the new wallet's receiving address on the new device's own screen; that is the one that counts. 2 Send a test of 50,000 to 100,000 sats from the old wallet and wait for a confirmation; this proves the new wallet can receive. 3 Spend some: send part of the test to another address in the new wallet, not back to the old one; this proves the new device can sign. Only if both passed, go on. 4 Send the rest, from every wallet the old seed opens. 5 Check that each of those wallets shows zero and the new wallet holds everything. Receiving proves the address; spending proves the device can sign. Your words on metal are a separate check, the device's built-in backup check. — **Receiving proves the address; spending proves the device can sign.** A test that only receives can’t catch a device or setup that won’t sign. Neither test checks your backup: the device signs with the copy inside it, so check your words with its built-in backup check.

Handling BIP39 Passphrases During Migration

If you use BIP39 passphrases on your old wallet, migration requires extra care. Each passphrase creates a separate wallet with its own balance, and you must migrate funds from each one individually.

Start by listing all passphrases you have used with the old device. For each passphrase, access the corresponding wallet on the old device, verify the balance, and send the funds to the new wallet. If you plan to use passphrases on the new device as well, you can send funds from each old passphrase wallet to a corresponding passphrase wallet on the new device — but remember that the underlying seed phrases are different, so the same passphrase will generate different addresses on the new device.

A common mistake during migration is forgetting about a passphrase-protected wallet. Because there is no way to enumerate all possible passphrases (any text string is a valid passphrase, and each generates a valid wallet), you must rely on your own records. This is why maintaining clear documentation of your wallet structure is so important from the beginning.

After migration, do not immediately destroy the old wallet or its seed phrase backup. Keep them accessible for a reasonable period — several weeks to a few months — in case you discover a passphrase-protected wallet or derivation path that you overlooked. Only after you are completely certain all funds have been transferred should you securely dispose of the old device and its backups.

Script Types and Address Compatibility

When migrating between hardware wallets, especially between devices from different manufacturers or different generations, be aware of Bitcoin address type compatibility. Bitcoin has several address formats that represent different script types.

Legacy addresses (starting with 1) use Pay-to-Public-Key-Hash (P2PKH) scripts. In a single-key wallet, Nested SegWit addresses (starting with 3) use Pay-to-Script-Hash wrapping a SegWit script (P2SH-P2WPKH), and Native SegWit addresses (starting with bc1q) use Pay-to-Witness-Public-Key-Hash (P2WPKH). Taproot addresses (starting with bc1p) use Pay-to-Taproot (P2TR). An address starting with 3, or a 62-character one starting with bc1q, can also belong to a multisig wallet.

Your new wallet needs only one receiving address type, as long as your old wallet’s software can pay it: software that predates Taproot can’t send to a bc1p address. Native SegWit (bc1q) addresses offer the best combination of lower fees and broad compatibility and are the recommended default for new wallets. Taproot addresses offer additional privacy benefits but may not be supported by all wallet software and services yet.

If your old wallet used multiple address types — perhaps legacy addresses in its early days and SegWit addresses more recently — you will need to send transactions from each address type. Your wallet software should show balances broken down by address type, allowing you to verify that all funds have been accounted for.

Security Considerations After Migration

After completing your migration, several security steps finalize the transition. First, verify once more that the old wallet’s balance is zero across all address types and passphrases. Then consider what to do with the old device and its seed phrase backup.

The old device should be factory reset to clear all key material from its memory. If you plan to repurpose it — perhaps as a secondary signing device or for testing — a factory reset followed by fresh initialization is sufficient, as long as you still trust the device. If you are leaving it because you suspect tampering, destroy it: a reset clears the keys but can’t prove the hardware is clean. If you plan to dispose of it, a factory reset followed by physical destruction of the device provides the highest assurance that its key material cannot be recovered.

The old seed phrase backup presents a different consideration. The old addresses still accept payments, and if someone later sends Bitcoin to one of them (a rare but possible scenario, such as an exchange withdrawal saved to an old address), only the old seed can spend it. Before destroying the old backup, give every exchange, service or person that might still pay an old address a receive address from the new wallet. After that and a reasonable waiting period, most users can securely destroy it, so nobody who finds it later can open the old wallets. If you are particularly cautious, you can keep the backup in secure storage indefinitely as a safety measure.

Update your documentation and succession plans to reflect the new wallet configuration. If you have shared recovery instructions with family members or mentioned your bitcoin in a will or trust, update them for the new device. Record where the new seed backup and any passphrase are kept on a separate, sealed note, never in the will itself: in many places a will becomes public during probate.

A timeline from the day every old wallet shows zero to 2 to 3 months later. Old device: reset it today, then destroy it, or reuse it if you still trust it. Old words: keep them, as safe as before, for 2 to 3 months; if no missed wallet turns up, destroy them, or keep them safe. New words, on metal: in your planned places from today on. Family plan: update it today for the new device, and record where the backups are on a sealed note, never in a will. The old words outlive the move because they are your way back to a wallet you missed. — **Reset the old device now; keep the old words for a while.** Until they’re destroyed, the old words still open every old wallet, so they need the same care as before. Write down where the new backups are on a separate, sealed note for your family, never in a will, which can become public.

Common Migration Mistakes to Avoid

A costly mistake in hardware wallet migration is importing the old seed phrase into the new device when you meant to start clean. The new device’s keys are then only as secure as the least secure environment the seed phrase has ever touched. If the old seed may have been exposed, always generate fresh entropy on the new device.

Rushing the process is another common error. Skipping the test transaction and spend verification steps may save a few minutes but introduces the risk of sending your entire balance to an address you cannot spend from. The small transaction fees for testing are negligible compared to the cost of a mistake.

Failing to account for all funds is particularly risky for users with complex wallet configurations. If you have used multiple passphrases, derivation paths, or address types over the life of your wallet, ensure every source of funds is included in your migration plan. Use your wallet software’s discovery feature, with the old device connected, to scan for balances across all common derivation paths; never type the old words into it for a scan.

Finally, do not rush to destroy old backups. Keep them accessible until you are absolutely certain the migration is complete. The peace of mind of having a fallback far outweighs the minor inconvenience of maintaining the old backup for a few extra weeks.

Step-by-Step Guide: Migrating Bitcoin to a New Hardware Wallet

This streamlined guide covers the practical process of moving your Bitcoin from an old hardware wallet to a new one safely.

Step 1: Set up the new hardware wallet with a fresh seed. Unbox the new device, verify its packaging and tamper-evident seals, and follow the manufacturer’s initialization process. Install and verify the current firmware, then generate a new seed phrase on the device — do not import the old seed. Stamp the new seed onto a metal backup and verify it against the device’s displayed words. Set a strong PIN.

Step 2: Connect the new wallet to Sparrow Wallet and generate a receive address. Open Sparrow Wallet, connect the new hardware wallet, and create a new wallet file. Navigate to the Receive tab and generate the first address. Verify this address on the hardware wallet’s physical display — the address shown on Sparrow must exactly match the address shown on the device. Copy this verified address.

Step 3: Send a small test transaction from the old wallet. Connect your old hardware wallet to its wallet software. Send a small amount — 50,000 to 100,000 satoshis — to the verified receive address on the new wallet. Wait for at least one blockchain confirmation. Verify the balance appears in the new wallet on Sparrow.

Step 4: Spend from the new wallet to verify signing. This is the step most people skip, and it is critical. Send a small portion of the test amount to another address in your new wallet. This proves that the new device can sign transactions; your seed phrase backup is checked separately, with the device’s built-in backup check. If signing fails, investigate before transferring more funds.

Step 5: Transfer the full balance. Once the test cycle (receive, verify, send) completes successfully, transfer the remaining balance from the old wallet to the new one. If your old wallet has multiple address types or passphrase-protected wallets, send separate transactions from each. Use Sparrow’s coin selection to verify you are not leaving any UTXOs behind.

Step 6: Verify zero balance on the old wallet. After all transactions confirm, check that the old wallet shows zero balance across all derivation paths (legacy, nested SegWit, native SegWit, Taproot) and all passphrase wallets. If you are uncertain which ones were used, plug in the old device and let Sparrow (2.4 or later) scan the standard paths: File → Import Wallet, Scan for Connected Devices, then Discover Wallet in the menu beside Import Keystore. Skip the Mnemonic Words pane in that window, which asks for your recovery words.

Step 7: Secure the new backup and decommission the old device. Store the new wallet’s seed backup in your planned secure locations. Factory reset the old hardware wallet. Give any exchange, service or person that still pays an old address a receive address from the new wallet. Keep the old seed phrase backup accessible for 2-3 months in case you discover overlooked funds, then securely destroy it or keep it in secure storage.

Warning: A costly mistake in migration is importing the old seed phrase into the new device when you meant to start clean. A migration gives you new entropy generated in a verified secure environment. If the old seed may have been exposed, only a new seed fixes that; even if it was not, a fresh seed gives the new wallet a clean start.

Common Mistakes to Avoid

Importing the old seed into the new device. This is not a migration — it is duplication (fine for recovering from a broken device, but it does not start a clean wallet; after a lost device, restore and then move the coins to a new wallet at once). The new device’s keys are only as secure as the least secure environment the seed has ever touched. If the old device had compromised firmware, the seed is compromised regardless of which device holds it. If that is possible, generate fresh entropy on the new device.

Skipping the test spend verification. Receiving Bitcoin at an address and being able to spend from that address are two different things. Hardware wallet bugs, incorrect derivation paths, or configuration errors can create addresses that accept funds but cannot spend them. A 50,000 sat test transaction is cheap insurance against losing your entire balance.

Forgetting about passphrase-protected wallets. If you used BIP39 passphrases on the old device, each passphrase creates a separate wallet with its own balance. The base wallet (no passphrase) might show zero balance while significant funds remain in passphrase wallets. Check every passphrase you have ever used before considering the migration complete.

Destroying old backups too quickly. Users sometimes find funds months later in a derivation path or passphrase wallet they forgot about. Keep the old seed phrase backup secure for at least 2-3 months after migration. Only destroy it after you are certain all funds have been moved.

Frequently Asked Questions

Why can’t I just import my old seed phrase into the new device?

You can, and it is the normal way to recover after a broken device when your words were never exposed. After a lost or stolen device, restore the wallet and move the coins at once to a new wallet with fresh words, as Trezor advises. For a migration, or if the old seed may have been exposed, a fresh seed is the safer choice. Importing the old seed means the new device inherits any compromise that may have affected the old device. If the old device’s firmware was tampered with (like a Dark Skippy attack), the seed itself is compromised — moving it to a new device does not fix that. A fresh seed generated on verified firmware starts with a clean security baseline.

How much do migration transactions cost in fees?

The fee is the transaction’s size times the fee rate, and every UTXO (unspent transaction output, one coin in your wallet) it spends adds to the size. Moving one coin from a Native SegWit (bc1q) address takes about 110 vB: about 110 sats at 1 sat/vB, which was usually enough for the next block in November 2026, or 1,100 sats if fees rose tenfold. Thirty small coins take about 2,080 vB (2,080 sats at 1 sat/vB, 20,800 at 10), and thirty coins on old addresses starting with 1 take more than twice that, because each adds about 148 vB instead of 68. Check current fee rates on mempool.space and, if you can wait, send while they are low.

Can I migrate from a single-sig wallet to a multisig wallet?

Yes. The process is the same conceptually — you send Bitcoin from the old single-sig wallet to a new multisig wallet address. Set up the multisig wallet first (with verified address matching across all devices), complete the test cycle, then transfer the full balance. This is a common upgrade path for users with growing holdings who want stronger security.

What if my old hardware wallet is broken and I cannot sign transactions?

If the device is non-functional, recover the old wallet from its seed phrase backup on another hardware wallet, never on a computer or phone, and type each passphrase you used exactly as written. A replacement bought from the maker’s own store works, or any hardware wallet that accepts your backup type, as long as it is not the device that will hold your new seed. Sign the migration transactions on it, send the funds to your new wallet, then reset it.

Related Resources

Part of our free Bitcoin course: This topic is covered in How to Set Up a Hardware Wallet: Your First Cold Storage Step by Step, from the Bitcoin Wallets & Self-Custody course.

Filed under: Bitcoin Wallets & Self-Custody