#Database Migration

A personnel database that never enforced its rules had to become clean data for a new system while the old one kept running. Ordered, repeatable phases behind a read-only door, explicit maps, honest placeholders and a report instead of a crash made that possible.

Four commands that move a stack from its old layout into a new structure across major versions: export without changing the source's data, import each store the way its version allows, verify what really arrived, and rename modules while moving their data along.

Three commands that take a tested release into production without overwriting what production owns: they promote configuration structure but keep its secrets and addresses, refuse to copy new secrets, and apply schema migrations the images carry.

Release Workflow: Development to Production is the procedure every change of mine follows from my laptop to production — which steps I automated, which I deliberately left to a person, why each step sits where it does, how I diagnose a failed release, and how I recover from it.

Its software reached the end of support, and its records must outlive it. One component rewrote data as it read it, so the migration copies rather than converts — an operation with no rollback has to be survivable, not merely careful.

Staging and production shared 136 keys, but 21 had to stay different, including the one that decrypts years of data. Promoting a release's structure, not a file's contents, keeps that key in place and stops a schema migration from silently never running.