paulasilvatech Azure Cloud Migrate
This skill handles assessment and code migration of existing cloud workloads to Azure.
When to invoke
- "Migrate this AWS Lambda function to Azure Functions."
- "Move our Heroku or App Engine app to Azure App Service."
- "Convert this Cloud Run or Fargate workload to Container Apps."
- "Assess our cross-cloud workloads for migration to Azure."
Rules
- Follow phases sequentially — do not skip
- Generate assessment before any code migration
- Load the scenario reference and follow its rules
- Use
mcp_azure_mcp_get_azure_bestpracticesandmcp_azure_mcp_documentationMCP tools - Use the latest supported runtime for the target service
- Destructive actions require
ask_user— functions global-rules | app-service global-rules - Report progress to user — During long-running operations (deployments, image pushes), provide resource-level status updates so the user is never left waiting without feedback — see workflow-details.md
- Audit service discovery in app code — Kubernetes DNS names (e.g.,
http://order-service:3001) do not resolve in Container Apps. During assessment, scan source code for hardcoded hostnames/ports in HTTP clients and flag them for env-var-driven URL injection
Migration Scenarios
| Source | Target | Reference |
|---|---|---|
| AWS Lambda | Azure Functions | lambda-to-functions.md (assessment, code-migration) |
| AWS Elastic Beanstalk | Azure App Service | beanstalk-to-app-service.md |
| Heroku | Azure App Service | heroku-to-app-service.md |
| Google App Engine | Azure App Service | app-engine-to-app-service.md |
| AWS Fargate (ECS) | Azure Container Apps | fargate-to-container-apps.md (assessment, deployment) |
| Kubernetes (GKE/EKS/Self-hosted) | Azure Container Apps | k8s-to-container-apps.md |
| GCP Cloud Run | Azure Container Apps | cloudrun-to-container-apps.md |
| Spring Boot (Azure Spring Apps/VMs) | Azure Container Apps | spring-apps-to-aca.md |
No matching scenario? Use
mcp_azure_mcp_documentationandmcp_azure_mcp_get_azure_bestpracticestools.
Output Directory
All output goes to <workspace-root-basename>-azure/ at workspace root, where <workspace-root-basename> is the name of the top-level workspace directory itself (NOT a subdirectory within it). Never modify the source directory.
Steps
- Create
<workspace-root-basename>-azure/at workspace root - Assess — Analyze source, map services, generate report using the scenario-specific assessment guide → functions assessment | app-service assessment
- Migrate — Convert code/config using the scenario-specific migration guide → functions code-migration | app-service code-migration
- Ask User — "Migration complete. Test locally or deploy to Azure?"
- Hand off to azure-prepare for infrastructure, testing, and deployment
Track progress in migration-status.md — see workflow-details.md.
Output template
## Cloud migration result
**Status:** assessed | migrated | blocked
**Summary:** <one sentence covering scope and outcome>
### Details
Source platform, target Azure service, converted code, and remaining manual work.
### Validation
- <check performed>: <result and evidence>
Quality gate
- An assessment report was produced before any code conversion.
- Hardcoded service discovery hostnames were identified and replaced.
- The output follows
## Output templateexactly. - Every reported check was performed and its evidence is shown.
- Irreversible Azure actions were confirmed with the user first.