PAM migrations are far more complex than just shifting credentials into a new platform. The hard part is proving nothing still depends on the old one.
Enterprise PAM migrations often stall before the platform they were meant to replace is decommissioned. The new platform reaches production and the project is closed, but the legacy vault — a Delinea Secret Server cluster, a BeyondTrust appliance, an older CyberArk Digital Vault — stays in service, still storing and rotating credentials, listed in audit reports as pending decommission. The cause has little to do with the target platform. It concerns the requirement that ends the project: showing the legacy vault can be turned off.
Migration as a decommissioning problem
PAM migrations are scoped as data-movement projects: credentials are exported from the source vault, mapped into the target's object model, onboarded, and the users cut over. Progress is tracked as the percentage of accounts onboarded, and the migration is reported complete when that reaches one hundred.
Onboarding is the part that completes on schedule, but the deliverable is not a populated new vault. It is a legacy vault that can be removed without consequence, which requires showing that no system still depends on it. Loading the target proves a positive — these credentials now reside in the new platform — while removing the source requires proving a negative: nothing still references the old one. That negative cannot be derived from the source vault's records, which show what it stores, not every external system configured to retrieve from it.
The dependency graph
A credential in isolation has no operational weight. Its risk derives from the systems that use it: the application that authenticates with it, the script that injects it, the resource it unlocks. What has to be migrated is the dependency graph connecting each secret to its consumers and to the resources they reach, not the stored secrets alone.
A vault's inventory reflects the credentials placed under its management. It is not a map of the systems that call those credentials from elsewhere, or of the path from each consumer to the resource it reaches. It also reflects only what was onboarded, as of when it was onboarded — not the local administrator accounts left unenrolled across the server estate, the accounts created for past projects and never removed, or the service accounts that in most enterprises are the largest privileged population, frequently by an order of magnitude. Accounts absent from the inventory are neither migrated nor accounted for at decommission.
The last-reference problem
Before the legacy vault can be removed, every application that retrieves a credential from it has to be reconfigured to retrieve from the new platform. One missed reference produces a production authentication failure at the moment of decommission.
The scope of that work depends on how applications retrieve credentials. In a CyberArk environment, applications call the Central Credential Provider over a REST web service, commonly with client-certificate authentication, with the endpoint and query held in a configuration file. In a Delinea environment, they call the Secret Server REST API or retrieve through its SDK. In a BeyondTrust environment, retrieval runs through the Password Safe API. None of these references sit in the vault. They sit in the consuming systems: Windows service definitions, IIS application-pool identities, ODBC connection strings, scheduled tasks, cron jobs, batch schedules in Autosys or Control-M, and credentials embedded in vendor appliances. Each has to be located and repointed.
Reconfiguration is not a uniform change. For application-to-application retrieval, the consuming application's identity has to be re-established in the target — a new client certificate, application registration, or allow-list entry — before it can authenticate to the new provider. Where retrieval logic is compiled into the application rather than held in configuration, repointing requires a code change and a release. The credential material does not transfer in bulk either: encryption keys are platform-specific, and SSH keys, certificates, and API tokens are re-vaulted in the target and generally rotated on entry.
Interactive sessions are a separate path with the same requirement. Each platform brokers sessions through distinct infrastructure — CyberArk through the Privileged Session Manager and its SSH proxy, BeyondTrust through Privileged Remote Access and the Endpoint Credential Manager, Delinea through its session proxy — with network paths and gateway configuration specific to each, rebuilt in the target before human access can cut over.
The vault's access logs record retrievals that have occurred, not the systems configured to retrieve. A consumer that has not run within the observed period — a quarter-end reconciliation job, an annual regulatory export, a disaster-recovery path used only during failover — does not appear in them. A decommission decision based on absence of recent access omits them, and the failure surfaces when the job next runs against a vault that no longer exists.
Parallel operation
Reconfiguration cannot be completed in one change window, so both vaults run in parallel for an extended period. Three conditions during that period work against the migration.
The first is suspended rotation. To avoid breaking the references above, rotation is often paused for the duration of the project, leaving the credentials in scope static for months. That removes the control that limits the useful lifetime of a compromised credential, over the interval in which those credentials are most exposed. The 2025 Unit 42 incident response report documented an attacker reaching domain administrator from initial access in under forty minutes; a multi-month window of static privileged credentials is a measurable increase in exposure.
The second is competing rotation authority. When both vaults are configured to manage the same account, their rotation operations collide. One platform rotates the target password on schedule; the other detects that the target no longer matches the value it holds, treats the difference as drift, and resets it. Neither then holds a valid credential, and the account is locked out. Drift correction assumes a single managing authority; two on one account produce the condition it exists to prevent.
The third is translation loss. The platforms do not share an object model: CyberArk uses Safes governed by Platforms and a Master Policy, Delinea uses Secrets, folders, and templates, BeyondTrust uses Managed Systems and Smart Rules. Permissions, approval workflows, dual-control requirements, and break-glass procedures are re-expressed during migration, and the mapping is approximate in both directions. Where it is approximate, access either widens beyond its prior scope or breaks, and without a before-and-after comparison, neither outcome is detected during the migration.
For regulated organizations, session recording, access records, and attestation history have to remain continuous across the migration, or the gap becomes an audit finding. The 2024 Change Healthcare breach indicates the exposure attached to a single unmanaged credential: stolen credentials for a Citrix remote-access portal without multi-factor authentication, then roughly nine days of lateral movement, in an incident affecting roughly 190 million people's records. A migration introduces coverage gaps by default, each to be closed before the corresponding source coverage is removed.
Completion criteria
The percentage of accounts onboarded does not measure progress, because onboarding the target does not remove the dependency on the source. The measure that corresponds to completion is the proportion of credentials shown to be no longer referenced by any active system — those that can be severed without effect.
That evidence does not come from a vault API. It comes from observing authentication across the estate — which identity authenticates, against which target, from which source — over an interval long enough to include systems that run on extended cycles. The binding constraint on a PAM migration is observability, not credential export.
The sequence that follows reverses the usual one. Rather than moving credentials first and resolving dependencies as they break, the dependency graph is built first — every privileged identity, every secret, every edge — and used to order the rotations so that no consumer breaks, to validate the target account by account, and to decommission the source on evidence rather than inference. The destination is not the constraint: consolidating a Delinea and a BeyondTrust estate onto one platform, migrating onto Idira, or reducing five vaults to two are all manageable on the target side. Without a complete, current map of the dependency graph, severability cannot be shown and the legacy vault stays in service.
Hydden builds that map. Discovery identifies what exists across the estate, including the accounts and secrets no prior onboarding captured. Observation determines, continuously and from the environment, what depends on each credential. Control sequences the cutover and produces the evidence to decommission the source. Establishing what can be shut off is the work that closes a migration.
Frequently asked questions
What is a PAM migration?
A PAM (Privileged Access Management) migration is the process of moving credentials, accounts, and access policies from one vault platform to another — for example, from CyberArk to Delinea, from BeyondTrust to CyberArk Privilege Cloud, or from a legacy on-premises vault to a SaaS-delivered platform. The migration includes exporting credentials, mapping them to the target platform's object model, onboarding accounts, reconfiguring consuming applications, and cutting over interactive sessions.
Why do PAM migrations stall at decommission?
PAM migrations stall at decommission because the completion criterion — removing the legacy vault — requires proving a negative: that no application, script, scheduled job, or interactive session still retrieves credentials from it. That evidence is not available from the vault itself, which records what it stores, not every external system configured to call it. Without continuous observation of authentication across the estate, the dependency graph is never fully known, and the legacy platform remains in service indefinitely.
What is the last-reference problem in a PAM migration?
The last-reference problem is the difficulty of identifying every system that still calls the legacy vault before decommission. Applications, scheduled jobs, and batch processes that retrieve credentials embed the vault endpoint in configuration files, compiled code, or vendor appliances. A consumer that has not run within the observation window — a quarter-end job, an annual regulatory export, a DR path — does not appear in access logs. If that reference is missed and the vault is removed, the next run produces a production authentication failure.
How do you safely decommission a legacy PAM vault?
Safe decommission requires building the full dependency graph before severing any connection. This means: (1) discovering every privileged account on the estate, including those never onboarded to either vault; (2) observing authentication continuously — which identity calls which vault, from which system — over an interval long enough to capture all job schedules; (3) repointing each consumer to the new platform and validating the credential works before removing it from the old one; and (4) producing evidence, not inference, that no remaining system depends on the legacy vault.
What risks arise from running two PAM vaults in parallel during a migration?
Running two vaults in parallel creates three material risks. First, credential rotation is typically suspended to avoid breaking existing consumers, leaving privileged credentials static for months — a window that increases exposure to credential-based attacks. Second, if both vaults are configured to manage the same account, their rotation schedules collide: one vault rotates the password, the other detects drift and resets it, locking the account. Third, the permission models differ across platforms, so the migration mapping is approximate in both directions — access can widen beyond its intended scope or break silently.