AWS Transform now converts Azure code to AWS SDK, from Functions to Cosmos DB
On October 16, 2026, AWS made Azure SDK to AWS SDK code conversion generally available in AWS Transform: Azure Functions becomes Lambda, Blob Storage becomes S3, and Cosmos DB becomes DynamoDB in preview. For a .NET team weighing an exit from Azure, it is a serious starting point — not a one-click migration.
October 16, 2026. AWS announces general availability of application code conversion from Azure SDK to AWS SDK in AWS Transform. Four services. Azure Functions becomes AWS Lambda, Blob Storage becomes Amazon S3, Queue Storage becomes Amazon SQS, and Cosmos DB becomes DynamoDB in preview. Eight regions. From Northern Virginia to Sydney, via Frankfurt and London. Why it matters: for the first time, the migration war between the two big clouds drops to the source-code layer — and it changes what “leaving Azure” means for a .NET team.
Migration drops to the code layer
Until now, cloud migration tools mostly operated at the infrastructure layer — rehosting virtual machines, reconfiguring networks, replicating storage. AWS Transform adds a deeper layer: the .NET modernization agent reads the submitted source code, spots calls into the Azure SDK, and converts them into equivalent AWS SDK calls. AWS’s example is concrete: a serverless Azure Functions function that uses Cosmos DB becomes an AWS Lambda function that uses DynamoDB.
The flow is built to stay under human control. AWS Transform discovers the Azure SDK in the code, then presents conversion options in an assessment report and a modernization plan. The team can accept those options or adjust them before running the modernization. Once conversion starts, the tool transforms the identified code and validates that the changes are incorporated into the result. It is decision support before it is a blind transformer.
The target is explicit and limited to cloud-native .NET applications — not the whole Azure catalog, not legacy IaaS workloads. The scope is the modern managed services where the rewrite effort was, until now, the most manual and expensive.
What converts, and what does not yet
The functional scope comes down to four mappings, all in the Azure → AWS direction: Azure Functions → AWS Lambda, Azure Blob Storage → Amazon S3, Azure Queue Storage → Amazon SQS, and Azure Cosmos DB → Amazon DynamoDB in preview. The first three are generally available; the last is still in preview — a prudent choice, since it is by far the riskiest.
The caution around Cosmos DB → DynamoDB is justified. Both are managed NoSQL stores, but their consistency models, billing models and operational limits differ deeply. Cosmos DB offers configurable consistency levels and a request-unit (RU) model; DynamoDB enforces strong or eventual consistency per read and bills in capacity units. Converting SDK calls converts neither the data schema nor the capacity choices. That is exactly the part the tool leaves — rightly — to the team’s judgment.
Regional availability is deliberately broad but not universal: US East (N. Virginia), Asia Pacific (Mumbai, Tokyo, Seoul, Sydney), Canada (Central) and Europe (Frankfurt, London). A team whose data must stay in an uncovered region will have to wait, or run the assessment from an allowed region and deploy elsewhere.
Assessment first, not an automatic lift
The announcement’s strategic weight goes beyond the tool itself. By automating Azure → AWS code conversion, AWS lowers the entry cost of a migration assessment — the most expensive moment of a cloud exit, when a team must estimate the rewrite effort before even knowing whether the move is worth it. The same motion is visible in the ecosystem in the opposite direction: multi-cloud migration is becoming a tooling market, not just a professional-services market.
The risk not to underestimate is overconfidence in the output. An SDK converter produces syntactically correct, semantically “equivalent” code, but it does not know production behavior: SQS’s different latency versus Queue Storage, DynamoDB’s throughput limits, Lambda’s cold-start model. AWS Transform’s automated validation confirms the changes are incorporated, not that they behave identically under load. Human review and load testing remain the real work. The realistic outcome is not a finished migration but a defensible estimate: the assessment tells you whether the rewrite is a weekend, a quarter, or a non-starter — before you commit a single engineer to it.
The tactical reading is simple. For a .NET team already running Azure Functions and looking for an exit — contract, cost, multi-cloud strategy or repatriation — AWS Transform turns the first step of a multi-week project into a day of assessment. For a team with no intention of migrating, the announcement is still a signal: AWS is investing in capturing Azure’s .NET workloads, and this kind of tool eventually weighs on contract negotiations.
The migration-tooling arms race
The announcement is part of a longer sequence. AWS Transform already exists for other targets — mainframe modernization and COBOL or Visual Basic code conversion into managed AWS services. Adding Azure SDK → AWS SDK conversion extends that catalog to the most common use case: a company already committed to Microsoft that wants to price an exit without hiring a consultancy.
The motion is symmetric and competitive. Microsoft pushes Azure Migrate the other way, and both hyperscalers fund switches with credit and service programs. What distinguishes AWS’s tool is that it drops below the virtual-machine layer: it touches application code, the most expensive part to rewrite and the hardest to estimate. An automatic assessment report therefore produces value neither rehost nor replatform provides — a quantified estimate of the rewrite effort, before any budget decision.
One limit is admitted: the tool converts SDK calls, not architectures. An application built around Azure-specific properties — Durable Functions, Event Grid, Cosmos DB’s consistency grid — will still need a redesign the conversion does not cover. The tool lowers the cost of the “how much” question, not the “how” answer.
Verdict
If you are weighing an exit from Azure for cloud-native .NET applications, run AWS Transform over your code before any manual estimate: the assessment report sizes the conversion — and therefore the project’s real cost — at near-zero price. Accept or adjust the options, then treat the converted code as a high-quality draft, not a deliverable.
If your scope includes Cosmos DB, treat the DynamoDB conversion with particular care: it is in preview, and the real difficulty is not the SDK call but the data model and capacity choices. Revalidate the schema, the consistency model and the sizing before any cutover. If your data must stay in an uncovered region, plan the assessment from an allowed region and the deployment separately.
The conclusion fits in one sentence: the tool lowers the cost of the decision, not of the migration — the engineering work that remains is precisely what no converter can do for you.