Azure to AWS with AWS Transform: what the .NET code conversion automates (and what it doesn't)

Azure to AWS with AWS Transform: what the .NET code conversion automates (and what it doesn’t)

If you run .NET on Azure and have been weighing a move to AWS, the October 2026 announcement is worth understanding precisely - because the easy mistake is to read “Azure-to-AWS code conversion” as “Azure-to-AWS migration.” It is not the same thing, and knowing the difference is what keeps a re-platform on schedule.

What AWS Transform actually converts

AWS Transform reached general availability for application code conversion from the Azure SDK to the AWS SDK, aimed at Microsoft Azure cloud-native .NET applications. The AWS Transform .NET modernization agent identifies Azure service code in your source and converts it to the equivalent AWS service code.

The flow is discover → assess → plan → convert → validate: AWS Transform discovers the Azure SDK in your submitted source, presents the conversion options in an assessment report and modernization plan, lets you accept or adjust them before running, then converts the identified calls to AWS SDK equivalents and validates that the changes are incorporated into the transformed code.

As an example AWS gives: an Azure Functions serverless function that uses Azure Cosmos DB can be converted to an AWS Lambda function that uses Amazon DynamoDB. (Available in eight AWS Regions as of October 2026, including N. Virginia, Frankfurt, and London - check the AWS announcement for the current list.)

What it genuinely saves you

Credit where it is due - this removes real, tedious work:

• No hand-rewriting SDK calls across the codebase. Finding every Azure SDK call and swapping it for the AWS equivalent, consistently, is exactly the kind of repetitive change that is slow and error-prone by hand and well-suited to automation.
• The assessment surfaces what is convertible before you commit, so you are not discovering surprises mid-refactor.
• You review and adjust the plan rather than accepting a black-box rewrite - you keep control of what changes.

For a team with a large .NET estate on Azure, that is days or weeks of mechanical refactoring taken off the table. It is a legitimate accelerator.

What it does not do

This is the part that matters for planning. AWS Transform converts SDK calls. A migration is much more than SDK calls.

Two caveats worth calling out directly:

• Data is not code. Converting a Cosmos DB SDK call to a DynamoDB SDK call does not move your data, and Cosmos and DynamoDB have very different data models. The SDK conversion is the easy part; redesigning the data model and migrating the data is the hard part - and the Cosmos-to-DynamoDB conversion is still in preview.
• Validation is not testing. AWS Transform validates that the converted changes are incorporated into the code. That is not the same as proving your application still does the right thing in production - that is your test strategy, and it does not go away.

Where it fits in a real Azure-to-AWS migration

Think of AWS Transform as an accelerator inside the re-platform step, not a replacement for the migration. In the phased approach we lay out in our cloud migration costs and process guide, the sequence is roughly: assess → design the AWS target (landing zone, networking, IAM) → re-platform/refactor → migrate data → test → cut over. AWS Transform lives in the re-platform/refactor step, and it makes that step faster. It does not remove the steps on either side of it - the design decisions before, and the data migration and testing after.

That framing also sets realistic expectations on cost and timeline. The code conversion getting cheaper does not make the data migration, testing, or landing-zone work cheaper - so budget the whole move, not just the slice a tool automates. Our AWS migration cost breakdown covers where the real spend sits.

When to bring in a partner

• The what-to-move decision. Not everything should be re-platformed as-is; some things are better rebuilt, consolidated, or retired. That triage is where a migration succeeds or drifts.
• The data-model redesign. Cosmos DB to DynamoDB (or any datastore change) is an architecture problem, not an SDK problem. Getting the access patterns and key design right up front avoids an expensive re-do.
• Landing zone, networking, and IAM on AWS. The target environment needs to be designed and secured before workloads land in it.
• Test strategy and cutover. Proving behaviour and planning a safe cutover is the difference between a migration and an outage.
• Funding. Azure-to-AWS moves can qualify for AWS Migration Acceleration Program (MAP) funding. We cover how partner-led migration and funding work in how to choose an AWS migration partner.

FAQ

Does AWS Transform migrate my whole Azure app to AWS? No. AWS Transform converts Azure SDK code to AWS SDK code in .NET applications. It does not migrate your data, design your AWS architecture, or test your application. It automates one slice (the SDK-call rewrite) of a larger migration.

What does AWS Transform convert? For .NET apps, it converts Azure Functions to AWS Lambda, Azure Blob Storage to Amazon S3, and Azure Queue Storage to Amazon SQS, with Azure Cosmos DB to Amazon DynamoDB available in preview. It discovers the Azure SDK in your source, proposes conversions in an assessment report, and converts them after you review the plan.

Does it migrate my data too? No. Data migration is a separate job. A Blob-to-S3 data copy and especially a Cosmos-to-DynamoDB move (different data models) have to be planned and executed on their own - the SDK conversion only changes the code that talks to the data.

Is the Azure Cosmos DB to DynamoDB conversion production-ready? It is in preview as of October 2026. Treat it as something to evaluate, and remember that the harder part is the data-model redesign, not the SDK call - Cosmos and DynamoDB model data very differently.

What is supported - any language or workload? It targets Microsoft Azure cloud-native .NET applications using the Azure SDK. It is SDK-call conversion, so code that does not use the Azure SDK, and non-.NET workloads, are out of scope.

How much of an Azure-to-AWS migration does this actually cover? The SDK-call layer. Architecture and landing-zone design, data migration, IAM and networking, end-to-end testing, and the decision of what to move all remain - which is most of the effort and most of the risk.

Summary

1. AWS Transform converts Azure SDK code to AWS SDK code for .NET apps - Functions to Lambda, Blob to S3, Queue to SQS, and Cosmos to DynamoDB in preview. It is a genuine accelerator that removes mechanical refactoring.
2. It converts code, not migrations. Data migration, architecture, landing zone, IAM, and testing are still yours - and the Cosmos-to-DynamoDB data-model rethink is the hard part a tool cannot do for you.
3. Slot it into the re-platform step, and budget the whole move. The code conversion getting cheaper does not make the rest cheaper.

If you are planning an Azure-to-AWS migration and want to know what is genuinely automatable versus what needs a plan, explore our cloud migration guide or talk to us directly.

Moving .NET workloads from Azure to AWS?

Book a free 30-minute call. We help teams scope what to move, design the AWS target, plan the data migration and testing AWS Transform does not cover, and check whether the move qualifies for MAP funding.

Book a call Send us a message