AWS's agent now rewrites Azure .NET code for AWS. Swapping the SDK calls is the easy part of a cloud move

Point an agent at a .NET application that reads from Azure Blob Storage, processes Azure Queue Storage messages in Azure Functions and writes to Cosmos DB. Ask it to make the application run on AWS. The agent finds every Azure SDK call, proposes an AWS equivalent, waits for your approval and rewrites the code. The application compiles. Does it behave the same?

That is now a real question rather than a thought experiment. On October 16 AWS made Azure SDK to AWS SDK code conversion generally available in AWS Transform, its .NET modernization agent. The agent analyzes a cloud-native .NET application and finds supported Azure dependencies. It presents conversion options in an assessment report and modernization plan, which the user accepts or adjusts. Then it converts the code and checks that the changes were incorporated.

Three conversions are generally available: Azure Functions to AWS Lambda, Azure Blob Storage to Amazon S3 and Azure Queue Storage to Amazon SQS. Cosmos DB to DynamoDB is in preview. The feature runs in eight AWS Regions: US East (N. Virginia), Canada (Central), Frankfurt, London, Mumbai, Tokyo, Seoul and Sydney.

Two clouds, one direction of travel

Earlier this month Google put an agent behind moving Kubernetes workloads from EKS to GKE. Now AWS has one pointed the other way, at Azure. Hyperscalers are building migration agents aimed at each other’s customers, which makes cloud exit plans cheaper to test and gives buyers a credible alternative at renewal time. The catch is the same in both directions: an agent converts what it can see in the code, and much of what makes an application behave the way it does is not in the SDK calls.

What lives outside the SDK calls

Identity. An Azure application typically reaches storage and queues through Microsoft Entra ID and managed identities with role assignments. On AWS the same access is IAM roles and policies. Converting BlobClient calls to S3 calls does not design the IAM policy that should restrict them, and the convenient fix, broad permissions so the tests pass, is how migrations create the over-privileged workloads that later become incidents.

Triggers and failure handling. An Azure Function with a queue trigger and an AWS Lambda reading SQS both process messages, but retries, poison messages, visibility and batching work differently. Azure Queue Storage functions move a message to a poison queue after a set number of dequeues; SQS relies on a visibility timeout and a dead-letter queue redrive policy that someone has to configure. A conversion that preserves the happy path can change what happens to the thousandth message that fails, which is when businesses discover their process was idempotent only by accident.

Data model. Cosmos DB to DynamoDB is in preview for a reason. Moving between document databases with different query models, partitioning, indexing and consistency options is a data design decision, not a syntax change. Treat a converted data layer as a proposal for an architect, not a finished change.

Network and configuration. Private endpoints, virtual networks, configuration stores and secrets have AWS equivalents, but they are infrastructure, usually defined outside the application code that the agent rewrites.

Operations. Logging, metrics, tracing and alerts move from Azure Monitor and Application Insights to AWS tooling. Dashboards and on-call runbooks do not migrate themselves, and the first incident on the new platform is not the time to find out.

How to verify a converted application

The approval gate on the modernization plan is the right design: the agent proposes and a person decides. But approving a plan is not verifying a result. For an application that matters, the evidence should come from behavior:

• Contract tests at every converted boundary, including failure cases: missing objects, oversized messages, throttling, duplicate delivery.
• Replay of real traffic against old and new deployments with outputs compared, the approach that made Google’s Dual Run credible for mainframes.
• An IAM review written by a person, not inferred from what the tests needed.
• A rollback path while both deployments run in parallel.

Agents like this one take the slow, repetitive part of a migration, finding and rewriting hundreds of SDK calls, off engineers’ hands, the pattern we described for migration agents working inside playbooks. They do not remove the part that requires knowing what the application is supposed to do when things go wrong. That part was always the expensive one, and it still is.