Key Takeaways
Payment teams usually migrate wallet infrastructure over cost structure, support response times, or concentration on a single provider.
Importing existing vault keys preserves deposit addresses, so customers and counterparties keep their saved payment details.
Utila's Business Continuity can run as a standby environment, alongside an existing provider, or as a full migration.
Business Continuity mirrors wallets, policies and whitelists, while users, devices, integrations and recovery are set up again on Utila.
Payment companies often outgrow the wallet provider they started with. Pricing that worked at launch becomes expensive at volume, support cannot keep pace with live payment operations, or the business becomes too dependent on a single vendor. Switching still feels risky, because deposit addresses are saved in customers' wallets and counterparties' systems, approval rules encode the company's control framework, and payout pipelines are built against one provider's API.
A migration does not have to mean a relaunch. Utila's Business Continuity product imports existing wallet keys, so deposit addresses stay the same, and a company can bring Utila up alongside its current provider, move flows across gradually and keep a rollback option until the last step.
This guide sets out the migration in six steps, based on Utila's work with PSPs, exchanges, gaming operators and stablecoin issuers that moved live flows onto Utila.
Before You Start
Teams rarely migrate for a single reason, and knowing which problem the move has to solve helps decide how far and how fast to go. The triggers Utila sees most often fall into six groups:
Trigger | What it looks like |
|---|---|
Pricing | Per-transaction or basis-point fees that grow with volume. BLOXtrade found its previous provider's fee nearly wiped out the margin on a large USDT transfer |
Support | Slow responses during live payment incidents, or round-the-clock support sold as an add-on |
Operational failures | Sweep jobs that need manual intervention, or console designs that make sending errors more likely |
Concentration | Board or investor concern about depending on one bundled provider for custody, liquidity and payouts |
Provider exit | The provider shuts down or exits a market, as happened to Stable Mint, a MiCA-authorised PSP and stablecoin issuer |
Regulation | Rules such as the EU's DORA, which expects financial entities to keep exit plans for critical technology providers |
The migration itself follows six steps:
Step | What you do | Utila feature |
|---|---|---|
1. Migration path | Choose standby, parallel running, full migration or a fresh start | Business Continuity |
2. Inventory | List everything that has to move | Key import, policy and whitelist mirroring |
3. Recovery and governance | Set up backups, roles, quorum and policies | Admin quorum, transaction policy, backup and recovery |
4. Integration | Rebuild API, webhook and signing integrations on testnet | API, webhooks, Co-Signer |
5. Parallel running | Move flows across in groups | Mirrored wallets |
6. Clean-up and cut-over | Consolidate UTXOs, rebuild fee setups, retire the old provider | Sponsored Transfers, Utila Gas Station |
Step 1: Choose a Migration Path
Utila's Business Continuity imports ECDSA and EdDSA vault keys from another provider and mirrors wallets, policies and whitelists, so existing deposit addresses remain valid on Utila. That lets a company choose how far to go:
Path | What it means | When teams use it |
|---|---|---|
Standby environment | Utila mirrors the current setup and stays ready to activate, while the current provider remains primary | Exit plans, disaster recovery, DORA |
Parallel running | Both platforms operate side by side on the same addresses | Proving the new setup on live flows |
Full migration | All flows move to Utila and the old provider is retired | After a successful parallel run |
Fresh start | New wallets and addresses on Utila | Small balances, or when customers are changing payment details anyway |
Step 2: Inventory What Has to Move
Wallets and balances are the visible part of a migration, but the controls and integrations around them take longer to move. A full inventory before any funds move shows what Business Continuity carries over and what the team has to rebuild:
Area | What to move | How it moves to Utila |
|---|---|---|
Wallets and addresses | Every wallet on every chain | Key import keeps existing addresses |
Policies and whitelists | Approval rules, thresholds and approved destinations | Mirrored by Business Continuity; whitelists can also be uploaded in bulk by CSV |
Users and devices | Admins, signers, operators and their devices | Re-onboarded on Utila, with each new device approved by administrators |
Integrations | API calls, webhooks, signing services | Rebuilt against Utila's API; Utila webhooks carry IDs only |
Screening | AML vendor connection | Chainalysis or Elliptic connected to Utila |
Recovery | Key backups and disaster-recovery provider | Set up on Utila before funds move |
Step 3: Set Up Recovery and Governance
Recovery and governance come before any keys or funds move, so the new environment is protected from the first day. Four pieces need attention:
Backup and disaster recovery. Utila supports self-managed backups and third-party recovery through Station70 and CoinCover. Confirm who holds each backup and who is authorised to use it.
Admin quorum. The admin quorum approves changes to policies, users, whitelists and backups. It can be set to one or two approvers, and Utila recommends two for any vault holding client funds.
Roles. Utila's roles separate viewers, non-signing operators, signers, non-signing admins and admins, which makes maker-checker separation explicit.
Policy review. Utila's transaction policy applies the first rule whose conditions all match, so mirrored rules should be checked for order before going live.
Step 4: Rebuild Integrations on Testnet
Payout pipelines, deposit monitoring and signing services were built against the old provider's API, so they need to be connected to Utila and tested before any live traffic moves. Utila's REST API, signed webhooks and Co-Signer for automated signing cover these flows, and a testnet-only vault lets the team run them end to end without real funds.
Step 5: Run Both Platforms in Parallel
Running both platforms side by side lets the team prove the new setup on real flows while the old one remains the fallback. Teams usually route new clients, a new product or a single flow through Utila first, keep the remaining traffic on the current provider, and move further groups of clients once each one runs cleanly. XEROF, a Swiss VASP, mirrored its wallets during a parallel evaluation and connected Utila to its internal systems in under a week.
Step 6: Clean Up and Cut Over
Some preparation depends on the chain and is easiest before the final group of clients moves:
Consolidate UTXOs. Bitcoin wallets that received many small deposits hold many small unspent outputs. Spending them one by one inflates fees, so they are consolidated in batches before cut-over.
Rebuild fee setups. Gas wallets need funding on each chain. Sponsored Transfers add the EVM delegation automatically on first use, and the Utila Gas Station cuts the cost of USDT transfers on Tron by up to 70%.
Retire the old provider. Once all flows run on Utila and reconciliation is clean, the old provider can be switched off, or kept as a standby if the exit plan requires one.
Plan the Move
A migration review with Utila inventories your current wallets, policies and integrations, and shows which addresses can be preserved and which flows can move first. Talk to the team.
Frequently Asked Questions
Can we keep our deposit addresses when we migrate?
Yes, for supported key types. Business Continuity imports ECDSA and EdDSA vault keys, so existing addresses stay valid and customers keep sending to them.
Can we run both providers at the same time?
Yes. Mirrored wallets let a team route some flows through Utila while the current provider handles the rest.
How long does a migration take?
Integration depends on the scope but can often take under a week, as XEROF found. The full cut-over depends on how many client groups move and how long the team chooses to run both systems in parallel.
Do policies and whitelists transfer automatically?
Business Continuity mirrors wallets, policies and whitelists from the current provider. Teams should still review rule order before going live.
Does a standby environment help with DORA?
Utila positions Business Continuity as support for DORA exit planning, since a mirrored standby gives a tested path away from the primary provider.
Related guides: How to Launch Cross-Border Stablecoin Payments · How to Launch Stablecoin Pay-ins and Payouts · How to Launch a Stablecoin Yield Offering
Content Marketing Lead
Marcin Miłosierny is Content Marketing Lead at Utila, with experience creating content for regulated finance at Sygnum and technical analytics products at Glassnode.
