Using AWS to bring Windows Server apps to the cloud

Introduction

In 2026, enterprises are still grappling with software built on core technologies that are 30 to 40 years old. Despite years of cloud-first mandates and modernisation programmes, a surprising number of organisations continue to run Windows Server workloads that were never designed for virtualised or cloud environments. The pressure to migrate has intensified — driven by rising on-premise infrastructure costs, end-of-support deadlines, and the measurable savings now achievable on AWS — but the technical complexity has not gone away.

AWS has been running Microsoft workloads since 2008, longer than any other cloud provider, and the platform has matured considerably across those 17 years. With over 850 EC2 instance types available for Windows Server workloads and tooling such as AWS Compute Optimizer and the AWS Optimization and Licensing Assessment (OLA) delivering concrete, data-driven guidance, organisations that approach migration systematically can achieve substantial savings. Legacy constraints still demand careful handling — but the gap between what is theoretically possible and what is practically achievable has narrowed significantly.

TL:DR – Migrating legacy Windows Server software to AWS EC2 remains a serious undertaking in 2026, but the tooling, licensing options, and cost optimisation capabilities available today are far stronger than they were even a few years ago. Establishing clear budget constraints and using AWS cost controls from day one is still the single most important thing you can do to prevent expenses from spiralling.

See also: FREE Windows web server with a Lets Encrypt SSL certificate in AWS

Why Windows Server software still struggles in the cloud

Windows Server licensing is often the first hurdle. Organisations must decide between bringing their own licences (BYOL) or using Amazon-supplied, licence-included pay-as-you-go options. Each approach carries different cost profiles and affects how instances are deployed and sized. The right answer depends heavily on your existing licence agreements, Software Assurance status, and projected usage patterns.

The choice of Amazon Machine Image (AMI) matters too. Microsoft-supplied AMIs are optimised for AWS, but enterprises frequently require custom configurations that deviate from defaults. Selecting the right EC2 instance type is equally important — with over 850 instance types now available, the choice is genuinely complex, and balancing performance, cost, and compatibility with software that may have been written when multi-core CPUs were exotic requires deliberate analysis rather than intuition. Network throughput is another variable: older applications can generate unexpectedly high traffic volumes, pushing deployments towards more capable and more expensive networking configurations.

None of this is insurmountable, but it requires a level of deliberate planning that many teams underestimate when they first scope the project.

The specific technical challenges of legacy workloads

Legacy Windows Server software was frequently written without virtualised CPU environments in mind. Heavy compute demands that were manageable on dedicated physical hardware can become inefficient — and expensive — on standard vCPUs. Instance selection therefore requires more than a like-for-like lift of the on-premise spec.

Networking compounds the problem. Verbose inter-process communication, which was tolerable on a local area network, translates into performance bottlenecks and real data transfer costs in the cloud. Firewall rules that were once managed at the perimeter now need to be replicated — and often rethought — as fine-grained EC2 security group configurations. Storage is a further concern: older applications frequently depend on storage technologies that are obscure, deprecated, or simply incompatible with modern cloud-native approaches.

These are not edge cases. They are the norm for enterprise software that predates cloud architecture by a decade or more. The organisations that navigate them successfully are typically the ones that invest in understanding the application's actual behaviour — CPU profiles, storage access patterns, network chattiness — before committing to an instance family or storage configuration.

How to approach the solutions

Choosing the right AMI remains foundational. Compatibility, licensing, and long-term support must all be evaluated before committing to an image. EC2 instance type selection should be informed by profiling actual CPU and storage behaviour rather than relying on vendor sizing guides written for bare-metal deployments.

AWS Compute Optimizer is now a practical starting point for this analysis. It can surface rightsizing recommendations that reduce infrastructure spend by up to 25%, and it can flag opportunities such as SQL Server edition downgrading where workloads are over-provisioned for the edition they are running. The EC2 Optimize CPUs feature goes further — by adjusting vCPU counts to match actual licence and performance requirements, organisations are achieving an average of 50% savings on licence costs, a figure that can materially shift the business case for migration on its own.

Architectural redesign often delivers more value than simple lift-and-shift. Consolidating workloads to reduce instance count, replacing EC2-backed storage with S3 where the application permits, and scripting deployment methodologies to enforce consistency all contribute to a more cost-efficient and maintainable outcome. Security group configuration should segregate duties clearly — separating user-level and network-level controls — to limit exposure while satisfying compliance requirements.

For organisations running Active Directory-dependent workloads, AWS Managed Active Directory removes the operational burden of maintaining domain controllers in EC2, while Amazon FSx for Windows File Server provides fully managed Windows-native file storage that integrates cleanly with applications that depend on SMB shares and NTFS permissions. AWS License Manager adds a further layer of control, tracking licence consumption across the estate and enforcing the rules that prevent inadvertent licence breaches at scale. These managed services collectively reduce the surface area that migration teams need to own and operate themselves.

Where possible, legacy knowledge remains an asset. Familiarity with older storage subsystems, network protocols, and Windows Server internals still makes a material difference when the application behaves unexpectedly in a virtualised environment.

Containerisation and modernisation as a migration path

Not every Windows Server workload belongs on a long-term EC2 roadmap. For applications where the underlying code is maintainable, containerisation is increasingly viable — and AWS has invested heavily in making it accessible. Windows containers are now supported on both Amazon ECS and Amazon EKS, and AWS App2Container provides a tool for analysing, containerising, and migrating existing applications without requiring a full rewrite. For .NET applications in particular, the path to Linux-based containers — and the cost and operational benefits that come with them — is more clearly defined than it has ever been.

AWS supports this journey through structured programmes including the AWS Windows Migration Accelerator, the AWS Migration Acceleration Program for Windows, and Experience-Based Acceleration (EBA), which pairs migration teams with AWS specialists who have worked through comparable projects. Serverless technologies represent the furthest point on the modernisation spectrum, and while they are not appropriate for every legacy workload, they are worth evaluating for components that are genuinely stateless and compute-bound. The key is to treat modernisation as a spectrum rather than a binary choice between lift-and-shift and full rewrite.

The economics of migration in 2026

The financial case for migrating Windows Server workloads to AWS is stronger than it has been at any point in the platform's history. AWS Optimization and Licensing Assessment data shows average savings of 77% on Windows Server licence costs for organisations that complete the assessment process. SQL Server licence savings of up to 74% are achievable where workloads are running on editions that significantly exceed their actual requirements — a situation that is more common than most teams expect when they first audit their estate.

Real-world migrations at scale back this up. SAP Concur migrated more than 85,000 SQL Server databases to AWS and reduced total cost of ownership by 72%. Mindbody completed a migration of over 60,000 SQL Server databases. Avionté achieved 99.999% availability after moving its Microsoft workloads to AWS. These are not proof-of-concept results — they reflect production migrations of the kind of sprawling, complex estates that many enterprises are still carrying today.

The AWS Optimization and Licensing Assessment is worth completing before committing to a licensing approach. The savings it surfaces can materially change the business case for migration, and it frequently identifies consolidation opportunities that were not visible from the on-premise perspective. Given that the assessment is available at no cost, deferring it is difficult to justify.

Region restrictions and compliance

Data residency requirements continue to drive region restriction decisions for many enterprise workloads. EC2 deployments can be effectively constrained to a single AWS region, but some AWS services — IAM being the most frequently cited example — operate globally by design. This creates compliance edge cases that must be addressed explicitly rather than assumed away.

The practical approach is to design the EC2 deployment to be both regionally restricted and resilient, ensuring workload availability while satisfying data sovereignty obligations. AWS has expanded its region footprint and its compliance certification coverage considerably, which reduces the friction here compared with earlier years — but it does not eliminate the need for deliberate architectural decisions. Organisations operating under strict data sovereignty regimes should map their compliance requirements to specific AWS regions and service configurations before the migration design is finalised, not after.

Lessons learned

Nobody would choose to start a cloud migration project with 30-year-old software if they had a clean slate. But enterprises rarely have a clean slate, and waiting for a full application rewrite before moving to the cloud is often not a viable option. The lesson from projects that have gone well is not that legacy software is easy to migrate — it is that the challenges are manageable when they are identified early and planned for honestly.

Cost control deserves particular emphasis. EC2 costs can escalate quickly when instance types are oversized, storage volumes are left attached after use, or data transfer patterns are not understood in advance. Implementing AWS Budgets and setting up cost alerts before the first instance is launched is not optional — it is the baseline discipline that separates successful migrations from expensive ones. The same applies to licence tracking: AWS License Manager should be configured from the outset, not retrofitted after the estate has grown beyond easy visibility.

Modern browser compatibility, certificate management through IIS-integrated services, and layered AWS security tooling have removed several categories of concern that complicated earlier migrations. The security baseline available today is substantially stronger than what was possible when many of these applications were first deployed — but it requires deliberate configuration rather than passive inheritance.

Conclusion

Migrating complex legacy Windows Server workloads to AWS EC2 is still not a trivial undertaking in 2026. It demands technical depth, a tolerance for unexpected behaviour, and a clear-eyed understanding of both the application's legacy constraints and the modern tools available to work around them.

What has changed is the scale of the opportunity. The combination of over 850 EC2 instance types, AWS licensing flexibility, Compute Optimizer recommendations, managed services that absorb operational overhead, and a mature ecosystem of migration tooling and programmes means that organisations willing to invest in proper planning can achieve cost reductions and availability improvements that would have been difficult to justify on paper even a few years ago. The case for migration is stronger than it has ever been — provided the execution is disciplined from the start.