Old self-host VPS decommission, gated on validation sign-off

[JSONbored]

Part of #4325.

Context

Per the epic's constraint, the old host is not decommissioned on a timer — only after the new host has been live with real traffic for a burn-in period and the validation criteria continue to hold under real (not shadow) load.

Requirements

• A stated minimum burn-in period on real traffic before decommission is even considered (this issue should propose a number and reasoning, not leave it open-ended).
• Final data-parity check (Postgres/Qdrant) immediately before decommission, in case any late write landed on the old host through an edge case in the cutover.
• A last full backup of the old host's data taken and verified restorable before it's powered off, independent of whatever's already on the new host — a migration bug discovered later should not be an unrecoverable data-loss event.

Deliverables

• Burn-in period proposed, agreed, and observed in full before this issue proceeds further
• Final parity check confirms no data landed on the old host after cutover that's missing on the new one
• Independent final backup taken and a restore of it test-verified
• Old host decommissioned only after all of the above are checked off

Expected outcome

The old host is safely retired with zero data loss and a verified final backup, only once the new host has proven itself under real production load, not before.

Effort

S

[linear-code]

JSO-3310

[JSONbored]

Status check (2026-07-09) — flagging this one for your direct attention, not closing it.

A comment on #4327 (posted 2026-07-09T02:00:50Z, about 5 hours after this epic was created) mentions in passing that "old host is now decommissioned." I found no other public record of this issue's actual requirements having been carried out first:

• No stated/agreed burn-in period on real traffic before decommission was considered.
• No documented final data-parity check (Postgres/Qdrant) immediately pre-decommission.
• No documented independent final backup of the old host's data, and no restore-test confirmation.

I can't verify any of these after the fact — the old host is (reportedly) gone, so there's no way for me to independently check whether a final backup exists and is restorable. This issue's own hard constraint is that decommission happens only after validation criteria continue to hold under real load, not on a timer — and the compressed timeline (epic created → reportedly decommissioned in ~5 hours) is hard to reconcile with a real burn-in period.

Could you confirm directly: does a verified, restorable final backup of the old host actually exist somewhere? If yes, this can close with that pointer recorded (even just "confirmed privately, backup at X"). If the backup step was skipped, better to know that now while it might still be recoverable than after. Not closing this myself given the stakes.

[JSONbored]

Closing per owner confirmation (2026-07-09): the old host has been decommissioned/wiped and repurposed for a different use, which is an accepted, deliberate outcome rather than an oversight of this issue's burn-in/parity-check/backup gating. Noting for the record that I could not independently verify a pre-decommission backup was taken (the flag I raised in my prior comment) — closing based on direct owner authority, not independent re-verification.