You usually do not hear much from our consultants during migrations: they are hard at work achieving the agreed objective as quickly as possible. They do this by applying best practices wherever possible. Sometimes, they face a dilemma: which is better, a quick migration or one that takes a little longer and costs a little more, but leaves you with fewer problems in the future?

This is the dilemma Frederique discusses in her blog. She recommends putting the choice to the stakeholders. As I read it, I wondered: “How would that conversation with the stakeholders go?” I asked Frederique, and she replied:

“In my blog, I describe an on-premises environment: a Windows Failover Cluster being migrated to AWS (Amazon Web Services). These clusters are typically used in environments running an important application that must not have multiple instances running simultaneously. In my blog, I use concert ticket sales as an example. You want to make sure that a ticket for a particular seat is sold only once, so that two people do not end up with tickets for the same seat at the same concert. You can imagine other situations too, such as reserving a loading bay for a lorry during a specific time slot in a logistics environment.”

“You want to make sure that a ticket for a particular seat is sold only once, so that two people do not end up with tickets for the same seat at the same concert.”

When carrying out an AWS migration, you first need to assess the on-premises environment. If you know how long it takes to move a cluster from one node to another, you can estimate how long this will take within AWS.

I wrote a sample application that simply displays the server’s time on a web page. By requesting that page every second from another node and then stopping the node hosting the website, you can measure exactly how long each solution takes to switch the application from the first virtual machine to the second. The results often surprise technical specialists accustomed to cluster moves taking a few tens of seconds. In the AWS cloud, this always takes longer: from just under a minute for a like-for-like migration to as much as nine minutes when using AWS technology with a load balancer’s default settings. However, the costs also vary considerably: the like-for-like migration has operating costs around four times higher than the standard AWS solution.

When designing a new system in AWS, you would naturally no longer use Windows Failover Clusters. Instead, you might use a serverless Lambda function configured to prevent multiple instances from running simultaneously. Alternatively, you could use a container, preferably running in the serverless Fargate environment. Or you could use database locking to prevent certain records from being updated concurrently.

During a migration, you often do not have that option: the existing environment needs to be moved to the cloud as quickly as possible. Optimisation usually happens only once everything is running in the cloud. In projects like these, you face a choice: what costs are you willing to pay, and what risks are you willing to take? The project delivery team and the client have different priorities. The project team primarily wants to finish quickly, and low operating costs are an advantage because they reassure the customer that migrating was the right decision. The client, however, is better placed to assess whether the risks taken are appropriate for the business being migrated.

“During a migration, the existing environment needs to be moved to the cloud as quickly as possible. Optimisation usually happens only once everything is running in the cloud.”

1. A like-for-like migration of the Windows Failover Cluster.

The advantage is a very short failover time between two nodes if one fails. Another benefit is that migrating the software can be very quick. You may currently deploy software manually and need to automate that process, but the environment itself closely resembles the on-premises setup. There are drawbacks too: operating costs are four times higher than those of the standard AWS solution. And if a network issue within your Availability Zone makes all its nodes unreachable, deploying your CloudFormation template in another region takes around 45 minutes.

2. Migrating a Windows Failover Cluster to an AWS Auto Scaling Group.

This solution offers low operating costs. It is also considerably less complex than a like-for-like migration. Looking at the number of workarounds and the amount of code involved, it is much easier to teach new colleagues how the Auto Scaling Group solution works than to explain everything happening within both AWS and the Windows Failover Cluster to keep it running. The drawback is the long failover time: if a node fails, deploying a new one takes an average of 7.5 minutes. This time is the same whether the problem affects the node itself or the Availability Zone.

3. Migrating a Windows Failover Cluster to an AWS Auto Scaling Group with a custom image.

This approach resembles the previous solution, but a custom image is created first. IIS and your application software are installed only when creating a new image, rather than during every failover, reducing the failover time by more than a minute. Costs are slightly higher than for the previous option. The main additional costs come from the solution’s complexity rather than its infrastructure: extra documentation and knowledge transfer to the technical specialists who will manage it in the future.

You may now be wondering why you would migrate systems to the cloud at all if failover always takes longer. The answer lies in the cloud’s other benefits. For example, AWS data centres generally have better physical security than on-premises data centres. In my solution, everything is scripted, so applying a Windows update simply involves shutting down the CloudFormation stack and redeploying it. This also deploys fresh virtual machines, preventing the build-up of old clutter that you typically encounter after running a Windows Failover Cluster for three years, including files left behind by Windows itself and temporary files left by administrators. If a Windows Server starts performing poorly on-premises, this often becomes a problem: rebuilding the server takes so much time that it is usually left undone. Sooner or later, this leads to production disruptions.

Another benefit is scalability. Suppose an application is modified and suddenly needs more CPU power or memory. In AWS, you can switch to a more powerful virtual machine type relatively easily. With everything scripted, you can quickly redeploy your solution.

When choosing a migration approach focused on short-term cost savings, the priorities will differ from those of an approach aimed at minimising operational risks over the long term. Frederique’s blog series clearly compares the alternatives, taking into account the costs and failover time of each solution. “I believe our specialists should discuss the possible scenarios with the client, because they will experience both the financial consequences and the consequences of our risk assessments over the longer term.”

“Ultimately, costs can fall considerably when you use the cloud as intended, making greater use of serverless solutions. However, this requires a redesign that is often a little too complex to tackle amid the pressures of a migration. Our specialists would be happy to help you get the best return on your investment.”