5 Technical Hurdles to Investigate Before Migrating to the Cloud

By Stephanie Myara - June 14, 2018
3 min read

Commodity cloud providers like Amazon, Microsoft and Google have spurred widespread adoption with generic offerings, but AWS, Azure and Google Cloud can’t fit every enterprise’s needs. If you’re planning to migrate complex on-premise applications to one of the giant clouds, you’ll likely face some kind of capabilities gap.

Let’s say you want to leverage the cloud to immediately extend the reach and ease of delivering demos, POCs, and training for your on-premise cybersecurity, data management or firewall applications, or to speed development of new features, or the resolution of customer support issues for that matter. You need to be especially cautious because these types of applications likely employ multi-faceted networking features – features known to spark questions, delays, and frustration during the migration process.

Before you mire your team in what might ultimately prove a costly, time-consuming or an utterly impossible project, you’d be wise to consider these five key networking capabilities that public cloud providers typically do not support.


For more on choosing a public cloud provider, download our white paper, “Why Public Cloud Providers Are NOT One Size Fits All.”


Specialized needs that cause trouble in public clouds:

  1. Network customization: The networking elements and structures you rely on for your on-premise applications will cause you headaches in a generic cloud environment. Maybe you spread your subnets across multiple noncontiguous CIDR blocks; implementing this approach in the public cloud could mean you have to re-architect everything – both your application and its documentation.
  2. Promiscuous mode: Many network security applications require promiscuous mode network interface cards (NICs), but generic public clouds don’t usually support this networking feature. That means for content firewalls, intrusion prevention systems, and other related applications, you might need to do a major application rewrite to get to the cloud.
  3.  Instance networking: Generic public clouds aren’t well equipped to support the deployment of single virtual machines (VMs) with multiple NICs and IP addresses. Your NICs per VM will be limited unless you pay for bigger instances, which can run up your costs and waste compute resources.
  4. Nested virtualization: You can potentially avoid the above issues by running nested VMs on top of each other, but this approach introduces a few other problems. First, you’ll up the latency levels on your applications. Second, most commodity clouds don’t support nested virtualization as part of their standard offerings.
  5. VM importing and exporting: Unfortunately, the VMs you most want to import to the cloud are likely to give you the most trouble. You may have been running them for years, and they may have been altered multiple times in ways that don’t align with the provider’s cloud import and export tools. If your applications include 32-bit Linux, Kali Linux, customized kernel or Windows XP, we’re talking to you. Commodity cloud vendors are unlikely to support your VMs, leaving you to decide whether to re-architect, modify or stay on premise.

By understanding key networking features typically not supported by the generic cloud providers in advance, you can avoid becoming involved in problematic projects. AWS, Azure and Google Cloud are solid options for some apps, especially cloud-native ones.

Yet, for on-premise applications with the significant hurdles notes above, enterprises should investigate specialized providers with the ability to move complex on-premise applications to the cloud immediately, without rewriting your application or your documentation.