iServ
iServ Platform Estate Migration
A portfolio of production builds moved onto company-owned infrastructure, with the database and file store verified at full parity before anything was switched.
01 The story
Builds that start fast usually start on whatever infrastructure is nearest, and the hard part comes later: moving them to their long-term home without losing a row, a policy, or a file. This migration did it as a playbook first and an execution second. Seven repositories now live in the company's GitHub organization with private archive mirrors, DNS was verified by live lookup, and the shared database moved Postgres to Postgres with every table, row, row-level security policy, function, trigger, index, and auth user counted on both sides. The file store moved with a fourteen-second public window, closed automatically by a trap even if the script failed. Every script is dry-run unless told otherwise. An attempt to merge three apps into one shell was reverted when a framework version gap made it unsafe, and replaced with a federation plan instead.
02 What went into it
- Written runbook, stack spec, environment manifest, and federation plan before any move
- Repository transfers into the company organization with archive mirrors on the Luminary side
- Postgres-to-Postgres migration with source-versus-target parity checks across every object type
- Storage migration with automatic re-lock and name-and-size verification
- Scheduled jobs captured with secrets redacted and deliberately not recreated until cutover
- Token-only deploy script that needs no GitHub app installation
- Every script dry-run by default; nothing executes without an explicit flag
- Consolidation attempt reverted on a version gap, replaced by multi-zone federation
03 Stack and capabilities