Migrating to Centralized Secrets

Migration is the hard part. The vault architecture is straightforward. Moving every hardcoded credential, every environment variable, and every config file secret into the vault — without breaking any of the agents that depend on them — is a project that requires precision, sequencing, and the uncomfortable discipline of touching every integration in the system.

1. Phase 1: Parallel Operation Deploy the vault alongside existing secret storage. Create vault entries for every mapped secret. Update agents to read from the vault with a fallback to the existing location. Verify that every agent functions correctly with vault-sourced secrets before removing the fallback.
2. Phase 2: Cutover Remove the fallback. Agents now read exclusively from the vault. Monitor for any agent that fails — a failure at this stage means a secret consumer was missed in the mapping phase. Fix the mapping. Do not revert to the old location.
3. Phase 3: Cleanup Delete every secret from its old location — environment variables, config files, container images, CI/CD variables. Then rotate every secret that was ever stored in a non-vault location. The old credential is compromised by definition — it existed in an uncontrolled location for an unknown duration.