Crypto custody migration is the process of moving digital asset operations from one custody provider or infrastructure to another. For an institution, it covers far more than moving assets. Keys, approvals, compliance records and integrations all change too. Plan each one before you start.
The security stakes make a structured approach essential. Chainalysis reported more than $3.4 billion stolen in 2025, and said a small number of large private key compromises at centralized services shaped the total. Treat a custody switch as a change to your whole digital asset operating environment.
This guide is for heads of operations, technology, security, treasury and compliance at institutions that use crypto custody today. It suits teams still weighing a switch and teams already planning one. It covers what to do before, during and after a migration.
In an institutional context, crypto migration means changing the custody infrastructure that controls digital assets. The assets stay on the blockchain. What changes is who holds the keys and how transactions are approved.
An institutional migration may include:
Three things are easy to confuse:
Institutions switch when the business outgrows the provider. A platform does not need to fail for this to happen. The business has often evolved beyond what the infrastructure was built to support. The most common triggers are:
Institutions should also assess how much they rely on external providers and whether this creates concentration risk. For banks, the Basel Committee’s standard on cryptoasset exposures points to operational risk, outsourcing, cyber risk and third-party risk as part of the overall assessment.
The decision to switch should weigh current problems and the institution’s future operating model.
The checks below cover the inventory, security, keys, ownership and failure points to settle before you move assets.
Before you begin, build a complete picture of what exists. The inventory becomes the reference point for planning, testing and validation. Record:
It changes with the key management model, the access controls and the recovery process. Review each one instead of copying the old setup.
Start by comparing key management models. You may be moving between MPC, HSM, multi-signature or hybrid arrangements. Each protects signing authority differently, so understand what will change. Review the full key lifecycle: generation, storage, signing, rotation, backup, recovery, revocation and access.
Give privileged access particular attention. Know who can change wallet settings, modify transaction policies or reach sensitive systems. Test role separation in the new environment. If different employees initiate and approve transactions, recreate and test those permissions before you complete the migration.
Review the provider’s incident response process. Understand how it would handle an unavailable signing component, suspicious activity or a compromised administrator account. Escalation paths and recovery procedures should be clear before you move production assets.
Request penetration test reports, independent assessments, incident response documentation and recovery procedures. The aim is to understand how the whole system behaves in normal operations and during a security event. Cryptographic architecture matters, but access controls, transaction governance, recovery and operational processes all shape how safely you can manage assets.
Often, no. In many institutional environments, private keys cannot simply be exported and imported into another system. The answer depends on the architecture and the provider.
In many cases, the safer approach is to create new wallets with the destination provider and transfer the assets. That makes it an asset migration, not a key migration. It still needs careful handling of destination addresses, approvals, transaction fees, reconciliation and compliance records.
Confirm the provider’s policy on key portability, export restrictions and migration before you sign a custody agreement. Knowing the limits upfront makes any future provider change easier to plan.
Learn More – What Is Wallet as a Service (WaaS)
An institutional migration needs one accountable programme owner, supported by teams with clear responsibilities:
Treat the migration as a cross-functional business project, not an IT change. Assets, controls, compliance and financial records sit with different teams, so everyone should work from one migration plan.
Small gaps in planning, configuration or record-keeping can disrupt a migration. They rarely affect the blockchain itself. They can delay transactions, create reconciliation problems or weaken controls during the transition. The most common failures are:
Changing infrastructure should not create gaps in compliance records or audit history. Identify what must stay accessible before the migration starts. This includes AML and KYC records, sanctions screening results, KYT history, Travel Rule information, transaction records, customer information, audit trails and regulatory reporting data.
Transaction history needs particular attention. When assets move to new wallet addresses, the link between old addresses, customer accounts and internal records does not follow the assets. Decide how you will export, retain or link historical records to the new environment.
Review data retention rules too. Depending on jurisdiction and business model, some records must stay accessible for a set period after the provider relationship ends.
Some regulators also expect notice of material changes to outsourcing or custody arrangements. Examples include the EU’s Digital Operational Resilience Act (DORA) for ICT third-party arrangements and the Monetary Authority of Singapore’s outsourcing guidelines. Legal and compliance teams should confirm what applies in each market you serve.
Keep compliance involved throughout the migration. Do not treat it as a final sign-off.
A custody environment rarely works in isolation. It may connect with core banking, treasury, accounting, ERP, trading, payment, compliance and reporting systems.
Before you switch, map every connection to the existing platform and note what data or events pass through each one. The technical review should cover APIs, webhooks, authentication, data formats, rate limits, error handling and reconciliation.
Look for less obvious dependencies. An internal reporting tool or reconciliation process may rely on a specific API field, wallet format or event notification.
Test the destination environment against each critical integration before you move production assets. Test transactions should follow the full path: initiation, approval, signing, blockchain confirmation and internal reconciliation.
Agree who owns integration support during cutover. If an API issue affects live transactions, teams need a clear escalation path and a defined response process.
Migrate in seven phases so that each stage can be tested, paused or rolled back. A phased approach lets you test the new environment before you move the full production portfolio. It also gives teams clear points to stop and fix issues.
| Phase | What happens | Complete when |
| 1. Discovery | Document wallets, assets, users, integrations, policies and compliance requirements | Operations, security and compliance sign off the inventory |
| 2. Technical testing | Configure the destination environment and test wallets, permissions, approvals, signing and integrations | Test transactions pass end to end |
| 3. Pilot migration | Move test wallets or a small amount of assets | The full migration path works as expected |
| 4. Controlled production migration | Move production assets in planned stages, not all at once | Each stage passes validation |
| 5. Validation | After each stage, verify balances, permissions, transaction records, compliance controls and integrations | Results match the approved configuration |
| 6. Final cutover | Complete the remaining transfers | Required checks pass and cutover is approved |
| 7. Decommissioning | Retain required records and disable the previous environment | All dependencies are addressed |
Each stage needs a rollback plan and an incident escalation process. Running the old and new environments in parallel for part of the transition lets teams compare them. Small-value transfers help verify destination addresses, transaction workflows and reconciliation before you move larger amounts.
There is no standard timeline. Duration depends on the number of wallets and blockchains, integration complexity, security and compliance reviews, staking lock-ups and the number of production stages. A small migration may need limited testing. A large institutional programme can take weeks or months.
Asset transfers are only one milestone. Validate the destination environment before you retire the old platform.
This gives you evidence that the new environment works as expected. It also gives management a basis to approve final cutover.
Use this quick reference as a starting point for crypto custody due diligence.
| Question | What to confirm |
| Why are we migrating? | The business objective: scale, security, integrations, regulatory requirements or commercial terms |
| Which wallets and assets are affected? | Networks, balances, wallet types and special positions such as staking |
| How will signing controls change? | The existing and destination key management and approval models |
| Are all integrations ready? | APIs, webhooks, reporting feeds and reconciliation processes |
| Will compliance continue during migration? | Monitoring, screening and required records stay available |
| Is there a rollback plan? | When a stage should stop and what happens next |
| How will reconciliation work? | How blockchain activity will be matched with internal records |
| Who approves the final cutover? | A named decision maker |
| How will the old environment be decommissioned? | Remaining records, access, contracts and dependencies |
A new custody provider may rely on several external companies to deliver its services. Identify these dependencies before you sign and understand how they could affect your custody operation. They may include cloud providers, custody partners, blockchain node providers, compliance vendors and Travel Rule providers.
Assess service level agreements, business continuity, disaster recovery and incident response. Ask whether a failure at a critical third party could affect transaction processing, access to wallets or other essential services.
Review exit provisions and data portability for important third-party relationships, not only the main provider. Understand what alternatives exist if a critical supplier has a prolonged disruption or changes its service.
This shows you the full technology and service chain behind a custody platform, not only the primary provider’s capabilities.
Review exit terms before the relationship begins.
The goal is to leave a provider without creating unnecessary operational, compliance or security risk.
Liminal provides institutional wallet infrastructure using MPC, multi-signature and HSM-backed key protection, with hot, warm and cold wallet support. Its Wallet-as-a-Service offering is API-driven and built for wallet management, automation and integration into institutional environments.
During a migration, you can use the destination environment to configure wallets, transaction policies and approval workflows before you move production assets. Liminal Firewall is a policy engine that approves, blocks or escalates a transaction before it reaches signing. Maker and checker controls help separate transaction initiation from approval.
In a phased migration, these controls support testing before production cutover. After assets move, wallet records and approval history support post-migration validation.
Liminal holds ISO 27001:2022, ISO 27701:2019 and SOC 2 Type II. Review the scope and assessment period of each report during your due diligence. Liminal provides the infrastructure layer. The institution remains responsible for migration planning, regulatory requirements, approvals and risk management.
Crypto custody migration involves far more than transferring assets to new wallets. It affects security, transaction controls, compliance processes, integrations, records and daily operations.
A successful migration starts with a detailed assessment of the existing environment and a clear transition plan. Review key management, map integrations, preserve compliance records and test the new infrastructure before you move production assets. A phased approach helps you find issues early and limit disruption.
The migration does not end when the assets move. Verify balances, wallet ownership, permissions, transaction history, compliance controls and reconciliation before you retire the previous environment.
A well-planned migration lets you move to new custody infrastructure while keeping the security, controls and continuity your digital asset activities need. To plan a phased migration for your exchange, bank or payment use case, talk to the Liminal Custody team.
Crypto custody migration is the process of moving digital asset operations from one custody provider or infrastructure to another. For institutions, it can involve wallets, assets, signing systems, transaction policies, integrations, permissions and compliance records.
Institutions change providers for scalability, different security controls, more blockchain support, stronger integrations or better compliance capabilities. Commercial terms, service quality and third-party dependencies can also drive the decision.
Inventory existing wallets, assets, permissions, policies and integrations. Configure and test the destination environment, then move assets in controlled stages. Each stage should include balance checks, transaction testing, reconciliation and validation of required controls.
Review wallets, assets, key management, transaction policies, permissions, integrations, compliance requirements and recovery procedures. Set a rollback plan, define who approves cutover and decide how historical records and the previous environment will be handled.
It depends on the provider and wallet architecture. Some systems restrict private key export, and different MPC and HSM implementations may not be compatible. Institutions often create new wallets and transfer assets instead of moving the original keys.
There is no standard timeframe. A small migration may need limited testing. A large institutional programme can take weeks or months because of integrations, security reviews, compliance requirements, asset inventories and phased production transfers.
Use staged transfers, test wallets, small-value transactions, multiple approvals, verified destination addresses and rollback procedures. Test the destination security architecture before you transfer significant production assets.
Transaction history does not move automatically with the assets. Decide which records to export and retain, such as transaction history, customer information, KYT results, compliance records and audit trails.
Check data and asset portability, key export policy, access to historical records, notice periods, migration support, API documentation, termination rights and costs such as termination fees. Review the same terms for critical third parties.
Run detailed due diligence, build a complete asset inventory, test technically, migrate in phases and validate afterwards. Map third-party dependencies, preserve compliance records, test recovery procedures and keep a clear incident escalation process throughout.
