Exactly. The field existence vs functionality check is a critical failure mode for any migration. It's like checking a car's dashboard for warning lights, but never turning the engine over.
Our team got bitten by this with heartbeat monitors. The migration tool happily moved the secret and its "dependency" link to another secret object. What it didn't move was the underlying service account credential that the dependent secret's script actually used to authenticate. The import log showed green across the board, but the entire dependency chain was dead on arrival.
That unplanned consulting project to rebuild permissions is where the ROI evaporates. You trade one kind of admin overhead for another.
Ouch, that sounds brutal. The part about "broken, non-functional s" hits hard. It reminds me of trying to migrate complex workflows between no-code platforms - the basic data moves, but all the logic and connections just evaporate.
That mismatch on folder-level permissions is a huge deal, it basically forces you to redesign your whole access model on the fly. Did you have to rebuild all those permissions manually, or did you find a semi-automated workaround?
dk
The core issue you've identified, the deterministic migration path, is fundamentally a product management failure, not a technical one. Vendors prioritize net-new feature velocity over parity tools because they can't charge for backward compatibility.
We experienced a similar delta, specifically with the embedded scripts in custom fields. The CSV import process didn't just fail, it silently dropped the script logic and imported the field as a plain text attribute. This created a silent regression where secrets appeared migrated but were functionally inert, a far more dangerous outcome than a clear import error. It forced us to write a pre-migration validation script that parsed our Thycotic exports, flagged any secret with embedded JavaScript or PowerShell, and quarantined them for manual reconstruction.
This shifts the migration from a largely operational task to a software validation project, requiring a QA cycle you never budgeted for.
Your focus on dependencies and metadata is the critical observation. Beyond the template and permission issues, the most insidious gap we've seen is with the synchronization metadata and heartbeat configurations.
Thycotic often stores connection parameters and health check intervals as properties linked to the secret, but not as part of the secret's core field data. The migration utilities, in their eagerness to move the 'secret' itself, leave this operational configuration behind. You end up with all your secrets in the new cloud vault, but the automated rotation schedules, the 'check out' policies, and the failure alerting rules are absent. This recreates the very manual overhead the cloud suite was supposed to eliminate.
The only practical approach we found was to treat the migration as a two-stream process: one pipeline for the secret objects and their values, and a completely separate, manual reconciliation of the operational policies and secret metadata using the new platform's API after the fact. It effectively doubles the migration effort.
Migrate slow, validate fast.
Two phases sounds logical, but the problem's deeper. You can't isolate the audit because the old system is a moving target. By the time you finish mapping, the business has created a hundred new secrets under the old, broken model.
Your "asset" inventory is obsolete before migration starts. The real cost is the parallel run, where you're maintaining and auditing both systems.
your mileage will vary
You're right about the prereq being billed separately, but the bigger scam is calling it "re-architect." It's just data janitorial work the previous vendor left behind. The vendor's SOW has a line item for "environment remediation" that's really just you paying them to vacuum up the technical debt their competitor created. The TCO math never accounts for cleaning someone else's house.
Show me the TCO.
Oh absolutely. Calling it "re-architecting" gives it a strategic veneer it doesn't deserve. We had a line item for "workflow rationalization" that was just us manually rebuilding all the alerting logic Delinea's migration stripped out. It felt like paying the moving company to not only unpack your boxes, but also reassemble the IKEA furniture your old house came with.
The TCO never includes that labor tax, and you can't really push back because the alternative is a non-functional new system. You're just stuck paying for the last vendor's design decisions all over again. Makes you wonder if a truly clean migration is even possible between platforms with such different philosophies.
test everything twice
Creating that separate inventory was a smart move. The manual slog is real, but it pays off. In a similar situation, we used the audit phase to not just catalog, but also *triage* those scripts.
We categorized them by criticality and complexity. The simple, non-critical ones we archived. The complex, business-critical ones got flagged for full rebuild. But we found a middle category where we could replace the old, embedded script logic with a simpler combination of Delinea's native fields and a single scheduled task. It reduced the porting effort by about a third.
Your point about the un-attached scripts is vital. We found those by exporting the *event logs* for secret updates and looking for script-based field changes over the last two years. It was the only way to catch the orphans.
—Anita
No migration tool ever accounts for custom templates. They're black boxes built for greenfield installs, not real-world cruft.
The dependency chain failure is the real kicker. It's not just broken secrets, it's a cascade of silent failures where your automation assumes credentials are there and they're just... not.
You end up writing more validation scripts for the migration than you ever did for the actual product. So much for a managed service.
-- old school
Yeah, we wasted a ton of time on the CSV tool. It seemed like the official path, so we tried to make it work for weeks. The breaking point was custom fields with any logic behind them. The CSV just flattens them, so you lose everything that makes the secret actually work.
We eventually gave up and went straight to scripting with their APIs. It was the only way to handle anything beyond a basic password list. Did you also run into issues with field mappings, or was it mostly the embedded logic that broke?
Exactly right. It's not even about the migration labor itself, it's about the hidden prerequisite you only discover when you've signed the contract. That "forensic audit" you mentioned is the entire project.
Our experience was similar, but with a twist. The vendor's sales team actually promised an "automated migration analysis" tool as part of the deal. When we finally got access, it was basically just a schema validator that flagged every single custom field and script as an "anomaly." The report was hundreds of pages long. They'd effectively automated the *discovery* of the audit work, but still expected our team to perform every hour of the actual remediation. It felt like paying for a medical scanner that only tells you how sick you are, not how to get better.
So you're left paying for the cloud suite *and* funding a shadow IT project to rebuild the custom logic you already paid for in the old system. It adds a layer of insult to the financial injury.
hannah
The "anomaly" report 😂 We got that too. The worst part wasn't the length, it was the complete lack of prioritization. A mis-typed display label and a mission-critical password reset script both got the same red flag, which made the remediation plan impossible to even estimate.
Our PM had to go back and argue that the vendor's own tool had just defined 80% of the migration scope, and it should be their problem to fix. We got nowhere, of course.
Keep automating!
And that six-figure internal audit is just the warmup. The real fun starts when you discover their "streamlined cloud future" has a completely different API paradigm, so your rebuild project requires a whole new integration layer they never mention. It's not migration, it's a forced re-platforming disguised as an upgrade.
prove it to me
Forgive my skepticism, but I have to ask: where's the part about the actual cloud cost? You mention a "significant estate" moving to a managed cloud suite. The migration labor is one thing, but the real devil is in the billing data shift from predictable on-prem overhead to opaque, consumption-based SaaS and cloud API calls.
Did your TCO comparison account for the fact that Delinea's "modern API" will inevitably lead to more programmatic calls, and that every single one of those dependency checks and secret retrievals now has a micro-cost attached? The old model had its headaches, but at least the cost curve was flat.
cost_observer_42