AutoGineer
Generated banner for Azure Cloud Migrate
Generated logo for Azure Cloud Migrate

Azure Cloud Migrate

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Cloud and DevOps
  • MIT
  • Low risk
Download ZIP

From the author

Assess and migrate cross-cloud workloads to Azure with reports and code conversion. Supports Lambda→Functions, Beanstalk/Heroku/App Engine→App Service, Fargate/Kubernetes/Cloud Run/Spring Boot→Container Apps. WHEN: migrate Lambda to Functions, AWS to Azure, migrate Beanstalk, migrate Heroku, migrate App Engine, Cloud Run migration, Fargate to ACA, ECS/Kubernetes/GKE/EKS to Container Apps, Spring Boot to Container Apps, cross-cloud migration.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Azure Cloud Migrate provides a structured, multi-phase workflow for transitioning applications from various cloud platforms to Azure. It focuses on assessing the current architecture, mapping services to Azure equivalents, and performing the necessary code and configuration conversions. The skill ensures a methodical approach by requiring an assessment report before any migration actions occur, and it provides specific guidance for common migration paths such as AWS Lambda to Azure Functions, Heroku to App Service, and Kubernetes to Container Apps.

What it does

  • Generates comprehensive migration assessment reports for cross-cloud workloads.
  • Maps source platform services, compute configurations, and dependencies to Azure equivalents.
  • Provides guidance for converting application code and configuration files.
  • Audits source code for platform-specific service discovery patterns.
  • Creates architecture diagrams for both current and target states.
  • Tracks migration progress and provides resource-level status updates.

When to use it

  • When planning to migrate workloads from AWS Lambda, Elastic Beanstalk, or Fargate to Azure.
  • When moving applications from Heroku or Google App Engine to Azure App Service.
  • When transitioning Kubernetes or Cloud Run deployments to Azure Container Apps.
  • When you need a structured assessment of migration readiness and effort.

Advantages

  • Ensures a consistent, step-by-step migration process.
  • Reduces risk by requiring a detailed assessment report before code changes.
  • Provides clear mapping between source platform features and Azure services.
  • Includes specific checks for common migration pitfalls like hardcoded service discovery.

Usage examples

“Assess my current AWS Lambda project for migration to Azure Functions.”
The agent will analyze the Lambda project, map the services to Azure Functions, and generate a migration assessment report in the output directory.
“Migrate my Heroku application to Azure App Service.”
The agent will perform an assessment, guide the conversion of configuration files, and assist in setting up the application for Azure App Service.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/azure-cloud-migrate/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip azure-cloud-migrate.zip -d .agents/skills

Documentation by Microsoft

Azure Cloud Migrate

This skill handles assessment and code migration of existing cloud workloads to Azure.

Rules

  1. Follow phases sequentially — do not skip

  2. Generate assessment before any code migration

  3. Load the scenario reference and follow its rules

  4. Use mcp_azure_mcp_get_azure_bestpractices and mcp_azure_mcp_documentation MCP tools

  5. Use the latest supported runtime for the target service

  6. Destructive actions require ask_user — functions global-rules | app-service global-rules

  7. 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

  8. 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

SourceTargetReference
AWS LambdaAzure Functionslambda-to-functions.md (assessment, code-migration)
AWS Elastic BeanstalkAzure App Servicebeanstalk-to-app-service.md
HerokuAzure App Serviceheroku-to-app-service.md
Google App EngineAzure App Serviceapp-engine-to-app-service.md
AWS Fargate (ECS)Azure Container Appsfargate-to-container-apps.md (assessment, deployment)
Kubernetes (GKE/EKS/Self-hosted)Azure Container Appsk8s-to-container-apps.md
GCP Cloud RunAzure Container Appscloudrun-to-container-apps.md
Spring Boot (Azure Spring Apps/VMs)Azure Container Appsspring-apps-to-aca.md

No matching scenario? Use mcp_azure_mcp_documentation and mcp_azure_mcp_get_azure_bestpractices tools.

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

  1. Create <workspace-root-basename>-azure/ at workspace root

  2. Assess — Analyze source, map services, generate report using the scenario-specific assessment guide → functions assessment | app-service assessment

  3. Migrate — Convert code/config using the scenario-specific migration guide → functions code-migration | app-service code-migration

  4. Ask User — "Migration complete. Test locally or deploy to Azure?"

  5. Hand off to azure-prepare for infrastructure, testing, and deployment

Track progress in migration-status.md — see workflow-details.md.

Files

references/services/container-apps/assessment-guide.md

Kubernetes to Azure Container Apps - Assessment Guide

Compatibility Matrix

Kubernetes → Container Apps Resource Mapping
Kubernetes ConceptContainer Apps EquivalentSupportedNotes
DeploymentContainer App✅ YesOne-to-one mapping for stateless workloads
Service (ClusterIP)Internal ingress✅ YesSet ingress.external: false
Service (LoadBalancer)External ingress✅ YesSet ingress.external: true
IngressBuilt-in ingress with custom domain✅ YesSupports TLS, traffic splitting
ConfigMapEnvironment variables✅ YesInline or from secrets
SecretSecrets (Key Vault refs preferred)✅ YesUse managed identity for Key Vault
CronJobContainer Apps Job (scheduled)✅ YesCron expression syntax
JobContainer Apps Job (manual/event)✅ YesOne-time or event-triggered
HPABuilt-in scaling rules✅ YesHTTP, TCP, KEDA-compatible scalers
PersistentVolumeClaimAzure Files mount⚠️ LimitedEmptyDir and Azure Files only; no block storage
DaemonSetN/A❌ NoConsider sidecar containers or external agents
StatefulSetN/A❌ NoUse external state (Cosmos DB, Redis, SQL)
Custom CRDs / OperatorsN/A❌ NoEvaluate if Dapr components can replace
NetworkPolicyVNet NSG rules⚠️ LimitedConfigure at Environment subnet level
Resource Limits
ResourceKubernetes (typical)Container Apps MaximumMigration Impact
CPU per containerUp to 64+ vCPU4 vCPUSplit large containers
Memory per containerUp to 256+ GiB8 GiBRedesign memory-intensive workloads
Replicas per app1000+300 per revisionValidate scale requirements
Request timeoutConfigurable (hours+)240 seconds defaultRedesign long-running requests
Startup probe timeoutConfigurable240 secondsOptimize startup time
Containers per pod/app10+Up to 10 sidecarsInit + sidecar containers supported

Unsupported Patterns

Critical Blockers

  1. StatefulSets with persistent storage

    • Why: Container Apps is designed for stateless workloads

    • Alternative: Migrate state to Azure Cosmos DB, Azure SQL, Redis, or Storage

  2. DaemonSets for node-level agents

    • Why: No node-level access in managed environment

    • Alternative: Use Azure Monitor agents, Dapr components, or sidecar containers

  3. Privileged containers or host networking

    • Why: Security isolation in managed platform

    • Alternative: Redesign to avoid host-level access

  4. Custom CRDs and Operators

    • Why: No Kubernetes API server access

    • Alternative: Use Dapr state management, bindings, or Azure PaaS services

  5. Direct Kubernetes API calls from apps

    • Why: Kubernetes API not exposed

    • Alternative: Use environment variables, service discovery via DNS, or Dapr

Storage Considerations

  • EmptyDir: Supported (ephemeral storage)

  • Azure Files: Supported via volume mounts

  • Persistent Block Storage: Not supported (migrate to Azure Blob, SQL, Cosmos DB)

Assessment Checklist

1. Workload Inventory

  • List all Deployments, StatefulSets, DaemonSets in target namespaces

  • Identify workload types: API, background worker, CronJob, StatefulSet

  • Document current resource requests/limits (CPU, memory)

  • Note replica counts (min, max, typical)

2. Network Configuration

  • Service Types: ClusterIP (internal) vs LoadBalancer (external)

  • Ingress: Document hostnames, TLS certificates, path routing rules

  • Service Mesh: Document if using Istio, Linkerd (consider migrating to Dapr)

  • NetworkPolicies: List egress/ingress rules (map to NSG rules or VNet integration)

3. Storage and State

  • PersistentVolumeClaims: List volumes, sizes, access modes (ReadWriteOnce, ReadWriteMany)

  • StatefulSets: Document state storage patterns (candidates for external state migration)

  • EmptyDir/Temp Storage: Note usage patterns (supported in Container Apps)

  • ConfigMaps/Secrets: Count and categorize (migrate inline or to Key Vault)

4. Scaling and Performance

  • HPA: Document scaling metrics (CPU, memory, custom metrics)

  • Min/Max Replicas: Verify within Container Apps limits (0-300)

  • Startup Time: Measure pod startup latency (must be <240s)

  • Request Patterns: Long-running requests (>240s) need redesign

5. Dependencies

  • Internal Services: List service-to-service calls (use internal DNS in Container Apps)

  • External Services: Databases, APIs, message queues, storage

  • Authentication: Service accounts, RBAC roles (map to managed identities)

  • Observability: Logging, metrics, tracing (migrate to Azure Monitor, App Insights)

6. CI/CD and Deployment

  • Pipeline Tools: kubectl, Helm, Kustomize, ArgoCD, Flux

  • Image Registries: Docker Hub, GCR, ECR, private registries (migrate to ACR)

  • Deployment Strategy: Rolling update, blue/green, canary (Container Apps supports traffic splitting)

Complexity Assessment Guidelines

Low Complexity

  • Stateless Deployments with ClusterIP or LoadBalancer Services

  • Simple environment variables (no complex ConfigMaps)

  • No persistent storage or external state already in use

  • Standard HTTP/gRPC ingress

  • No service mesh dependencies

Medium Complexity

  • Multiple Deployments with inter-service communication

  • ConfigMaps and Secrets requiring Key Vault migration

  • HPA with custom metrics (need KEDA scaler mapping)

  • CronJobs (map to Container Apps Jobs)

  • Ingress with TLS and custom domains

High Complexity

  • StatefulSets requiring state migration to external services

  • Service mesh (Istio/Linkerd) requiring Dapr migration

  • Custom CRDs or Operators (need redesign)

  • NetworkPolicies requiring VNet/NSG configuration

  • Large-scale deployments (>100 replicas, need architecture review)

  • Workloads exceeding Container Apps resource limits (>4 vCPU, >8 GiB)

Assessment Report Structure

Generate k8s-migration-assessment.md with:

  1. Executive Summary: Cluster name, namespace(s), workload count, complexity (Low/Medium/High), estimated timeline, Azure cost

  2. Current State: Deployment inventory, resource usage, scaling config, storage usage, networking topology

  3. Compatibility Analysis: Supported workloads, blockers, redesign requirements (StatefulSets, DaemonSets, CRDs)

  4. Azure Target: Required resources (resource group, Container Apps Environment, ACR, Key Vault, Log Analytics, VNet if needed)

  5. Migration Plan:

    • State migration strategy (databases, caches, storage)

    • Image migration approach (ACR import, rebuild)

    • IaC generation plan (Bicep templates per Deployment)

    • Deployment sequence (dependencies first, then consumers)

  6. Risk Assessment: Blockers, feature gaps, performance considerations, downtime estimate

  7. Validation Tests: Smoke tests, integration tests, performance benchmarks

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/azure-skills/skills/azure-cloud-migrate · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download azure-cloud-migrate.zip