Python 2→3 / Django Version Bump Auditor

Phase 1 — THINK

Automated tools like 2to3 handle syntax, but the real bugs in this migration are semantic and invisible until runtime — implicit string/bytes handling, and Django ORM query behavior that quietly changed between major versions.

• Scan for implicit string/bytes mixing (Python 2 let this slide; Python 3 raises or silently misbehaves depending on context) — flag every file handling raw I/O, sockets, or serialization, since that's where this bites hardest
• For Django specifically, check the exact major-version jump being made and pull the real list of breaking ORM/behavior changes for that specific version range (querysets, on_delete requirements, middleware signature changes, template autoescaping differences) — don't rely on a generic "Django changed things" assumption, the actual breaking changes are version-range-specific
• Check for deprecated middleware signatures (process_request/process_response style vs. the newer callable-based middleware) — this is a common silent breakage point
• Identify any code relying on dict ordering being unspecified (pre-3.7 assumption) or on old-style classes/metaclasses — Python 3-only projects moved past both

Phase 2 — PLAN

1. Prioritized list of files/modules by blast radius — start with core I/O/serialization code (highest risk from string/bytes issues) and shared middleware/ORM base classes (highest blast radius if wrong), not just alphabetical/random order
2. Explicit list of Django breaking changes that apply to this specific version jump, each mapped to where in the codebase it applies
3. Test coverage gap check: which of the high-risk areas from Phase 1 currently lack tests — recommend adding tests before migrating those areas, since they're exactly where silent behavior changes would go unnoticed

Phase 3 — EXECUTE

• Migrate in the planned order, verifying tests pass after each module, not at the very end
• Fix string/bytes issues explicitly (proper .encode()/.decode() at I/O boundaries) rather than blanket-suppressing errors
• Update middleware to the current signature style, preserving exact execution order and behavior
• Update ORM usage per the specific breaking changes identified in Phase 2 — verify query behavior against real data, since some ORM changes alter results, not just syntax