Upgrade Planning Mode B Prechecks Checklists

6. Live Database Prechecks

Ask the customer how to connect:

1. SSM Run Command — requires an EC2 instance ID in the same VPC and DB credentials
2. RDS Data API — if enabled, no extra infrastructure needed
3. Direct connection — if publicly accessible or a tunnel is set up
4. User runs the script — you generate the SQL, the user pastes results back

Then run the MySQL precheck queries from prechecks-mysql.md.

Constraints:

• You MUST ask the user to choose the connection method — do not pick for them
• You MUST NOT create, access, or store AWS credentials or DB passwords directly. Use inline JSON payloads for SSM, user-supplied secret ARNs for Data API, or pre-configured tunnels for direct
• You MUST categorize every finding with one of: 🔴 Critical (blocks upgrade), 🟡 Warning (behavior change), 🟢 Clean
• You MUST generate a recommended parameter group configuration based on findings rather than returning raw query output

7. Query Load Analysis (Optional)

After schema prechecks, offer to analyze top queries. Use query-load-mysql.md.

Constraints:

• You MUST run EXPLAIN in the MySQL format: EXPLAIN FORMAT=JSON
• You MUST categorize each query’s upgrade risk with the same three-color system as task 6
• You SHOULD present findings in a compact table (summary, plan issue, upgrade impact, action) rather than raw EXPLAIN output

8. Pre- and Post-Upgrade Checklists

Provide:

• Pre-upgrade steps from pre-checklist.md
• Post-upgrade validation from post-checklist.md

You MUST also surface the engine-specific upgrade blockers and required cleanup items directly in your response — do not leave them buried in the precheck files the user hasn’t opened. These are the items that most commonly cause upgrade failures or silent breakage.

For Aurora MySQL, surface at minimum (from prechecks-mysql.md):

• 🔴 Reserved keywords added in 8.0 used as unquoted identifiers — blocks queries post-upgrade.
• 🔴 Removed data types / SQL features (e.g., utf8mb3 as default, PRE_5_6_26_UTF8_JSON flag, deprecated spatial functions).
• 🟡 sql_mode and default charset/collation changes — utf8mb4_0900_ai_ci becomes the default; application assumptions about collation ordering will shift.
• 🟡 Query cache removal (5.7 → 8.0) — if the cluster relied on query cache, expect CPU/latency delta after upgrade.
• 🟡 Authentication plugin changes — MySQL 8.0 defaults to caching_sha2_password; older clients may need mysql_native_password.

Constraints:

• You MUST include engine-specific sections of each checklist, not just common steps
• You MUST surface the engine-specific blockers inline in your response using the 🔴/🟡/🟢 taxonomy — listing only the file path is insufficient because users don’t follow those references unprompted
• You MUST explicitly address items that don’t apply to this upgrade path (e.g., state “Query cache removal — not applicable when upgrading Aurora MySQL 8.0 → 8.4, only relevant from a 5.7 source”) rather than silently omitting them; otherwise the user can’t tell whether you checked or forgot
• You MUST NOT execute any modify-db-cluster --engine-version command because this workflow is planning-only and production upgrades must go through the customer’s change process
• You MUST recommend testing on a snapshot-restored cluster before production upgrade
• You SHOULD surface relevant documentation from documentation-links.md

For post-upgrade validation when the user reports a completed upgrade, see post-upgrade-validation.md.