How to analyze your applications for a migration to Cloud? - Part Three
This is the third part of a method of analyzing the application portfolio for a lift and shift migration to Cloud. You have built your Application Catalogue and eliminated obviously incompatible applications. The easy part is over. Now we will delve into application components. Each finding here will lead to further analysis, and we will try to foresee and mitigate all problems the application might experience on Cloud.
4. Analysis
Integrations and Connections: Inbound and outbound connections of an application to other applications and shared services, as well as to external parties, are essential. You will have to migrate relevant access configurations to Cloud, but most organizations lack updated knowledge on this area. Discovery helps in this regard; however, they also contain much irrelevant traffic (SSH/RDP, Exchange, Security and Network tools, etc.). In addition, you might miss seasonal traffic, depending on the period of your discovery. Therefore, retrieving and analyzing automated discovery results and verifying them with the client will give you a solid dataset to rely on during the migration. This was a big exercise, and it took us a couple of months to analyze and go over the discovery results with the client.
Regarding internal connections, you should verify that all connection points that will be physically separate from the application tolerate latency. In our case, we had an RFID application that didn’t work when we separated the sensor from the server. In another case, the application had many inbound and outbound services with the SAP workloads, and performance was unbearable when we put them into different CSPs.
External connections are a different story. Outbound external connections will have to be validated and configured on your Cloud setup (on the firewall, security group, etc.). However, will you need a Public IP? Do you have to have it whitelisted somewhere? Will this third party accept one IP address, a range of IP addresses, or any random IP address set that you give them? Clarify this with the application owner because SNAT is not a strong suit of CSPs at the moment.
Licensing (COTS): You will need to check licensing requirements of custom-off-the-shelf applications. Consult your vendor because you might need to generate new licenses with respect to the new MAC address or IP. In addition, certain licenses can only reside in physical servers, which makes them impossible to move to Cloud. We didn’t run into any issues regarding licensing, only minor setbacks during the cutover where we had to wait for a new license to be generated.
SMTP: This was not a big issue, but it is important to remember. Which one of your applications sends e-mails? Remember to mark them and add them to the list during the cutover.
DNS Records: You know that you will have to update your DNS records with respect to your new IPs on Cloud. But do you know all DNS records related to that application? We had to update several internal DNS records after the cutover because nobody was aware of them, and they were showing the old servers. I don’t know how to collect all related DNS records efficiently but to analyze the whole list and ask the application owner. There is even less room for error regarding the external DNS records.
IP Dependencies: Your internal IPs will change. This means everyone and everything in your organization using an IP address to access an application will need to be updated when this application is migrated to Cloud. You can try to get rid of these dependencies before the cutover, but usually, you will not want to manage another change during the migration.
Load Balancer Configuration: I’m not an expert on this, but in my experience, CSP load balancing solutions are less mature than their on-premise counterparts. Each has its use cases, and ELB or Application Gateway are great products; however, this is probably where we had the most issues. The client has done many questionable solutions with their on-premise load balancer, and it was challenging to migrate those configurations to Cloud. In fact, we haven’t migrated certain configurations yet; we will deal with them in a more suitable time slot. In hindsight, we could have spent more time reviewing existing load balancer configurations.
Certain things to look out for your internal load balancers. The Health Probes require access to certain Azure IPs to work; otherwise, you will not see the “Healthy” sign on your servers.
Firewall Configuration:
Each Cloud Service Provider has numerous offerings around network and security and best practices on using them on their infrastructure. Needless to say, this is a crucial area that requires extensive thinking before acting since as you move applications, your network architecture becomes harder and harder to change.
For example, we used Azure Firewall and Application Gateway to secure our setup. We put Azure Firewall in front; however that blocked us from getting the client IP (x-forwarded-for header becomes the Firewall’s private IP in this case), so it became a huge problem for the security team to correlate information for cyber attacks. Later, we decided to change our setup and put the Firewall and the Gateway in parallel. This resulted in some amount of rework (luckily, it could have been much more). I suppose using the Firewall and the Gateway in parallel could be an acceptable setup for most companies, as you can directly manage HTTP(S) traffic with the Gateway and filter the rest with the Firewall. However, in any case, make sure to read Azure documentation.
For AWS, we used a 3rd party firewall (this is the preferred setup for AWS) which made our lives much easier, to be honest.
Certificates:
This needs a bit of explaining, so bear with me. The client has no standard regarding the internal traffic; for some applications, the traffic was end-to-end encrypted, and for others, SSL offloading was done at the load balancer. As a result, some IIS servers had both HTTP and HTTPS broadcasts, and for HTTPS broadcasts, certificates were expired. This was not an issue before migration as the client’s on-premise load balancer did not validate expired certificates if the offloading was done at the load balancer. However, Azure Application Gateway does not allow that. So we had to check the HTTPS broadcasts on IIS servers and make sure that the certificates were updated before migrating, even if they were not used.
Before migration, discuss HTTPS broadcasts with your IT owners and developers. You might need to change the broadcast to HTTP or update the certificate on the server. In fact, it is definitely better to adopt a standard for internal traffic in the long run and apply it across the infrastructure. I have seen many clients who do not encrypt internal traffic, but it could be a problem for others.
5. Final Words
So, thanks to anyone who made it this far, this has been a great retrospective for me, and I hope it will be useful for some comrades out there. My e-mail is below if you want to reach me for more information or a well-deserved criticism for all the errors and outrageous claims I made here.
For some final notes, I would like to remind you to check the uptime on your servers; they might receive Windows updates in the middle of the startup on a migration wave night. Also, take extra care of your Windows 2008s and Windows 2012s before migrating them; those were the ones we spent the most effort troubleshooting during migrations. Finally, just in case if you have time, make sure to remove McAfee agents before migration. We couldn’t startup certain servers because of some .dll files in those agents.