Migrating to Trezor Suite From Another Hardware Wallet: What You Need to Know

A user holding Bitcoin, Ethereum, and several altcoins across a Ledger Nano S or KeepKey device eventually faces a practical question: can those coins move to a Trezor hardware wallet without loss, exposure, or unnecessary complexity? The answer depends on understanding the relationship between recovery seeds, account derivation paths, and the specific software managing each device. A migration is not simply a matter of plugging in a new device and importing an old seed phrase. Recovery seeds themselves are network-agnostic—a 12- or 24-word BIP39 phrase can unlock the same private keys across different hardware and software implementations—but the wallet software controls which accounts are generated, which addresses are displayed, and how assets are reconciled.

Trezor Suite, the official software for managing Trezor hardware wallets across desktop and mobile platforms, enforces strict separation between private key generation and internet exposure. When migrating from another device, the security advantage of that isolation comes with a reconciliation responsibility: confirming that the recovery process generates the same accounts, detecting any balances that remain on the original device, and ensuring that no asset is accidentally forgotten during the transition. The process is manageable but requires deliberate steps in the correct order.

Why recovery seed compatibility is not automatic

A BIP39 seed phrase is a standardized way to derive an infinite sequence of private keys from a human-readable backup. If a Ledger or KeepKey device was initialized with a 24-word seed, and that seed is imported into a Trezor device, both should theoretically produce the same private keys. However, the software managing each device controls which keys are actually used and how they are associated with visible addresses. This is where account derivation paths come into play. A derivation path is a mathematical sequence that specifies which private keys are generated for which coin and which account. Different hardware wallet vendors have historically used slightly different standards, and even within the same vendor, firmware updates or settings changes can affect which path is used.

Ledger, for example, may generate Bitcoin addresses using BIP44, BIP49 (native segwit), or BIP84 (taproot) paths depending on the account type and app selected on the device. KeepKey generally follows BIP44 for most coins but may have its own conventions for newer assets. Trezor supports multiple derivation paths for Bitcoin and Ethereum, and the specific path selected during account recovery can determine whether the imported seed produces the same visible addresses as the original device. If the paths do not match, a user might see zero balances on newly generated accounts even though the seed phrase is correct, because the software is checking different address derivation paths than those actually used in the original wallet.

The practical implication is that recovery seed compatibility cannot be assumed; it must be verified. Before consolidating all assets under Trezor Suite, a user should create a test account on the new device, derive the first few addresses, and compare them to the addresses shown on the original device for the same coin. If they match, the derivation path is aligned and recovery can proceed. If they do not, the issue is not a corrupted seed—it is a path mismatch, which may be correctable by selecting a different account type in Trezor Suite or by requiring a manual reconciliation step.

Creating the Trezor device and preparing for recovery

Setting up a new Trezor device is the first step, but the decision about whether to initialize it with a new seed or to recover an existing one must be made immediately. Trezor Suite guides the user through this choice when first connecting the device. The hardware wallet itself generates its recovery seed during setup, meaning the device creates random entropy and produces a 12- or 24-word phrase without exposing it to the connected computer. This is a critical security property: the software never sees the seed during creation.

To recover an existing seed from another device, the user must select the «restore wallet» or recovery option in Trezor Suite during initial setup. The actual seed entry happens on the device itself, not in the software, using the device’s buttons or touchscreen. This on-device entry further reduces the risk that the seed is transmitted to or captured by the computer. Once the seed has been entered on the Trezor and the device confirms successful recovery, Trezor Suite can then generate the associated accounts and display addresses. At this point, the critical test is to verify that the addresses on the screen correspond to the addresses actually holding funds on the original device.

Before beginning recovery, a user should document the current state of the original device: a list of coin types, the visible account names, any public addresses shown on the device screen itself, and—most importantly—the balance for each asset. A simple spreadsheet with Asset, Account, Address (optional), and Balance columns can serve as a reference. Taking screenshots of the original wallet software and comparing them later to Trezor Suite provides a second verification layer. This documentation is not paranoia; it is the only reliable way to confirm that no asset has been accidentally skipped or double-counted during the transition.

Reconciling accounts across wallet software

After recovery is confirmed and the first test addresses match, Trezor Suite will derive additional accounts as needed. For Bitcoin, this typically means multiple accounts, each corresponding to a different BIP44 path. For Ethereum and ERC-20 tokens, Trezor Suite generally uses a single account but displays all tokens held at that Ethereum address. Coins like Cardano, Litecoin, and Solana follow their own patterns. The first reconciliation task is to ensure that Trezor Suite has derived all the accounts that contain balances on the original device.

A user who had four Bitcoin accounts on a Ledger device must confirm that Trezor Suite shows all four accounts with the same receive addresses. If an account appears empty in Trezor Suite, it may be because the derivation path differs or because the account index is not being checked. Many hardware wallet platforms allow the user to manually specify an account index or to enable additional account discovery. Trezor Suite includes an account discovery feature that automatically scans for additional accounts containing funds. This feature should be used after the initial setup to prevent assets from being overlooked.

For altcoins and tokens, the reconciliation is equally important but sometimes less obvious. If the original device held Cardano on a specific account or ERC-20 tokens on an Ethereum address, Trezor Suite must be configured to display those accounts and assets. Many tokens are not displayed by default; they must be manually added or discovered. The Trezor hardware wallet application allows users to search for and add supported tokens, but the user must initiate this process. Missing from the interface does not mean the token is lost; it means Trezor Suite simply is not displaying it yet. Checking each asset against the original device’s balance list will reveal gaps.

Understanding account index and derivation path differences

Bitcoin addresses derived from a recovery seed are indexed numerically: address 0, address 1, address 2, and so on. Different coins and different account types may start at different indices or use different derivation formulas. KeepKey, for example, might generate Bitcoin addresses starting from index 0 in account 0, while Trezor might be checking the same account but starting from a different index, or a user may have created multiple accounts on the original device, each beginning at index 0. When the software looks for funds, it must check the correct account and the correct index.

Trezor Suite’s account structure is hierarchical: for each coin, there can be multiple accounts, and for each account, there can be multiple addresses (for Bitcoin-like coins) or a single address (for account-based coins like Ethereum). When importing a seed, the user should pay special attention to the account index. If the original device used Account 0, Account 1, and Account 2, Trezor Suite must check all three to find the balances. The software may not automatically discover very high account indices (such as Account 10 or 20), so if the original device had accounts at unusual indices, manual specification may be required.

For Ethereum and other account-based coins, there is typically only one account per derivation path, but the address itself is what matters. If an Ethereum address held tokens on the original device, that same address will hold them in Trezor Suite, provided the seed was imported correctly. The token list may differ, but the address balance is absolute. A user can verify this by opening any Ethereum block explorer, pasting the address, and confirming the visible token balances. This independent verification can clarify whether a missing token is a Trezor Suite display issue or an actual account mismatch.

Moving assets from the original device to the new Trezor

Once account reconciliation is complete and all balances are confirmed in Trezor Suite, the user faces a decision: leave assets on the original device as a backup, or consolidate everything on the Trezor. From a security perspective, having the same seed in multiple locations increases the risk that the seed could be discovered or compromised. The best practice is to move all assets from the original device to the Trezor and then securely destroy the original device’s seed (or keep a paper backup in a secure location separate from both devices).

Moving assets should be done systematically, coin by coin, to avoid errors. For each asset type, a user should send the entire balance from the original device to a receive address generated by Trezor Suite. The receive address must come from Trezor Suite, not from a third party, and it should be verified on the Trezor device screen itself before any transaction is sent. Trezor Suite enforces mandatory on-device transaction verification: the user must confirm the destination address on the hardware device before the transaction is signed. This prevents man-in-the-middle attacks where malware could alter the destination address between the screen and the actual signature.

After sending each asset, the user should wait for the transaction to confirm on the blockchain and verify that the balance appears in Trezor Suite. Only then should the next asset be moved. This deliberate approach reduces the risk of irreversible errors. A common mistake is to send multiple transactions in rapid succession without confirming receipt of each, which can obscure whether a particular transaction was completed or failed. Patience during this consolidation phase is an investment in confidence.

Handling multi-signature wallets and custom derivation

Some users maintain multi-signature wallets where two or more hardware devices (perhaps a Ledger and a KeepKey) are required to authorize transactions. A multi-signature recovery is more complex because both devices must be present and in agreement. If migrating from a multi-signature setup where one device is being replaced, the new Trezor device must be configured to participate in the same multi-signature scheme. This typically involves importing the same seed but, more importantly, ensuring that the multi-signature software (whether it is a third-party coordinator like Casa, Unchained Capital, or a local tool like Caravan) recognizes the Trezor device as a valid participant.

Multi-signature recovery requires understanding the difference between a seed and a public key. The seed is private and used to sign transactions; the public keys derived from the seed are shared with the multi-signature coordinator and determine which addresses are created. When replacing a device in a multi-signature setup, the recovery process must restore not only the seed on the new device but also the configuration in the multi-signature software that specifies which public keys and at what indices are participating.

For single-key users, custom derivation is less common but still possible. A user who manually specified a non-standard derivation path on the original device (rather than using the default) must replicate that path in Trezor Suite, or accept that the Trezor will use its standard paths and conduct a one-time consolidation transfer. Custom derivation is an advanced feature and should only be attempted if the user has clear documentation of the exact path used and understands the implications. In most cases, using standard BIP44 or Trezor’s defaults is the safer choice.

Privacy considerations during migration

Trezor Suite supports non-custodial wallet management, meaning private keys remain on the hardware device and are never exposed to the internet. However, the migration process itself involves sending transactions from one device to another, which creates on-chain evidence that the user controls both addresses. An observer analyzing the blockchain can see that funds moved from one address to another, potentially linking account histories that were previously treated as separate.

Users concerned about privacy should consider consolidating assets in batches or over time rather than moving everything at once. A single large transaction from every address to new addresses can be more revealing than a series of smaller or delayed transactions. Additionally, Trezor Suite includes coin control features that allow users to select specific inputs (UTXO) when spending Bitcoin, and it supports Tor integration for network privacy. These tools can help reduce traceability during and after migration, though they do not erase the blockchain records of the consolidation transfers themselves.

For users who had separate coin wallets on the original device, maintaining separation by using different accounts in Trezor Suite—rather than consolidating everything into one address—can preserve some privacy boundaries. Trezor Suite’s portfolio tracking and coin control features provide the tools needed to manage this separation. The decision to consolidate or partition accounts is a privacy and operational trade-off that should be made consciously rather than defaulting to whatever seems most convenient.

Testing recovery and securing backups after migration

After the initial recovery and consolidation is complete, a final critical step is to test the recovery process on a separate device or in a test environment. This means initializing a second Trezor device (or a test wallet on a computer) with the same seed phrase and confirming that the accounts and balances appear correctly without the original device present. A recovery phrase that cannot be used to restore the wallet is a backup that has failed its only purpose. Testing should happen before the original device is destroyed or archived.

The recovery phrase itself must be stored securely. For a hardware wallet, the seed is the single point of failure: anyone with access to the seed can drain all assets. Standard backup practices include writing the seed on fireproof metal, storing it in multiple geographic locations, and keeping it physically separate from the Trezor device itself. A common error is storing a digital backup (a photograph, a password manager, a cloud note, or an email) which exposes the seed to internet-connected risks.

Trezor Suite also supports a feature called a «passphrase» (sometimes called a 25th word), which is an optional additional password that modifies the account derivation. If a passphrase was used on the original device, it must be entered when recovering in Trezor Suite. Without the correct passphrase, the recovered accounts will look empty even though the seed is correct. A user should carefully confirm whether a passphrase was used before beginning recovery. If one was used and is forgotten, those assets may become inaccessible.