To plan a migration “journey,” you must first collect information about applications running in the enterprise to support analyses of their suitability for transformation. Ideally, this enterprise architecture knowledge base exists in most enterprises today and is a good place to start to understand the lifecycle of an application and its dependencies. Some of the criteria and dependencies are shown in the following figure. There are many considerations to be made that will have an impact on decisions about where these workloads might live and how they might best be served by new paradigms, such as hybrid cloud afforded by VMware Cloud Providers. You can think of the items in the following figure as requirements you might give a real estate agent for a good picture of what your applications’ new home will look like. Of course, in this case that new home might be a VMware Cloud Provider. We want the best way to match tenants and their applications with their new home and Discovery and Assessment is the first step in reconnaissance to execute a successful migration.

 

The following table describes the first of several attributes in what becomes a multi-dimensional analysis, although there are not an overwhelming number of values in any dimension. An application can be in one of many states in terms of its lifecycle. In many cases, there might be a lack of information or a lack of understanding as to how available information is parsed so that enterprises can decide whether applications are migrated beyond virtualization and into some type of cloud environment. The values in the following table are desired future state values, which will require some sort of transformation. (Except in the case of numbers 1 and 2, which is a conscious decision to either end the application lifecycle, maintain status quo, or at least forego any migration to virtualization or cloud.)

 

Dependencies are important to glean in the Discovery and Assessment phase because they aid in characterizing applications in a different dimension from that of the Lifecycle Stages shown in the previous table. The new dimension in the following table addresses the overall complexity of the application with regard to its dependencies. It is critical to map and understand how applications leverage different tiers such as a traditional three-tier application with database, business logic, and Web facets.

While these discovered migration candidates might be defined local to a single instance of an operating system (a virtual machine in the case of migration), they might also be located in more than one virtual machine grouped together in what is known as a vApp, or a form of container to create startup/shutdown sequence and other elements such as a Network Address Translation (NAT) service from a VMware vCloud Director® managed VMware NSX Edge™.

 

 

While numbers 1 and 2 in the table have inter-dependencies that are self-contained, as you transition from number 2 and beyond, you start to rely on services such as PKI, DNS, Internet routing, Active Directory, or LDAP, to name a few, that either have to be made available in the new environment or have a network configuration that allows for the components to communicate across sites. Just as whether or not you bring your vehicle on your aforementioned human migration is determined by its suitability for conditions, cost to keep it available, and so on, similarly, you must decide whether to make, for example, Active Directory available in the cloud through a new instance or with some sort of federation, providing the authentication services required. The potential changes to be discovered are in the operating model of account provisioning, network availability, throughput for replication, and so on.

After these dependencies are well understood and these services are available in the new environment, either by new deployments or having the existing services delivered through a hybrid cloud network, migration of the critical services can begin. The capability to configure your virtualization and hybrid cloud topology with VMware NSX and vCloud Director is described in other sections within the vCAT-SP. Providing for these dependencies is a requirement for the migration of any application with a number 3 and above from the preceding table. It is also where the most value lies, in terms of leveraging a VMware Cloud Provider, because of the ability for hosting enterprise applications in a hybrid cloud architecture when defined by architectures in the vCAT-SP.

In the previous table, the attributes reflect a maturity model, where number 4 is not only a VM or vApp with dependencies, but literally a distributed application architecture. This is the Zen-like apex of the hybrid cloud phenomenon, where each component in an application and its dependencies are located wherever they are best suited to serve their purpose, and dynamically providing the network connectivity and operational control to be able to achieve that goal. As an example, consider an e-commerce application that has Web and business logic tiers running elastically in a VMware Cloud Provider implementation. This application leverages an Active Directory server for authentication and a customer master database that both remain on premises and connected to the VMware Cloud Provider Program data center. It also posts transactions for orders to an SAP system hosted in Virtustream or other VMware Cloud Provider. If there is a well-defined set of network requirements such as those provided in the SAP HANA Network Requirements white paper, you can gain tremendous agility and reusability by leveraging the VMware software-defined components to support the application wherever it runs across the VMware Cloud Provider Program hybrid cloud environment.

In the previous table, number 5, the Packaged Application (such as SAP used in the example), can be a distributed application or not, but it also has additional considerations. To get an idea of why SAP or packaged applications might require their own migration category, see the VMware Adapter for SAP LVM document that describes how the adapter allows for automation of the packaged application along with SDDC constructs. The automation of the collective APIs from VMware and the packaged application vendor creates tremendous out-of-the-box opportunities to host large enterprise applications on the only SDDC platform able to provide the kind of performance required.

Categorizing migration candidates with these simple tags yields a subset of applications that can be suitable for one-time, self-service migration using one of the tools prescribed by the COE. As long as the target provider infrastructure and the dependent network connectivity or other services have been made available and the stakeholders involved agree, the opportunity to migrate workloads and perhaps even to later “stitch” in other dependencies to made available over the network can yield a successful first “wave”. Lack of planning and understanding the totality of the migration, its waves and dependencies, however, can place the overall successful migration in jeopardy. Whether an application exists in a single VM or a distributed set of them, you can discover more about them for enhanced manageability in the hybrid cloud model. Methods to gather such information are covered in the following section.