Scaling Python 3.8/3.9 → 3.12 Lambda Runtime Migration Using Poetry + GitHub Copilot Agent Skills — Validating Approach Before Full Rollout

Your proposed approach is architecturally sound and aligns with AWS best practices for large-scale Lambda migrations. The phased strategy—libraries first, then functions—is the recommended sequencing pattern and will minimize risk and dependency conflicts.

Regarding Your Specific Questions:

1. Scalability and Failure Patterns: Your approach is sound. The key risk to account for upfront is the time-intensive nature of manual migrations at scale. For 800+ Lambda functions, manual updates would typically require 15-30 minutes per function, translating to 200-500 person-hours of effort. Your AI-assisted automation should reduce this by 97-99%. Critical failure patterns to watch for include: runtime-specific code that may break between Python versions, dependency version conflicts when libraries are updated incrementally, and functions that may have hardcoded references to older library versions.

2. AWS-Native Guardrails: Yes, several should be incorporated:

• Implement thorough testing in non-production environments before production rollout
• Back up all Lambda function configurations before migration
• Implement the upgrade in phases rather than all at once
• Verify function behavior after each upgrade
• Consider implementing logging functionality to track migration progress and issues
• Add error handling and rollback capabilities to your automation
• Use a dry-run mode for testing before actual updates

3. Recommended Sequencing: Your instinct is correct—migrate and stabilize ALL libraries in CodeArtifact before touching Lambda functions. This "libraries-first" approach prevents dependency resolution failures and ensures that when you begin function updates, all required dependencies are available and tested. A progressive library-by-library approach alongside function updates would create a complex dependency matrix that's difficult to manage at your scale and increases the risk of runtime failures.

4. Poetry-Specific Considerations: While the sources don't detail Poetry-specific differences between Python 3.9 and 3.12 for CodeArtifact, be aware that you'll need to ensure your pyproject.toml files correctly specify Python 3.12 compatibility and that all dependencies are resolved against the new runtime. Test the full publish-consume cycle in a non-production CodeArtifact repository first.

Additional Best Practice Recommendations:

• Timeline Awareness: After December 15, 2025, Python 3.9 will no longer receive security patches. After February 15, 2026, you won't be able to update existing Python 3.9 functions at all, making this migration time-critical.

• Phased Rollout Strategy: Consider grouping your 800 functions by criticality and business impact. Migrate lower-risk functions first to validate your process before touching mission-critical workloads.

• Automated Validation: Build automated smoke tests that can be run against each migrated function to verify basic functionality before considering the migration complete.

• Documentation and Tracking: Maintain detailed records of which libraries and functions have been migrated, including version numbers and any issues encountered. This will be invaluable for troubleshooting and rollback scenarios.

Your AI-assisted approach with standardized patterns is exactly the right strategy for managing this scale of migration efficiently while maintaining consistency and reducing human error.
Sources
Automated Migration Script for AWS Lambda Python 3.9 End-of-Support | AWS re:Post