Introduction
Many enterprises still rely on software built on core technologies that are 20 to 30 years old. These applications were never designed to operate in the cloud and often depend on legacy architectures that complicate migration. Documentation typically assumes on-premise installations, leaving significant gaps when transitioning to AWS.
Bringing such software into the cloud requires careful planning, deep technical expertise, and a willingness to work around limitations imposed by outdated design principles.
Windows Server software wasn't originally designed for the cloud
Windows Server licensing presents one of the first hurdles. Organisations must decide between bringing their own licences (BYOL) or using Amazon-supplied licensing. Each approach has cost implications and affects how instances are deployed.
The choice of Amazon Machine Image (AMI) also matters. Microsoft-supplied AMIs are optimised for AWS, but enterprises may require custom configurations. Selecting the right EC2 machine type is equally important, balancing performance, cost, and compatibility. Additionally, Ethernet throughput must be considered, as some older applications generate high network traffic and require robust and more costly networking configurations.
TL:DR – Migrating legacy Windows Server software to AWS EC2 is challenging but possible with careful planning, modern security measures, and technical expertise. Establishing clear budget constraints and cost controls early is crucial to prevent expenses from spiraling out of control.
Contents
Research into complex technical challenges
The particular software that the client required was never intended for virtualised CPU environments and places heavy demands on compute resources. Its high CPU load can make it inefficient on standard vCPUs, requiring careful instance selection.
Networking is another issue. Verbose communication over the network can result in performance bottlenecks and excessive data transfer costs. Firewalls often introduce compatibility challenges, requiring fine-tuned security group configurations. Storage is another major concern, as the software relies on obscure and often deprecated storage technologies.
Solutions for complex technical challenges
Choosing the right AMI is crucial. The selection process must account for compatibility, licensing, and long-term support. The EC2 machine type must be optimised to handle the application's CPU and storage requirements efficiently.
To optimise performance and cost, the platform architecture was redesigned compared to its traditional on-premise architecture. The number of instances was minimised by consolidating workloads where possible. Ethernet throughput analysis using Windows Event Manager helped identify and resolve performance bottlenecks.
Security was tightened using complex security group settings. The deployment segregated duties using user security groups and network security groups to limit exposure while ensuring compliance. Where possible, S3 was used instead of EC2 volumes to improve cost efficiency and simplify data management. Scripts were developed to facilitate data staging via S3, reducing the reliance on EC2 storage.
Storage optimisation was a key focus. Attention was paid to volume types, ensuring that high-performance disks were used only where necessary. Deployment methodologies were scripted to add rigour to the process. Ultimately, legacy knowledge played a significant role in overcoming these challenges – our experience with older technologies proved invaluable.
Region Restriction in AWS
Due to the nature of the data involved, AWS region restrictions had to be enforced. However, while EC2 can be effectively restricted, some AWS services, such as IAM, cannot be fully contained within a single region. This posed security and compliance challenges that had to be addressed.
Despite these limitations, the EC2 deployment was designed to be both restricted and resilient, ensuring that workloads remained available while meeting compliance requirements.
Lessons Learned
Ideally, no one would start a cloud project with such legacy software. However, reality dictates that enterprises must often work with what they have. Careful planning and execution can make even outdated software functional in the cloud.
Modern cloud services provide insulation against the security risks of open ports and unencrypted traffic. Technologies like Let's Encrypt can be integrated with IIS to improve security. Using modern browsers like Chrome instead of Internet Explorer further enhances usability and compatibility although it would have probably been a sacking offence to install a browser on Windows Server back in the day.
Conclusion
Migrating a complex platform based on legacy Windows Server software to AWS EC2 is not for the faint-hearted. Success requires technical expertise, a willingness to troubleshoot unexpected issues, and a deep understanding of both legacy and modern technologies.
Establishing clear budget constraints and performance expectations before starting is critical. Without proper cost controls, EC2 expenses can quickly spiral out of control. Implementing AWS budget management early ensures that costs remain predictable and within limits.
