Switch Licensing Providers Without Replacing Customer Keys

Switching software licensing providers does not always require a new customer key. It does require a controlled change to the application, entitlement data and verification policy. Keeping the same visible string is only one part of the migration.

Start with an owned test sample and a rollback plan. Separate key lookup, device registrations, offline proofs, payments and customer identity. An import of license rows is not a migration of every service your installed software uses.

Keep the key when the lookup can be reproduced

The PermitCore CSV wizard expects existing key strings. It hashes the key in the browser; the server applies its own HMAC lookup protection. An API importer can supply the documented SHA-256 input, but an unknown vendor-specific salted hash, HMAC or encrypted blob is not automatically the same input. Do not rename an arbitrary exported hash and assume it will validate.

Preserve the exact original value and its encoding. Case, whitespace and separators can matter; the server hashes the supplied plaintext bytes rather than inventing a new key format. Verify actual old keys against an owned migrated record before rolling out the client update.

If your export does not contain recoverable key values, establish what verifiable lookup material you actually have. A supported server-side migration process may be needed; do not expose a privileged import API credential in customer software or let an unverified client create its own entitlement.

Map products and policy before importing

Use Licenses → Import, review the selected source preset and explicitly map the columns. Match licenses to the correct PermitCore product. Check expiry, trial state, features, device cap, node-locking and customer association rather than treating every source field as equivalent.

The API accepts up to 500 rows per batch and reports per-row outcomes such as Created, Duplicate and ValidationFailed. Rows commit independently; a partially successful batch is not an all-or-nothing transaction. Keep the results and reconcile failed or duplicate rows before retrying.

Version limits use the supported dotted-numeric format. Convert dates deliberately, including timezone meaning. The wizard does not carry every custom field or network restriction; use the import reference for its current mapping and API fields. Reapply unsupported policy through the authorised administration workflow.

Activation counts are not device records

InitialActivations seeds the used count and must be between zero and the activation limit. It does not recreate the old device identities or active floating sessions. A node-locked installation that registers against the new system can consume another slot because its old activation row is absent.

Decide the count and re-enrollment policy before importing. Test a realistic partly occupied key, an existing installation and a genuinely new device. Do not assume copying the old total makes every old device reappear without cost, or solve uncertainty by silently removing customer limits.

Floating consumers need a new checkout and enforced returned deadline in the new system. Offline validation is not a floating lease. See the capacity guide and floating lifecycle.

Recovery storage is a separate choice

With the import wizard's optional passphrase encryption, you can retain ciphertext for later authorised reveal using that passphrase. Skipping it can still permit lookup and validation, but does not retain a recoverable plaintext key in that imported row. Preserve your authorised source export securely when recovery matters.

Store-issued licenses use their separate server-managed delivery and recovery path. Do not assume that path automatically wraps a generic imported row. An order reference is not ciphertext, and a hash is not a key recovery package. Review the exit and recovery plan for those different artifacts.

Update installed applications deliberately

Importing data does not redirect old client binaries. Ship a version that calls the correct PermitCore endpoint and checks the new product scope. Your app can reuse a legitimately retained customer key from its own settings, but you must implement and test that storage migration; the importer does not reach into installed apps.

Old signed offline proofs are not converted by importing the visible key. SDK 2.1.1 needs its supported proof format and independently configured trusted public keys. Plan new proofs and a controlled transition for disconnected users. Do not ship private signing or Admin keys as a shortcut.

Keep old and new decisions observable during an owned pilot. Define the cutover and rollback conditions, avoid activating both systems unintentionally, and test what an older client does after the original endpoint is retired. See signing and trust rollout.

Do not confuse licensing with payment migration

License import does not move card tokens, payment mandates, provider subscriptions or Store order history. Changing a vendor Store's selected provider affects new checkouts; existing purchases and subscriptions retain their original provider binding.

Handle any commercial migration as a separate approved process with the payment provider. Coordinate access dates without double charging or promising automatic subscription transfer. The payment lifecycle guide explains the existing fulfillment boundaries.

• Reconcile source and imported row counts, duplicates, failures and product mapping.
• Test existing key strings, wrong-product rejection, expiry and the intended device re-enrollment policy.
• Test update installation, retained key settings, new trust configuration and disconnected recovery.
• Keep billing migration, customer communications and rollback separately controlled.