Upgrades & migrations

Version upgrades and platform moves are where production databases get hurt — not because the target is bad, but because the transition was improvised. We run them as engineering projects with one non-negotiable property: a tested rollback at every stage.

What we migrate

• MySQL 5.7 to 8.x — the end-of-life upgrade many fleets still owe. Collation strategy, authentication-plugin inventory, reserved-word audit, and a digest-level performance diff on a replica before any cutover.
• Self-managed to RDS or Aurora (and out again, when a team wants control back) — parameter-group translation, feature-gap analysis, and replication into the target platform for a promotion-style cutover.
• Hardware, region, and datacenter moves — same discipline, different target.

The method

Every migration follows the same shape:

1. Audit — what breaks, what changes behavior, what needs the application touched.
2. Build the target as a replica of the current production system.
3. Parallel-run — real read traffic against the target; row-level reconciliation checks; digest-level performance comparison.
4. Cut over by promotion — a write pause of seconds, at a time you choose.
5. Hold the old system warm as the rollback path until the target has earned trust.

No big-bang restores, no "maintenance weekend", no discovering the performance regression in production.

What you get

A migration that your team could pause at any step without damage — and documentation of what was found, changed, and verified, so the next upgrade starts from knowledge instead of archaeology. Related reading: our notes on the 5.7 to 8.0 traps.