Skip to content

Gap-9: Container Apps Migrate (F → A) — ECS/Fargate + Cloud Run migration guides #1634

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Paul Yuknewicz (paulyuk) wants to merge 3 commits into from
Closed

Gap-9: Container Apps Migrate (F → A) — ECS/Fargate + Cloud Run migration guides #1634

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
73e4600
feat(migrate): Container Apps migration — ECS/Fargate + Cloud Run (Ga…
paulyuk Apr 1, 2026
69c5593
fix(gap-9): address Container Apps migration feedback
Jul 4, 2026
f2e4d3a
Merge remote-tracking branch 'origin/main' into pass-equity-gap-9
Jul 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 17 additions & 16 deletions plugin/skills/azure-cloud-migrate/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: azure-cloud-migrate
description: "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."
description: "Assess and migrate cross-cloud AWS/GCP workloads to Azure with reports and code conversion. Supports Lambda→Functions, Beanstalk/Heroku/App Engine→App Service, ECS/Fargate/Kubernetes/Cloud Run/Spring Boot→Container Apps. WHEN: migrate Lambda to Azure Functions, AWS to Azure, migrate Beanstalk, migrate Heroku, migrate App Engine, Cloud Run migration, Fargate or ECS to ACA, ECS/Kubernetes/GKE/EKS to Container Apps, Spring Boot to Container Apps, migration readiness report, cross-cloud migration."
license: MIT
metadata:
author: Microsoft
Expand All @@ -9,18 +9,16 @@ metadata:

# 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](references/services/functions/global-rules.md) | [app-service global-rules](references/services/app-service/global-rules.md)
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](references/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
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](references/services/functions/global-rules.md) | [app-service global-rules](references/services/app-service/global-rules.md) | [container-apps global-rules](references/services/container-apps/global-rules.md).
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](references/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

Expand All @@ -30,9 +28,10 @@ metadata:
| AWS Elastic Beanstalk | Azure App Service | [beanstalk-to-app-service.md](references/services/app-service/beanstalk-to-app-service.md) |
| Heroku | Azure App Service | [heroku-to-app-service.md](references/services/app-service/heroku-to-app-service.md) |
| Google App Engine | Azure App Service | [app-engine-to-app-service.md](references/services/app-service/app-engine-to-app-service.md) |
| AWS ECS/Fargate | Azure Container Apps | [ecs-to-container-apps.md](references/services/container-apps/ecs-to-container-apps.md) |

@jongio Jon Gallant (jongio) Jul 4, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This row overlaps with the existing AWS Fargate (ECS) row on line 32. When a user says "migrate my Fargate service," both rows match, pointing to different files (ecs-to-container-apps.md vs fargate-to-container-apps.md with its companion assessment/deployment guides).

Consider either:

  • Consolidating into one row that links to ecs-to-container-apps.md as the primary reference (since it covers both ECS and Fargate), and removing or demoting the old Fargate-specific row to a sub-link.
  • Adding a disambiguation note so the LLM knows ecs-to-container-apps.md is the comprehensive guide while fargate-to-container-apps.md is Fargate-only.

| AWS Fargate (ECS) | Azure Container Apps | [fargate-to-container-apps.md](references/services/container-apps/fargate-to-container-apps.md) ([assessment](references/services/container-apps/fargate-assessment-guide.md), [deployment](references/services/container-apps/fargate-deployment-guide.md)) |
| Kubernetes (GKE/EKS/Self-hosted) | Azure Container Apps | [k8s-to-container-apps.md](references/services/container-apps/k8s-to-container-apps.md) |
| GCP Cloud Run | Azure Container Apps | [cloudrun-to-container-apps.md](references/services/container-apps/cloudrun-to-container-apps.md) |
| GCP Cloud Run | Azure Container Apps | [cloud-run-to-container-apps.md](references/services/container-apps/cloud-run-to-container-apps.md) and [cloudrun-to-container-apps.md](references/services/container-apps/cloudrun-to-container-apps.md) |

@jongio Jon Gallant (jongio) Jul 4, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listing two files with and in a single table cell doesn't give the LLM a clear signal about which to load. It'll likely try to load both, which is redundant if the new cloud-run-to-container-apps.md supersedes the old cloudrun-to-container-apps.md.

If the new file is the comprehensive replacement, point this row to it alone. The existing cloudrun-to-container-apps.md (plus its companion cloudrun-assessment-guide.md and cloudrun-deployment-guide.md) can be referenced as supplementary material or deprecated.

| Spring Boot (Azure Spring Apps/VMs) | Azure Container Apps | [spring-apps-to-aca.md](references/services/container-apps/spring-apps-to-aca.md) |

> No matching scenario? Use `mcp_azure_mcp_documentation` and `mcp_azure_mcp_get_azure_bestpractices` tools.
Expand All @@ -43,10 +42,12 @@ All output goes to `<workspace-root-basename>-azure/` at workspace root, where `

## 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](references/services/functions/assessment.md) | [app-service assessment](references/services/app-service/assessment.md)
3. **Migrate** — Convert code/config using the scenario-specific migration guide → [functions code-migration](references/services/functions/code-migration.md) | [app-service code-migration](references/services/app-service/code-migration.md)
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](references/services/functions/assessment.md) | [app-service assessment](references/services/app-service/assessment.md) | [container-apps assessment](references/services/container-apps/assessment.md).
3. **Migrate** — Convert code/config using the scenario-specific migration guide → [functions code-migration](references/services/functions/code-migration.md) | [app-service code-migration](references/services/app-service/code-migration.md) | [container-apps code-migration](references/services/container-apps/code-migration.md).
4. **Ask User** — "Migration complete. Test locally or deploy to Azure?"
5. **Hand off** to azure-prepare for infrastructure, testing, and deployment
5. **Hand off** to azure-prepare for infrastructure, testing, and deployment.

Track progress in `migration-status.md` — see [workflow-details.md](references/workflow-details.md).

Container Apps migrations must also load [global-rules.md](references/services/container-apps/global-rules.md), assess with [assessment.md](references/services/container-apps/assessment.md), then migrate with [code-migration.md](references/services/container-apps/code-migration.md).
153 changes: 153 additions & 0 deletions plugin/skills/azure-cloud-migrate/references/services/container-apps/assessment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,153 @@
# Assessment Phase — Container Apps

Generate a migration assessment report before any code or configuration changes.

## Prerequisites

- Workspace contains Dockerfiles, docker-compose files, ECS task definitions, Cloud Run service YAML, or equivalent container specs
- Prompt user to upload relevant files if not present

## Assessment Steps

1. **Identify Containers** — List all container services with images, ports, and resource limits
2. **Analyze Dockerfiles** — Check base images, build stages, exposed ports, entrypoints
3. **Map Cloud Services** — Map source services to Azure equivalents (see scenario references)
4. **Map Networking** — Map load balancers, service discovery, and ingress to Container Apps ingress
5. **Check Dependencies** — List external services (databases, caches, queues) and verify Azure equivalents
6. **Map Secrets** — Identify secrets/env vars and plan Key Vault migration
7. **Map Volumes** — Identify persistent storage needs and map to Azure Files or ephemeral storage
8. **Analyze Multi-Container** — Identify sidecar patterns, init containers, and service mesh usage
9. **Map IAM** — Map task/service roles to Managed Identity + RBAC
10. **Map Monitoring** — Map logging/metrics to Application Insights + Log Analytics
11. **Review CI/CD** — Check pipeline compatibility with Azure DevOps or GitHub Actions

## Image Analysis

For each container image:

| Check | Details |
|-------|---------|
| **Base image** | OS, runtime, version — verify Azure compatibility |
| **Multi-stage build** | Identify build vs runtime stages |
| **Exposed ports** | Map to Container Apps ingress (HTTP/TCP) |
| **ENTRYPOINT/CMD** | Verify compatibility with Container Apps |
| **HEALTHCHECK** | Map to Container Apps health probes |
| **Volume mounts** | Map to Azure Files or ephemeral storage |
| **Build args / ENV** | Map to Container Apps env vars and secrets |
| **Image size** | Flag images > 1GB for optimization |

## Architecture Diagrams

Generate two diagrams:
1. **Current State** — Source architecture with containers, networking, and integrations
2. **Target State** — Azure Container Apps architecture showing equivalent structure

## Assessment Report Format

> ⚠️ **MANDATORY**: Use these exact section headings in every assessment report. Do NOT rename, reorder, or omit sections.

The report MUST be saved as `migration-assessment-report.md` inside the output directory (`<source-folder>-azure/`).

```markdown
# Migration Assessment Report

## 1. Executive Summary

| Property | Value |
|----------|-------|
| **Total Services** | <count> |
Comment thread
paulyuk marked this conversation as resolved.
| **Source Platform** | <AWS ECS / GCP Cloud Run> |
| **Container Runtime** | <Docker / containerd> |
| **Target Platform** | Azure Container Apps |
| **Target Environment** | Consumption / Dedicated |
| **Migration Readiness** | <High / Medium / Low> |
| **Estimated Effort** | <Low / Medium / High> |
| **Assessment Date** | <date> |

## 2. Container Inventory

| # | Service Name | Image | Port | CPU | Memory | Replicas | Description |
|---|-------------|-------|------|-----|--------|----------|-------------|
| 1 | | | | | | | |

## 3. Service Mapping

| Source Service | Azure Equivalent | Migration Complexity | Notes |
|----------------|------------------|----------------------|-------|
| | | | |

## 4. Networking & Ingress Mapping

| # | Service Name | Source LB/Ingress | Azure Ingress | Protocol | External? | Notes |
|---|-------------|-------------------|---------------|----------|-----------|-------|
| 1 | | | | | | |

## 5. Environment Variables & Secrets

| # | Variable Name | Source | Purpose | Azure Equivalent | Auth Method | Notes |
|---|--------------|--------|---------|------------------|-------------|-------|
| 1 | | | | | Managed Identity / Key Vault | |

## 6. Volume & Storage Mapping

| # | Service | Source Mount | Type | Azure Equivalent | Notes |
|---|---------|------------|------|------------------|-------|
| 1 | | | | Azure Files / Ephemeral | |

## 7. IAM & Security Mapping

| Source Role/Policy | Azure RBAC Role | Scope | Notes |
|--------------------|-----------------|-------|-------|
| | | | |

## 8. Monitoring & Observability Mapping

| Source Service | Azure Equivalent | Migration Notes |
|----------------|------------------|-----------------|
| | | |

## 9. Scaling & Performance

| # | Service | Source Scaling | Azure Scale Rule | Min | Max | Notes |
|---|---------|---------------|------------------|-----|-----|-------|
| 1 | | | HTTP / Queue / Custom | | | |

## 10. Multi-Container Patterns

| # | Service | Pattern | Containers | Azure Approach | Notes |
|---|---------|---------|------------|----------------|-------|
| 1 | | Sidecar / Init | | Container Apps sidecar | |

## 11. Architecture Diagrams

### 11a. Current State (Source)

<!-- Mermaid or ASCII diagram -->

### 11b. Target State (Azure)

<!-- Mermaid or ASCII diagram -->

## 12. CI/CD & Deployment Mapping

| Source Tool | Azure Equivalent | Notes |
|-------------|------------------|-------|
| | | |

## 13. Recommendations

1. **Environment**: <Consumption / Dedicated workload profile>
2. **Registry**: <ACR Basic / Standard / Premium>
3. **IaC Strategy**: <Bicep with azd / Terraform>
4. **Auth Strategy**: <Managed Identity for all service-to-service>
5. **Monitoring**: <Application Insights + Log Analytics>
6. **Networking**: <External / VNet-integrated>

## 14. Next Steps

- [ ] Review and approve this assessment report
- [ ] Proceed to code migration (Phase 2)
- [ ] Hand off to azure-prepare for IaC generation
```

> 💡 **Tip:** Use `mcp_azure_mcp_get_bestpractices` tool to learn Container Apps best practices for the recommendations section.
Loading
Loading