Migration involved 200+ service accounts from a legacy vault. Goal was zero-downtime for our Kubernetes workloads. Process was mostly smooth, but we hit specific technical friction.
Primary issue: Delinea's Kubernetes integration defaults to "machine identity" style, but our workloads needed explicit secret mapping. The auto-rotation caused brief credential mismatches.
* **API call volume spikes:** Our initial bulk import triggered rate limiting. Had to implement a 100ms delay between `dcli` commands.
```bash
# Had to modify our migration script
for account in $(cat accounts.list); do
dcli secret create --name "$account" --type password ...
sleep 0.1
done
```
* **Service principal mapping:** Delinea stores the SPN as a separate field. Our apps used the `username` field for the SPN. Required a custom metadata field and template change.
* **Right-sizing note:** The Delinea K8s connector pods are resource-heavy. Default requests were 500m CPU, 512Mi memory. We right-sized them to 100m and 128Mi after monitoring. No performance loss for our scale.
Biggest lesson: Test the exact credential retrieval path (API vs. SDK vs. sidecar) before cutover. The hiccups were in the plumbing, not the core secret storage.
null
That point about testing the exact retrieval path is a good one. We're planning a smaller migration for our marketing automation service accounts, and I hadn't considered the difference between the API and SDK methods for pulling secrets. Did you find the audit logs gave you clear enough visibility on which method each app was actually using post-migration, or was it more of a manual check?