On 16 October 2026, AWS made Azure-to-AWS cloud-native code conversion generally available in AWS Transform. The .NET modernization agent now finds Azure SDK calls in your source code and rewrites them to use the equivalent AWS services. In AWS’s own example, an Azure Functions app that uses Azure Cosmos DB becomes an AWS Lambda function that uses Amazon DynamoDB (AWS What’s New, 16 Oct 2026). For any team planning an Azure to AWS migration, this goes after one of the hardest parts of leaving a cloud: application code written against another provider’s SDKs. Here is what it does, where it stops, what it costs, and how to run a first project.
Why Code Is the Hard Part of an Azure to AWS Migration
Moving virtual machines between clouds is a well-understood problem. Cloud-native applications are harder. Once your code calls Blob Storage, Queue Storage, Cosmos DB, or the Azure Functions programming model directly, every one of those calls has to be found, rewritten, and retested before the app can run on AWS. As WebProNews put it in its coverage of the launch, virtual machines move with relative ease, but application logic written against one vendor’s storage, queuing, or compute abstractions does not (WebProNews, 17 Oct 2026). Until now, that rewrite was largely manual.
What AWS Transform’s Azure-to-AWS Conversion Does
AWS Transform is AWS’s agentic AI service for migration and modernization. It covers infrastructure migration from VMware, bare metal, and hybrid environments, as well as Windows, mainframe, and custom code modernization (AWS Transform). The new capability lives inside AWS Transform for .NET. According to the user guide, it can convert the following Azure services:
- Azure Functions to AWS Lambda: functions are rewritten as Lambda functions.
- Azure Blob Storage to Amazon S3: Azure.Storage.Blobs SDK code becomes Amazon.S3 SDK code.
- Azure Queue Storage to Amazon SQS: Azure.Storage.Queues code becomes Amazon.SQS code.
- Azure Cosmos DB to Amazon DynamoDB (preview): Microsoft.Azure.Cosmos code becomes Amazon.DynamoDBv2 code.
Conversion runs automatically for eligible modern .NET applications. Code that has no AWS equivalent is flagged in TODO comments, stubbed code, or a generated Next Steps file. AWS is clear that the feature converts application code only and does not migrate cloud infrastructure (AWS Transform User Guide: Convert cloud-native code).
How It Works
The conversion runs inside a normal AWS Transform for .NET job, with human review at each stage.
1. Connect your source code
You can connect through AWS CodeConnections (GitHub, GitLab, Bitbucket, or Azure DevOps), use a personal access token stored in AWS Secrets Manager, point to a zip archive in Amazon S3, or upload a zip directly. Creating a connector requires approval by an AWS administrator, and transformed code is written to a new branch (Connect to source code). Azure DevOps support helps Azure-first teams that keep code in Azure Repos.
2. Review the assessment and plan
AWS Transform detects the Azure SDK in your code and shows the conversion options in the assessment report and modernization plan. You can accept them or change them before anything runs (AWS What’s New). Through agent chat, the plan, or a steering document, you can opt out of some conversions, set naming conventions, adjust comments, or redirect targets. AWS’s example is sending Blob Storage code to DynamoDB instead of S3.
3. Transform and validate
Repositories are transformed in parallel batches. In interactive mode, you can set checkpoints that pause after each repository so you can review the code, ask the agent to explain its changes, or request a retry (Transform your .NET code). At the end, you get the original and transformed code, an HTML transformation report, and a NextSteps.md file to hand to an AI code companion such as Kiro (Final summary).
What It Supports, and Where It Stops
The .NET agent works with C# and VB.NET. It transforms from .NET Framework 3.5, .NET Core 3.1, and .NET 5.x through .NET 10, and its targets are .NET 8, .NET 10, and .NET Standard. Supported project types include ASP.NET (MVC, Web API, Web Forms), console apps, class libraries, WCF services, and unit test projects. It does not handle Win32 DLLs without core-compatible libraries, repositories with no .NET solution, or web site projects that lack a project file (Modernizing .NET with AWS Transform).
Key limits:
- Only the listed services are converted. For other Azure services, AWS points you to AWS Transform custom or an AI code companion.
- Cosmos DB to DynamoDB is still in preview. It needs the most careful review.
- Infrastructure is out of scope. Networking, identity, IaC, and data migration still need their own workstream.
- Regions. AWS Transform is available in US East (N. Virginia), Asia Pacific (Mumbai, Tokyo, Seoul, Sydney), Canada (Central), and Europe (Frankfurt, London). Mumbai helps Indian teams with data-residency needs.
Pricing
AWS lists assessment and the Windows modernization agent as free. AWS-managed .NET transformations include up to 50,000 agent minutes per month at no additional charge, and unused minutes don’t carry over. Custom transformations are billed at $0.035 per agent minute. AWS also says that any resources you create from Transform’s output are billed at their standard prices (AWS Transform pricing). The real costs are the AWS resources you run afterwards and the engineering time spent on validation.
A Practical Five-Step Plan for Your First Project
- Inventory your Azure dependencies. List each app’s Azure services and sort them into “converted by Transform” (Functions, Blob, Queue, Cosmos DB) and “manual” (everything else).
- Pick one representative pilot. AWS recommends transforming a few applications first to set a baseline before you estimate a larger programme (AWS Transform FAQs).
- Prepare the landing zone in parallel. Build accounts, networking, IAM, and IaC for the target services while the code is being converted.
- Have a validation plan. AWS’s best practices say to decide up front how you’ll confirm behaviour, security controls, business logic, and data storage after transformation. If your solution has unit tests, Transform ports and runs them (Before you transform).
- Finish with a code companion and a cutover plan. Work through NextSteps.md, fix runtime issues, migrate data, and plan rollback before you switch traffic.
If you’re weighing this against a broader programme, the AWS Migration Acceleration Program (MAP) provides an Assess, Mobilize, and Migrate & Modernize framework, and it can help offset initial migration costs.
Frequently Asked Questions
Does AWS Transform migrate my Azure infrastructure too?
No. The Azure-to-AWS feature converts application code only. Your VNets, identities, databases, and deployment pipelines still need to be designed and migrated separately.
Is the converted code production-ready?
Treat it as a strong starting point, not a finished release. AWS says changes are reviewed through the plan and checkpoints, and it recommends validating functionality and UI and fixing failing tests before you go to production (Validation and finalization).
Can I work in Visual Studio instead of the web console?
Yes. AWS Transform is available in the AWS Toolkit for Visual Studio with interactive and autonomous modes. The IDE experience uses IAM Identity Center for authentication (Modernizing .NET in the IDE).
What if my app is not .NET?
This conversion is specific to .NET. For other languages or architectural changes, AWS suggests AWS Transform custom or an AI code companion.
Plan Your Azure to AWS Migration with Shanav
Shanav is an AWS Advanced Tier Partner with offices in Jaipur and the UAE. We help teams assess Azure workloads, run AWS Transform pilots, build secure landing zones, and cut over with confidence. Explore our cloud migration and modernization services and hybrid and multi-cloud solutions, or talk to our AWS experts about your Azure to AWS migration roadmap.