CyberArk to Delinea (and back): what a PAM migration really involves

Moving privileged accounts from CyberArk to Delinea Secret Server, or from Secret Server back to CyberArk, is a rebuild with a data load at the end. Neither vendor ships a tool that reads the other's vault, so plan the rotation rules, connectors and permissions first and the password copy last.

A PAMdefinitionPAM is privileged access management: the vault for admin and service account passwords, which also rotates them and checks who's asking. move touches the accounts that can stop the business. If a password changes in the new tool while an app still holds the old one, that app fails on its next restart. Delinea's own docs warn about exactly this for services and scheduled tasks that aren't listed as dependenciesdefinitionServices, scheduled tasks or app pools that use a vaulted account. The vault updates them when the password changes, but only if it knows about them..

You'll also lose things you may be counting on. Secret Server's documentation says audits and history aren't carried over when secrets move, and its export file holds every password unencrypted. Nobody on either side owns the problem for you, either: Delinea's import page says migration isn't supported by its technical support team.

Plenty of these projects start with the ownership change. Palo Alto now sells CyberArk under the Idira name and says it stays available as a standalone platform. A renewal on new paper still gets people pricing the other vendor, and some of those quotes turn into migration plans. One PeerSpot reviewer describes switching from Thycotic to CyberArk. The same mechanics apply in reverse, so we cover both directions.

Engineers will recognise the hard part in step four. For each wave there should be exactly one system allowed to change a password. CyberArk's own migration scripts tell you to stop the CPMs, its password-changing service, in both environments while accounts move, and the same idea applies across vendors.

The two products describe the same jobs with different objects. The table pairs them up, so you can see where the gaps are before anyone writes an import file. CyberArk terms come from its public scripts and Palo Alto's pages, since CyberArk's documentation site wasn't loading when we checked.

Two rows deserve a closer look. Service account dependencies are where migrations break production, and they're often the least documented part of the vault. A Secret Server reviewer on PeerSpot put it plainly: most people are unsure where their service accounts are used, so resetting one to make it compliant feels like a gamble.

The approval row is the other trap for anyone heading to Delinea's cloud. Delinea's docs say a secret with Require Approval, Require Comment or Double Lock switched on won't sync to the Delinea Platform. If dual controldefinitionCyberArk's rule that someone has to approve a request before the user sees the password. In Secret Server you'd set Require Approval for Access instead. is how you pass audits today, check which secrets would drop out of the Platform view before you copy the policy across.

Getting the data out is the easy half. CyberArk publishes PowerShell scripts on its GitHub that list and export account details over the REST API, and another set that exports platforms. Its REST migration module says the account that runs the export needs the right to retrieve accounts in each safedefinitionCyberArk's container for accounts. You add people as safe members, and their rights there decide whether they can list, use or manage what's inside.. The same notes warn that membership in Vault Admins or Auditors pulls every account, so use a dedicated export user with exactly the safes in scope.

Secret Server takes the data in two ways. A CSV import adds secrets of one template at a time, and an advanced XML import can create folders, templates and secrets together. The XML import can only be run by administrators with the right role permissions. Users and groups have to exist on the Secret Server side first, and file attachments such as key files only go in through the API.

If the destination is Secret Server Cloud, Delinea says XML isn't the route between on-premises and cloud editions and points to professional services or the API instead. It also asks you to set duplicate secret names to Prevent Duplicates Globally before importing. Check that setting early, and rename any CyberArk accounts that would end up with the same secret name before you import.

Going the other way, the export comes from Secret Server's own CSV or XML export. It only includes secrets the exporting user can view, it asks for the admin password, and it leaves out users, groups, launchers and configuration. Delinea's hardening guide suggests a separate role holding just the export permission, which is worth setting up before the project instead of handing someone full admin.

Some secrets need extra handling. Keeper's documentation for its own Secret Server importer notes that TOTP codes stored in Secret Server can only be pulled out through a manually downloaded CSV, and that XML exports carry neither attachments nor permissions. Check your templates for TOTP fields and attachments before you promise anyone a date.

CyberArk's GitHub has the pieces for loading. Its Account Onboard Utility reads a simple CSV and creates accounts and safes, and with a template safe it copies the CPM and safe members onto each new safe. Separate scripts add logon, enable and reconcile links and onboard dependencies such as Windows services, scheduled tasks and IIS app pools.

Put that in the business case. If your real problem is running servers and patching the vault, a move to the same vendor's SaaS comes with vendor tooling. A switch between vendors puts all the mapping on your team or your partner, so put that effort in the business case, not just the licence price.

• Keep one template or platform per target type, named the same in your runbooks. Fewer special cases means fewer things to map next time.
• Record every dependency in the vault itself, not in a spreadsheet beside it. Both products can update services and tasks when a password changes, but only for the ones they know about.
• Give each service account a named owner. The PeerSpot reviewer's problem, nobody knowing where an account is used, goes away once someone answers for each one.
• Put the export right in its own role and review who holds it, as Delinea's hardening guide suggests.
• Keep a change log of approval rules and session-recording settings, so the next team can see why each one exists.

We implement and upgrade both platforms, and a migration between them starts with counting: accounts per type, dependencies and approval rules. Then we build and test the rotation on the new side before any password moves. See our CyberArk and Delinea pages, bring in PAM engineers, read how our privileged access practice works, or start with an assessment. If you're still choosing, our CyberArk, Delinea and BeyondTrust comparison covers the buying side.