Migration from non-kms participant to kms-based participant (externally stored kms key)

We’re working on migrating our non-KMS participant to a KMS-based participant with externally stored KMS keys. According to the documentation, the migration process involves onboarding a new validator, recreating parties, and migrating all assets from the old participant to the new one.

We’ve successfully created new parties on the new participant, but we’re unable to determine how to transfer the Active Contract Set (ACS) from a party on the old participant to a party on the new participant. The current migration documentation is marked as work in progress ( Migrate to external key storage with a KMS — Digital Asset’s platform documentation ), so we’ve been referencing the older documentation ( Participant Node Migration with a New Namespace — Daml SDK 2.10.2 documentation ). The older guide mentions using utils.change_contracts_party_ids to transfer the ACS between parties, but this function appears to be deprecated in Canton 3.x.

What is the recommended approach for transferring the ACS from a party on the old participant to a newly created party on the new participant? Or is this something which is not possible

Transferring an ACS from party A (old participant) to a different party B (new KMS participant) via a single console macro is not supported today. There is no replacement for utils.change_contracts_party_ids.

What you can realistically do:

  1. If you can avoid changing party ids:

    • Use party migration / replication tooling to move the party as-is to the new participant (still non-KMS → KMS may not fit your exact scenario, but if you can keep the namespace, this is the cleanest).
  2. If you must change namespace / party ids (your case: external KMS, new participant):

    • Preferred: design a Daml-level migration (contracts re-issued under new parties, old contracts archived).

    • If you absolutely need an ACS-rewrite migration:

      • Treat it as a custom repair and engage Digital Asset support to get a vetted script/workflow; don’t try to resurrect change_contracts_party_ids behaviour yourself.