Contents

According to an announcement reported on October 20, 2026, AWS Transform can now convert Azure SDK code in .NET applications into code that uses the AWS SDK. It supports conversions such as Azure Functions to AWS Lambda, but teams still need to validate application behavior and address code the tool cannot convert.

Key Points#

  • AWS Transform now supports code conversion for .NET applications that use Azure services.
  • It supports conversions for functions, object storage, queues, and NoSQL databases.
  • Code without a supported equivalent may become TODO comments, stub code, or guidance in a separate Markdown file.
  • Treat converted applications as migration candidates that require review and testing before deployment.

What AWS Transform Converts#

This update addresses a specific migration challenge. .NET applications built with the Azure SDK depend on Azure services. Moving them to AWS requires changing service calls, not just moving application files.

AWS Transform supports conversions between the following four service pairs.

| Azure Service | AWS Destination | |---|---| | Azure Functions | AWS Lambda | | Azure Blob Storage | Amazon S3 | | Azure Queue Storage | Amazon SQS | | Azure Cosmos DB | Amazon DynamoDB |

These mappings provide a starting point for replacing Azure dependencies. However, they do not guarantee a direct equivalent for every feature, setting, or usage pattern. The supplied report does not detail the coverage within each service.

When This Update Helps#

The practical benefit is reducing the service integration code developers must rewrite manually. For example, calls in an application that saves files to Azure Blob Storage can be converted to use Amazon S3. The same approach applies to supported compute, queue, and database integrations.

This makes it useful if an existing .NET application uses the listed Azure services and you are considering a move to AWS. Before adopting it for a project, identify the application's actual dependencies. A service's inclusion in the support list is useful information, but you still need to check the operations and features your application uses.

The scope described here is code conversion. The supplied report does not establish that AWS Transform also transfers data, provisions all required infrastructure, or handles production cutover for these applications. Manage those as separate tasks in your migration plan.

Review Incomplete Conversions#

AWS Transform flags unsupported work through TODO comments, placeholder implementations called stubs, or a separate Markdown file labeled “Next Step.” Developers need to review each of these outputs.

Stubs deserve particular attention because required behavior may remain unimplemented. A successful build alone does not establish that the migrated application works. Review the converted code against the original application's behavior, including failure handling.

Use this four-item review checklist.

  • TODO comments: Identify missing behavior and assign an owner.
  • Stub code: Replace placeholders with working implementations before release.
  • Next Step guidance: Turn each relevant instruction into a trackable task.
  • Converted calls: Check that inputs, outputs, and error handling preserve the required behavior.

Test Service Behavior#

The source and destination services serve similar purposes, but their APIs and behavioral rules may differ. Validate against application requirements rather than simply checking whether the new SDK calls compile.

For Azure Functions conversions, test how Lambda functions receive events, return results, and handle failures. For storage code, validate file contents, metadata the application depends on, and access permissions. Queue tests should check retries and duplicate processing. Database tests should verify application queries and updates against the chosen DynamoDB design.

These are migration checks, not confirmed limitations of AWS Transform. The supplied report provides neither measured conversion success rates nor evidence that generated code preserves all application behavior. Define acceptance criteria before running a conversion so you can evaluate the results against clear standards.

Next Steps#

Choose one non-production .NET component that uses a supported Azure service and run a trial conversion with AWS Transform. Record every TODO, stub, and Next Step item, then test the component's main operations and one failure case before deciding whether to expand the migration.

Source: https://www.publickey1.jp/blog/26/aws_transformazure_functionsaws_lambdamicrosoft_azureaws.html

Contents