Migrate a .NET app to AWS: modern .NET, legacy .NET Framework, and the Windows licences.

IWhy .NET teams move to AWS, and the one fork that defines the project

Common triggers: an acquirer standardised on AWS, an Azure renewal, AWS strengths the team wants, or ageing on-premises IIS servers. The engineering decision tree is the same.

Classify each application by runtime first. Modern .NET is cross-platform: cheap Linux compute, small images, every AWS container and serverless runtime. .NET Framework (4.8 and earlier) is Windows only: it runs on AWS, but on Windows capacity that carries a Windows Server licence. Many estates are a mix.

The decision tree: rehost as-is (Framework on EC2 Windows, modern .NET on Linux containers), replatform (containerise onto a managed runtime), or port Framework code to modern .NET so it runs on Linux and the Windows licence goes away. Most teams rehost or replatform first, then port the high-value Framework apps.

IIWhere modern .NET lands on AWS

For cross-platform .NET there are a few good homes. The choice is how much of the platform you want to own and what the traffic looks like.

• Amazon ECS on Fargate: The default for most estates: serverless containers, a load balancer, VPC control, per-service scaling and sidecars. For a single simple web app or API, ECS Express Mode creates the Fargate service, load balancer and scaling from one image. (App Runner, the old answer, closed to new customers on April 30, 2026.) ECS also runs Windows containers, which makes it the bridge for .NET Framework during a phased port.
• AWS Lambda: Modern .NET as managed functions or container images, for event-driven work, spiky APIs and background jobs. ASP.NET Core can run behind API Gateway with the Lambda hosting package. .NET Framework cannot run on Lambda.
• Amazon EKS: If you already run Kubernetes. Otherwise ECS is simpler for a .NET team.
• Elastic Beanstalk: A PaaS-style option that still supports .NET on Windows Server and Linux, useful for teams moving off IIS who want a managed environment.

IIILegacy .NET Framework: EC2, Windows containers, or a port

Most real .NET migrations carry at least one Framework 4.x app that cannot move to Linux without work. There are three honest options.

• Rehost to EC2 Windows: Lift the IIS VM with AWS Application Migration Service (MGN), which replicates continuously so cutover is short. No code change, but the Windows Server licence (and any SQL Server licence) comes with it.
• Windows containers on ECS or EKS: Containerise the Framework app and run it on Windows capacity. You get container packaging and CI/CD without porting, still paying Windows licensing. A halfway house.
• Port to modern .NET: The only option that removes the Windows licence. AWS Transform for .NET is AWS's current tool for porting .NET Framework to cross-platform .NET. Porting Assistant for .NET, the older tool, is no longer open to new customers.

IVThe database: RDS for SQL Server or Aurora with Babelfish

A .NET app almost always sits on SQL Server, so the migration is two projects: the app tier and the data tier.

Amazon RDS for SQL Server is the low-risk path: same engine, licence-included or bring your own, minimal app change because T-SQL and Entity Framework keep working. AWS DMS can do a full load then ongoing change data capture where the source supports it, so the cutover is a short window.

Aurora PostgreSQL with Babelfish speaks SQL Server's wire protocol and a large subset of T-SQL, so many apps keep connecting with little change while the SQL Server licence goes away. Babelfish does not cover everything (SQL Agent jobs, SSIS, CLR, linked servers and some advanced T-SQL), so run the free Babelfish Compass report per database first. A common pattern: RDS for SQL Server during the move, Babelfish as a follow-on. The full decision is in the SQL Server to AWS guide.

VTooling, IaC and the IIS to ALB translation

Most of the move can happen from Visual Studio, the CLI and your existing pipeline, and IIS concepts map cleanly.

The AWS Toolkit for Visual Studio and the AWS SDK for .NET cover deployment and service calls (Blob to S3, Service Bus to SQS or SNS, Key Vault to Secrets Manager). AWS CDK supports C#, so you can define the landing zone in the same language as the app, or use Terraform. Azure DevOps Pipelines map to CodePipeline and CodeBuild, or GitHub Actions with AWS OIDC.

An IIS site and binding becomes an Application Load Balancer listener and target group; host headers become host-based routing rules; TLS moves to the load balancer with a free ACM certificate. ASP.NET Core runs on Kestrel directly behind the load balancer. Windows integrated authentication has no direct equivalent: move sign-in to ALB OIDC or Amazon Cognito and federate the corporate directory (AWS Directory Service or IAM Identity Center). Inventory where you use it early.

VIA phased cutover

Move in waves: landing zone first, the stateless app tier next, SQL Server last, with a tested rollback for every wave.

• Assess: Classify every app by runtime and by the 7 Rs, measure the port effort (AWS Transform for .NET), and review licensing (OLA). Output: a target architecture, a cost case and a per-app verdict.
• Mobilize: Landing zone, network link back to the source, identity, ECR, pipelines and IaC, plus a pilot of one low-risk .NET service end to end.
• Migrate the app tier: Modern .NET to ECS or Lambda; Framework apps rehosted with MGN or run as Windows containers. Shift traffic with Route 53 weighted records and roll back by reverting the weight. Ported apps get full regression tests: Kestrel on Linux can differ from IIS (case-sensitive paths, culture defaults, file-system assumptions).
• Migrate SQL Server: Stand up the target, load it, keep it in sync where CDC is available, then cut over in a short window: stop writes, drain, switch the connection string, verify. Keep the source read-only as a rollback for a defined window.
• Validate and decommission: Watch CloudWatch and cost for a billing cycle, right-size, then shut the source down.

VIIWindows licensing, OLA, and who can fund the move

For .NET, the money story is often licensing: moving Framework on Windows to modern .NET on Linux removes the Windows Server licence for that app.

The savings land only for apps you actually port, so the port measurement drives the business case. AWS offers the Optimization and Licensing Assessment (OLA), a complimentary review of your utilisation, third-party licensing and dependencies, covering Microsoft workloads. AWS also says AWS Transform for .NET can cut operating costs by removing Windows licence dependencies; treat that as AWS's figure, not your forecast.

Partner-filed funding: AWS says the Migration Acceleration Program (MAP) helps offset initial migration costs, and lists Microsoft workloads among those it supports. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. Activate credits are separate, and you apply for those yourself.

CloudRoute matches you with one vetted AWS partner for your mix of modern .NET, Framework and SQL Server. Startups pay CloudRoute nothing; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.

VIIIThe .NET-on-AWS gotchas

These do not show up in a comparison table but reliably cost a day each.

• Framework cannot run on Linux or Lambda: Until you port, its only AWS homes are EC2 Windows and Windows containers, both with a Windows Server licence.
• Windows containers are heavy: Large images, slow pulls, Windows capacity. Treat them as a transitional state.
• Integrated authentication: No one-to-one equivalent. Move to ALB OIDC or Cognito and re-test every auth path.
• Kestrel on Linux behaves differently: Case-sensitive paths, culture and encoding defaults, temp directories, registry or IIS-module dependencies. Regression-test every ported app.
• SQL Server features beyond the schema: Stored procedures, SQL Agent jobs and SSIS do not move themselves. Babelfish Compass shows the gap before you commit.
• Licence savings need an actual port: Rehosting everything to EC2 Windows and never porting carries the full Windows and SQL bill into AWS indefinitely.