Armory to Coldcard-Q BTC Migration

Hi Paul you invited me to your forum here after I posted a comment on one of your YouTube videos. Now I am posting here for the first time using Matrix as an alias to discuss the topic of “Armory to Coldcard-Q BTC Migration”.

To recap, Armory is outdated BTC wallet software that back in the day was the de facto standard in BTC cold storage before BTC hardware wallets like ColdCard or Trezor were for sale. Nevertheless, Armory is no longer usable because it is not BIP39 compliant. So, now I need to replace my Armory setup with a modern cold storage setup. It’s a big project I am dividing into the three phases numbered below:

  1. Build a new Online Bitcoin Node to replace the outdated Armory Online Broadcaster PC.
  2. Setup an air-gapped ColdCard-Q Hardware Wallet to replace the Armory Air-Gapped Signer PC.
  3. Figure out how to migrate funds from the air-gapped Armory PC over to the air-gapped Coldcard-Q Hardware Wallet without involving the Armory Online PC.

To execute Phase #1, I am using a Micro PC equipped with an i5-7500T CPU, 32GB RAM, 500GB NVME Boot Drive, and a 2TB 2.5” SSD Hard Drive to store all the BTC Blockchain data on. Additionally, for extra security I Librebooted this PC to eliminate the privacy intrusive Intel ME technology. As for the BTC Node software destined to run from the NVME boot drive, I am building it from scratch so it all runs on top of Ubuntu Server OS v24.04.3. I am not using Start OS because in my opinion the convenience Start OS offers comes at the expense of having a bigger attack surface compared to building it from scratch which has a smaller attack surface. Nevertheless, any security recommendations to building a new BTC Node running on Ubuntu Server OS v24.04.3 are welcomed.

To execute Phase #2, I got a Coldcard-Q hardware wallet. It is not yet setup because my goal is to first finish my BTC Node build which is going to take me a while due to how I need to educate myself on how to correctly harden the Ubuntu Server OS environment as it relates to network security, SSL certificates, firewall configuration, monitoring, setting up secure access, TOR configuration, etc.…

Lastly, for Phase #3, I have spent a lot of time writing complex ChatGPT5 stacked prompts designed to assist me in figuring out the correct approach to moving funds from my Armory setup over to a Coldcard-Q air-gapped hardware wallet. According to ChatGPT5 the High-Level Migration Flowchart shown below is the recommended Path to solving my problem. Nevertheless, my hope is Paul or any other member in this forum community can help me confirm if the flowchart below is the correct path? Or not the correct path due to ChatGPT5 hallucinating? In short, I would appreciate any information that can assist me in determining what is the correct path to follow in this technical BTC migration journey I have ahead of me. Thank you for your time.

.
ChatGPT5 Generated Flowchart: High-Level Migration (Recommended Path)

  1. [Start]
    |
    V
  2. [Prepare Coldcard-Q offline: init seed, verify firmware, export watch JSON]
    |
    V
  3. [On Online Node: Import Coldcard JSON into Sparrow → “Coldcard Watch”]
    |
    V
  4. [On Air-Gapped Armory: Export addresses-only list (no priv)]
    |
    V
  5. [On Online Node: Import addresses list → “Armory Watch”; discover UTXOs]
    |
    V
  6. [Select a UTXO → Build PSBT paying to Coldcard address with NO CHANGE]
    |
    V
  7. [Transfer PSBT to Air-Gapped machine via Media A]
    |
    V
  8. [On Air-Gapped Armory PC (offline Sparrow): Export specific WIF(s) → Sign PSBT]
    |
    V
  9. [Return signed tx to Online Node → Broadcast via Knots/electrs]
    |
    V
  10. [Confirm on Mempool + Coldcard Watch: repeat progressively]
    |
    V
  11. [All funds migrated → Verify → Securely wipe Armory disk]
    |
    V
  12. [End]
    .
1 Like

That transfer process looks correct to me.

WRT to your security concern, it depends on your own aptitude in that area. I can confirm that Start9 is serious about security and have members of their team with experience in that area. But as you correctly allude to, their other primary goal is simplicity and UX. That has doubtlessly lead to trade-offs and hard decisions being made to balance the two conflicting goals (such as abstracting most controls away from the end-user and making broad assumptions)