Outdated library migration plan

You are a senior engineer planning a safe dependency modernization. The goal is fewer outages and security problems, not a big rewrite. Inputs - Language, framework and version: {{stack}} - Current dependencies with versions: {{dependency_list}} - What the application does and how critical it is: {{app_context}} - Constraints (release freeze, team size, downtime allowed): {{constraints}} Steps 1. Classify each dependency as: current, aging (still supported), end-of-life or unmaintained, or unknown. If you are not sure about a library's support status, say so rather than guessing, and tell me what to check. 2. Rank the ones needing action by impact: effect on reliability, security, performance, and how many parts of the code touch them. 3. For each, suggest a replacement or upgrade path, the main breaking changes to expect, and the effort (small, medium, large). 4. Group the work into phases so each phase can ship on its own. Put low-risk, high-value changes first. 5. For each phase, define how to test it (existing tests, new tests, a staged rollout) and how to roll back. 6. List things that should NOT be changed now and why. Output format - Summary: three sentences - Table: dependency | status | risk | proposed action | effort - Phases: goal, items, tests, rollback - Open questions for the team Quality bar - Do not invent version numbers, release dates or vulnerability identifiers; mark anything uncertain as "verify". - Prefer maintained, widely used options and explain the trade-off. - Keep each recommendation to two sentences.

You are a senior engineer planning a safe dependency modernization. The goal is fewer outages and security problems, not a big rewrite. Inputs - Language, framework and version: {{stack}} - Current dependencies with versions: {{dependency_list}} - What the application does and how critical it is: {{app_context}} - Constraints (release freeze, team size, downtime allowed): {{constraints}} Steps 1. Classify each dependency as: current, aging (still supported), end-of-life or unmaintained, or unknown. If you are not sure about a library's support status, say so rather than guessing, and tell me what to check. 2. Rank the ones needing action by impact: effect on reliability, security, performance, and how many parts of the code touch them. 3. For each, suggest a replacement or upgrade path, the main breaking changes to expect, and the effort (small, medium, large). 4. Group the work into phases so each phase can ship on its own. Put low-risk, high-value changes first. 5. For each phase, define how to test it (existing tests, new tests, a staged rollout) and how to roll back. 6. List things that should NOT be changed now and why. Output format - Summary: three sentences - Table: dependency | status | risk | proposed action | effort - Phases: goal, items, tests, rollback - Open questions for the team Quality bar - Do not invent version numbers, release dates or vulnerability identifiers; mark anything uncertain as "verify". - Prefer maintained, widely used options and explain the trade-off. - Keep each recommendation to two sentences.

Summary: Two of eleven dependencies need action soon; the rest can wait for the next quarter. Table Dependency | Status | Risk | Action | Effort Connection pool library A | Unmaintained (verify) | High: affects every request | Move to the pool bundled with the framework | Medium HTTP client B | Aging | Medium | Upgrade one major version | Small Phase 1 (one week): swap the connection pool behind a feature flag. Tests: run the integration suite and a load test at 2x normal traffic. Rollback: flip the flag back. Not now: replacing the ORM; the benefit does not justify the risk this quarter. Open questions: Is a short maintenance window allowed?