AWS Transform eases Azure .NET migration

AWS Transform announces Azure-to-AWS cloud-native code conversion

Editorial position: This feature removes a manual, error-prone step from Azure-to-AWS .NET migrations, but engineers must still validate behavior and performance after conversion.

The news, in plain English

AWS has made generally available a feature in AWS Transform that converts application code that uses Microsoft Azure SDKs to use AWS SDKs instead. The target is .NET applications that run on Microsoft Azure and that teams want to move to AWS.

Technical context

AWS Transform is a set of tools that help teams modernize applications for the cloud. This new feature focuses on rewriting code that calls Azure services so that it calls comparable AWS services instead. The current supported mappings include:

• Azure Functions → AWS Lambda
• Azure Cosmos DB → Amazon DynamoDB
• Azure Blob Storage → Amazon S3
• Azure Queue Storage → Amazon SQS

The service uses a .NET modernization agent that you run against your code. The agent identifies calls to the Azure SDK and suggests or applies replacements that use the AWS SDK. The agent works at the source-code level, not as a runtime shim, which means the resulting code calls AWS APIs directly.

In practice: The agent does not change your application logic; it only changes the cloud-service calls. You still need to test the rewritten code, because API differences can affect behavior.

Where this fits in practice

This feature is useful if you have a substantial .NET code base that runs on Azure and you want to move it to AWS. It can reduce the amount of manual rewriting that teams otherwise have to do. The conversion is not a one-click solution: you still need to

• Run the agent against your code
• Review and confirm each suggested change
• Run tests against the rewritten code on AWS
• Deploy to AWS and monitor performance and cost

The service does not yet support every Azure service or every pattern of usage. If your code uses Azure features that do not have an AWS equivalent, you will still need to rewrite those parts manually.

Adoption path

To start using AWS Transform for Azure-to-AWS code conversion, you need to

1. Install the .NET modernization agent on your development machine or in a CI/CD pipeline.
2. Run the agent against the source code of your Azure-based .NET application.
3. Review the conversion report that the agent produces. This report shows which Azure SDK calls were found and what AWS SDK calls they were mapped to.
4. Apply the suggested changes, either automatically (where the agent supports it) or manually.
5. Test the rewritten application thoroughly on AWS, paying attention to performance, scalability, and cost.
6. Deploy the application to AWS and monitor it in production.

Watch out: The agent does not handle custom logic or complex orchestration that is specific to Azure. You must evaluate whether the AWS services that the agent maps to are a good fit for your workload.

Cost and operations

The announcement does not include details on pricing or service quotas. You should expect to pay for the AWS services that your rewritten application uses (for example, Lambda, S3, DynamoDB, and SQS), as well as for any additional tools or infrastructure that you deploy to run the agent. AWS Transform itself may have a cost, but that information is not provided.

Security and reliability

The source does not mention security or reliability aspects of this feature. When you rewrite code to use AWS services, you will need to apply the usual AWS security practices, such as

• Using AWS Identity and Access Management (IAM) roles and policies that grant least-privilege permissions to the new AWS SDK calls.
• Encrypting data at rest and in transit, using AWS Key Management Service (KMS) and HTTPS.
• Applying AWS monitoring and logging (for example, Amazon CloudWatch and AWS CloudTrail) to the new services.

Limits and trade-offs

The feature has several limits that you should know about:

• It supports only a subset of Azure services and their APIs. If your code uses other services, you will need to rewrite those parts manually.
• The agent may suggest mappings that are not optimal for your workload. You should evaluate each suggestion and consider alternatives.
• The rewritten code may have different performance characteristics on AWS. You will need to test and tune it.
• The agent does not change any infrastructure configuration (for example, Azure resource definitions). You will need to recreate that infrastructure on AWS.

Who should act

This feature is relevant to you if

• You have a significant .NET application that runs on Azure and that you want to move to AWS.
• You want to reduce the manual effort of rewriting Azure SDK calls to AWS SDK calls.
• You are ready to test and validate the rewritten code on AWS.

If you have only a small or trivial application, or if you plan to rewrite the application from scratch rather than migrate it, this feature may not be worth the effort.

Bottom line

AWS Transform’s Azure-to-AWS code conversion is a helpful tool for teams that need to move .NET applications from Azure to AWS. It removes a manual, error-prone step but does not eliminate the need for testing, validation, and possibly further refactoring. If you have a large Azure-based .NET code base and you want to migrate it to AWS, this feature can speed up that process.

Sources

• AWS Transform announces Azure-to-AWS cloud-native code conversion