From a technical perspective, a Cloud migration project can be quite simple or rather complex, depending on factors such as the migration scope and maturity and life cycle of workloads being moved. The way to find out the degree of complexity is to perform a very good process of Discovery and Workload Analysis.

If you find (in your Discovery and Analysis phases) that technical challenges are of low complexity, then the migration should be much easier and faster. However, as the level of complexity and the migration challenges are higher and bigger, you should expect increased time and effort required for successful migrations.

Let´s discuss each of the complexity and challenges that you are likely to find.

1. Dealing with Integration

First and foremost, the complex issue you may encounter when performing a migration project is the level and complexity of the integration of the data, systems, and processes to be migrated. In medium to large enterprises, you don’t usually find isolated systems, but interconnected applications, which can be tightly coupled at the business process or data level or can be used for reporting purposes. Dealing with integration in a Cloud migration project includes topics such as:

• Application interfaces of different nature and types: online, offline, batch, synchronous, asynchronous, use of files, utilization of sockets, use of message queues, FTP servers.
• Data imports, exports, extractions, and conversions for loading reporting and analytics systems
• Systems connected for running different type of workflows or BPM driven processes

Typically you can also find integration not only between your internal systems and applications, but with different type of business partners you might be dealing with: customers, vendors, banks, third-party logistics, and others.

Integration challenges also have to do with the way that complex and multi-tiered systems are designed, architected, and set up: load balancers, web servers, application servers, database servers, presentation servers, and so on.

And probably the one aspect that has more impact on the smoothness of a Cloud migration is to be prepared that systems and application connectivity is set up correctly regarding security, access, and authorization policies, for example, issues such as firewall rules, ungranted permissions, network security groups, service accounts, domain controllers, and correct access to the proper resources that have to talk to each other.

In Cloud migrations, one of the most important aspects to deal with these issues is to perform a thorough discovery and workload analysis where you can identify and inventory all these integration needs, inter-systems dependencies, and security policies.

So, what can you do to be prepared and avoid trouble as much as possible when dealing with integration challenges? Here are some ideas, which we cover in detail in several sections and chapters throughout the book:

• There are automated assessment and discovery tools that are able to find IP addresses, ports, and protocols used for incoming and outgoing connections. Watch out that this type of tooling cannot automatically discover all integration and dependencies.
• If you don’t have or can’t use automated discovery tools, try to create your own type of connectivity and integration inventory. Make sure to include integration and dependencies within the workload analysis. When possible, perform technical checks within the systems with administrator privileges to review any and all settings for configuring connectivity among systems.
• Often connectivity is set up inside the applications, so you will need the help and support of application owners, service managers, admins, or support personnel to stop them and be ready for the changes that it might have on impact in a migration.
• As much as possible, you should set up all your connections and firewall rules that require IP addresses using a DNS type of addressing since a simple change of the DNS value could automatically resolve many of the problems when changing IP addresses in a migration. This should be a best practice when designing and developing any type of interfaces and integration in your company.
• Identify all the stakeholders involved in interfacing and integration that can be required and called upon in a migration to Cloud project.
• Mock integration testing is an absolute must in complex environments. That must be carefully prepared. It’s also good planning for the step-by-step adjusting and correct configuration of interfaces and security controls. The recommendation is to be as specific as possible in your migration protocol (runbook) in regard to those activities.
• Regarding multi-tiered systems and applications, the key aspect in order to solve the complexity of moving these types of systems to the Cloud has to do with the designing and deployment of the target architecture. This can be a complex task since often there is no simple option for a redesign in the Cloud, and there might be many factors and considerations according to specific business needs.

Remember that integration is not an isolated technical issue when approaching a migration to the Cloud, but one that is tightly coupled with the other technical challenges we are discussing below.

2. Data Gravity and Downtime for Migration

Data gravity is a technical term that refers to the “weight” of the data within the data centers and the “power of attraction” that it has with regarding to bringing together -attracting as the earth gravity- additional systems and applications. Most often this data is also dynamic, which brings additional challenges in a migration.   It takes more effort to connect and transfer the amount and nature of data from source data centers to the Cloud. Since there is more data gravity, the more volume of data that needs to be transferred in an organized way to defy that gravity.

Closely related to how to overcome “data gravity” effects for a Cloud migration (even for a migration where only data is transferred), there are collateral issues such as the connectivity and the bandwidth available between data centers and the Public Cloud, integration technical issues (see section above), the dynamic nature of the data you might need to transfer and the downtime that can be acceptable for the less risky disruption of daily business operations.

Overcoming “data gravity” issues can be addressed from different angles and with various technologies, for example:

• From a technical perspective, there are migration tools that can replicate the storage or the data while maintaining consistency and uptime of source systems, providing short cutover times.
• Most Public Cloud vendors offer their own migration tools and services (even the possibility of sending offline hard disk storage) to deal with this issue.
• When dealing with dynamic data, in particular with transactional and operational databases, most include their own replication techniques the same way they are setup for clustering and high availability (for example Oracle DataGuard, Microsoft SQL Server Always On, or SAP HANA System Replication just to mention a few) which can allow you to have a system on premises and sending the replication to the Cloud system. Additionally, and specially to deal with minimum downtime, the database log shipping mechanism can be used.
• Finally, the order and grouping of workloads to be moved to the Cloud is a topic to carefully plan. While for single or simple systems with no or low dependencies this can be quite straightforward, complication starts with high levels of integration complexity and dependencies. To deal with that, workload analysis must take into consideration how to make the right “logical move groups”, organizing those workloads into groups that make sense to move together.

3. Compliance and Security

For many types of enterprises, and the industry they belong to, it might be required to have different levels of compliance validations and security standards that must be met, wherever the systems and applications are located, whether on premises or in the Cloud.

Cloud is a new way of delivering computing resources, not a new technology. Cloud computing provides the scale and flexibility that attract businesses due to many benefits like reduce capital expenses, agility and resiliency. However, this could have a good and bad impact on security as well.

From one side, massive concentration of resources and shared infrastructure can be more attractive to attackers, especially with the publicly accessible cloud management APIs. From the other side however, cloud-based security defenses can be more robust, scalable and cost- effective.

Since migrating to the cloud includes a third party (the cloud provider) that offers services on your behalf, a new shared responsibility model evolves when adopting a cloud strategy. The cloud provider handles security of the cloud while you are responsible of security in the cloud. This means you should carefully understand what you are responsible of securing instead of assuming it is taken care of by the cloud provider.

The Cloud also affects the way organizations deliver and measure compliance. In fact, the same shared responsibility model that applies to security pertains also to compliance. Compliance is a shared responsibility in the cloud. Just because you are putting your data in the cloud does not mean the compliance responsibility shifts entirely to the cloud provider.

Only by carefully understanding how the cloud operates, and what you are responsible of securing, you can establish a security governance that can work for the cloud. Chapter 6 of the Migration Handbook is fully dedicated to dealing with Security and Compliance for adopting or migrating to Cloud.

4. Networking, Connectivity and Latency

Needless to say, your enterprise users and admins will have to connect and access their applications and systems from their sites, and to perform any type of move, transfer or migrations, you will need to setup connectivity between sources sites to Public Cloud or Clouds (for those companies adopting multi-Cloud strategies).

Connectivity and communications can be provided by your operator of choice and you might reuse all or part of your current communications or additionally look at more modern, advanced, and faster options such as SDN (Software Defined Networks) and other tooling that are able to create almost “on the fly” a new type of safe and virtual networks. Public Cloud vendors are increasingly looking into making the process of “new networking” easier and faster, with many options to choose from.

Topics that present a technical challenge regarding the overall communication needs have to do with availability of tools and communication operators in the areas where you run your business. While this is not an issue in many countries, there are still regions in the world where setting up communications with Public Cloud are neither easily available and might present issues such as high latencies which might be unacceptable for certain business process to operate properly.

Latency is the time it takes to systems or nodes to reach another system or node. It can be the one-way or round-trip time, and it´s usually measured in milliseconds. In practical and simple terms, is the delay between two systems to reach each other.

5. Supported Platforms

The feasibility, type of migration (dealt with in a full chapter in the Migration Handbook) and available technical options for performing a successful migration to a Public Cloud will also depend on whether the underlying system platform, mostly the operating system and its release version is supported or not (can be deployed and the vendor will provide maintenance and support) in the Cloud. There other restrictions regarding what is currently supported and not supported in the Cloud.

In practical terms, the leading Public Cloud vendors only support 64-bit based Microsoft Windows systems and most types and flavors of Linux operating systems (CentOS, Ubuntu, RedHat, Suse, Debian and few others), and only from certain newer releases.

You can only find restrictions about using certain software or database engines on top of the supported operating systems in the Cloud. At times, due to actual technical restrictions and other times, even if technically feasible, it might be that the software vendor does not certify or offer maintenance or support to their software on certain or all of the Public Clouds.

In general, what is now being called “legacy” platforms, such as those of mainframe computers, IBM AS/400, HP/UX and many other older systems can not be deployed in the Public Clouds.

6. Understanding the Technical Differences

The summary of this section is that to approach Cloud Adoption or a Migration to Cloud, understanding the technical differences, the capabilities and the design options and restrictions is a key aspect on the overall process. With the examples we are including throughout the book, we are trying to give a broad overview of these differences, mostly from a practical -and not deep academic- perspective. You can find many of the technical differences and restrictions in Chapter 3, dealing with the different types of scenarios you might find when approaching a migration and the options available for each.

This is the reason that the Migration Master plan includes the need to get not only general acknowledgement of Cloud concepts but also technical training. There are plenty or online and onsite training courses and material, all major Public Cloud vendors offer many certifications tracks and programs.