Assessment Phase
Generate a migration assessment report before any code changes.
Prerequisites
- Workspace contains AWS Lambda functions, SAM templates, or CloudFormation templates
- Prompt user to upload relevant files if not present
Assessment Steps
- Identify Functions — List all Lambda functions with runtimes, triggers, and dependencies
- Map AWS Services — Map AWS services to Azure equivalents (see lambda-to-functions.md)
- Map Properties — Map Lambda properties to Azure Functions properties
- Check Dependencies — List 3rd-party libraries and verify Azure compatibility
- Analyze Code — Check language support and runtime differences
- Map Triggers — Identify equivalent Azure Functions triggers
- Map Deployment — Identify equivalent Azure deployment strategies (CLI, Bicep, azd)
- Review CI/CD — Check pipeline compatibility with Azure DevOps or GitHub Actions
- Map Monitoring — Map CloudWatch → Application Insights / Azure Monitor
Code Preview
During assessment, show a sneak peek of what the migrated Azure Functions code will look like for each function. Use bindings and triggers (not SDKs) in all previews, following Azure Functions best practices. Always use the newest generally available (GA) language runtime listed in the Azure Functions supported languages documentation in previews (for example, the latest Node.js LTS or newest Python GA version). This helps the user understand the migration scope before committing to code migration.
⚠️ Binding-first rule: Code previews MUST use
input.storageBlob(),output.storageBlob(),app.storageQueue(), etc. instead ofBlobServiceClient,QueueClient, or other SDK clients. Only use SDK for services that have no binding equivalent.
Architecture Diagrams
Generate two diagrams:
- Current State — AWS Lambda architecture with triggers and integrations
- Target State — Azure Functions architecture showing equivalent structure
Assessment Report Format
⚠️ MANDATORY: Use these exact section headings in every assessment report. Do NOT rename, reorder, or omit sections.