Moved from Thycotic to Delinea Cloud Suite - migration pain points

Oof, that line about the migration tools "focusing on basic secret and user data" is painfully familiar. It's like they built the tool for the sales demo where you have ten generic passwords, not for an actual deployed instance with a decade of organizational cruft.

You mentioned complex dependency chains breaking. That was the silent killer for us, too. A secret template with a pre-launch script that pulled a value from another secret just... stopped. No errors in the import log, because the tool only validates field *existence*, not field *functionality*. You don't discover the break until a rotation fails weeks later.

The permission mapping is its own special hell, isn't it? Thycotic's folder-level granularity versus Delinea's more role-centric approach meant we had to manually rebuild dozens of effective permissions as explicit roles. The promised "managed service" suddenly required a massive, unplanned consulting project just to reach parity. So much for a reduction in admin overhead.

That point about custom secret templates and embedded scripts failing silently is a huge concern for me. We're evaluating a similar move, and our templates aren't just about layout - some have custom scripts for pre-populating fields based on other directory lookups. It sounds like the Delinea import process strips that logic out, leaving a static, and eventually stale, shell of a secret. Did you find any way to at least document these functional dependencies pre-migration, or was it purely a process of discovery after the fact? The thought of that hidden breakage waiting to happen weeks later is a major project risk.

Ugh, exactly this. We're about 3 weeks into our pilot migration and hit the same wall with custom fields and scripts just vanishing.

> fail catastrophically on dependencies and metadata

This is so true. Our "pilot" secrets imported, but the heartbeat monitoring rules tied to them? Gone. The tool didn't flag them as missing, we only noticed because our alerting dashboard went quiet.

Did you have to rebuild all your secret templates from scratch in Delinea first, *then* try to map the CSV import to those new templates? That's what their support suggested to us, and it feels like we're manually recreating half the system before we even migrate.

You're absolutely right about the core issue being the data model delta. The standard CSV import treats a secret as a flat row, but the true value, and complexity, is in the object graph surrounding it.

We found the only viable path was to abandon the GUI tools entirely and build a custom migration harness using their GraphQL API. Even then, it was a two-phase process: first, a script to audit and document the Thycotic object graph (templates, dependencies, scripts), then a separate set of scripts to recreate those structures natively in Delinea *before* any secret data was moved. This meant building new secret templates, re-implementing scripts as Delinea-approved "Webhooks" or "Password Changers," and establishing a new permission matrix. Only then could we map and transfer the actual secret *values*.

The hidden cost wasn't just in the migration effort, but in the permanent operational shift. Those custom Thycotic scripts now require maintenance in Delinea's entirely different execution model, which has its own limitations and review cycles.

I'm considering a similar move and this is exactly the kind of detail I need. The mention of "data model delta" is key. Did you find the GraphQL API approach mentioned later in the thread to be the only real option from the start, or did you waste time trying to make the official CSV tool work for complex cases first?

Your concern about hidden breakage is the most valid risk assessment you can make. The documentation phase is the only thing standing between you and a silent catastrophe.

We attempted a pre-migration audit using Thycotic's own reports and a PowerShell script to dump template properties and script bodies. It created a map, but it was purely informational. The real work, as you guessed, was rebuilding the logic. That "pre-populating fields based on other directory lookups" script? In Delinea's model, that had to become a dedicated connector configuration or a pre-launch webhook. The import doesn't translate it, it ignores it.

So the answer is both: you must document exhaustively before the move, but that documentation becomes your rebuild checklist for the new platform. The discovery after the fact is just troubleshooting the items you missed on that checklist.

Oh, the "promise of a managed service" is always the most expensive part. Did you ever get a clear TCO breakdown from Delinea that included the engineering hours for this custom scripting work? Or were those migration costs just silently absorbed into your project's burn rate? Everyone sells the sunset of on-prem maintenance, but they're awfully quiet about the sunrise of cloud migration labor.

Absolutely, that hidden breakage is the project killer. You need to treat your custom scripts as first-class objects, not metadata.

Our team created a separate inventory database just for cataloging every script, its triggers, and its dependencies on other secrets or directories. It was a manual slog, pulling from report logs and the Thycotic database directly. The scary part was discovering scripts that weren't attached to templates, but to individual secret fields via old plugin systems.

This audit didn't help the auto-migration, but it gave us a fighting chance. Each script became a ticket to rebuild as either a Delinea webhook or a scheduled task. Without that map, you'd be fixing things reactively for months.

That last point about the inventory database being a manual slog is where the real TCO hides. We found that the labor for that audit phase, done properly, often exceeded the initial migration estimate itself.

Your method of treating scripts as first-class objects is correct, but the cost of that treatment is rarely in the vendor's pre-sales scope. It's a classic lift-and-shift versus re-architecture problem, only the "re-architect" labor is billed as a prerequisite for the shift.

You've hit on the exact budgeting trap. That "re-architect prerequisite" cost is almost never in the migration plan, it's buried in "discovery" or "planning."

We had to explicitly separate the project into two funded phases: the audit/inventory phase and the execution phase. Vendors love to scope the second one, but the first one is where the real time and risk live. It meant going back to procurement to adjust the business case, because the TCO started with months of manual labor before a single secret moved.

It turned a technical migration into a business process re-engineering project overnight.

Bingo. That "business process re-engineering project" line is the real invoice they never show you. It's the vendor's favorite shell game. They sell you a streamlined cloud future, but the price of entry is a full forensic audit of your own legacy system, labor they conveniently don't provide.

We tried to get that audit work quoted as a professional services add-on from the vendor once. The quote was stratospheric, which just proved the point. They know it's the hard part. So they leave you to discover it's a 6-month, six-figure internal effort *before* you can even use their shiny new platform. The TCO starts the moment you realize your old tool's "customizations" are now your own rebuild project.

The "six-figure internal effort" is the quiet part everyone should be yelling. But it's worse because that cost isn't a one-time project burn, it's a permanent shift in operational expense. That audit phase doesn't just end at migration, it becomes the ongoing cost of understanding your own Franken-platform because you now own the entire integration layer the vendor didn't build.

Your stratospheric professional services quote proves the model: they've priced the labor at a point where you're forced to insource it, effectively making you their unpaid systems integrator. The real TCO includes the senior engineer you have to keep on staff forever who understands the custom harness, not the junior admin the sales deck promised could run the managed service.

Exactly. That's the procurement pivot no one prepares for. It's not just about separating the audit into its own phase, it's about how you justify its funding.

You can't just call it "discovery" anymore, that gets rolled into the migration budget. You have to brand it as "legacy system decomposition" or "technical debt inventory," something that sounds like a distinct deliverable with its own ROI. Otherwise, the business just sees one expensive migration project getting more expensive, not two separate problems.

We had to show that the audit's output, the inventory, was an asset in itself. That it could be used for security compliance, onboarding, and future migrations. Turning a cost center into a capitalizable asset was the only way to get the extra six months signed off.

Oh, the data model mismatch is the silent killer. Your point about folder-level permissions is key. Thycotic's inheritance model could get incredibly granular, almost like NTFS permissions on a secret. Delinea's role-based approach collapses that into broader categories, and the mapping is lossy.

We hit the same wall with secret templates. The CSV import expects a flat structure, but a template with dependent fields or custom validation scripts is a *program*, not a row of data. We ended up having to rebuild those templates manually in the Delinea UI first, capturing the new IDs, *then* trying to import secrets mapped to the new template IDs. Even then, embedded logic was just stripped out.

It feels less like a migration and more like a manual porting project where the new platform provides the blank canvas but none of the original paint.