Four traps to avoid when migrating mature applications to the cloud

Some organizations still run some very old applications. In fact, I’ve come across some applications recently whose origins date back to the mid-1990s! Applications of this age can introduce some unique challenges that may not be obvious at first glance. But as with people, they still have value even when they get to an advanced age, so it would be better to call these applications “mature” instead of old.

Over the last few years, I’ve worked with a number of organizations to help them migrate their mature applications to the cloud. Along the way, I encountered quite a few difficult and unusual situations. In this post, I want to highlight four of the traps I’ve come across so that you can avoid them during your own migration projects.

1.     Operating system compatibility

migrating applicationsOne of the first considerations to address when migrating mature applications is to look at which operating system the application currently runs on and, in particular, which version of the operating system.

Most infrastructure-as-a-service (IaaS) providers will only allow you to create new virtual machines (VMs) using fairly recent operating systems. If your application is run on an earlier operating system, you should not assume that this operating system will be available from the IaaS provider. In fact, you may be hard-pressed to find a vendor who will let you create new VMs with earlier operating systems such as Windows 2003 server or Windows XP.

If you are then forced to move your mature application to a later version of an operating system, you should not just assume that the application will work unchanged on a later version of the operating system. You need to thoroughly test the mature application on the newer operating system to ensure that your application will still work as designed.

2. Software availability

If you are trying to move mature third-party software onto the cloud, then you should check to make sure that the software is available to reinstall—that you have the installation software available on storage somewhere, or that the installation software for that version can still be downloaded from the software developer.

One client I worked with was unable to locate the installation CD for its archiving system, and, because it was so old, the vendor did not sell copies of that version anymore. This client was then forced to decide between paying to upgrade the software to the latest version or keeping their system on premises rather than moving it to the cloud.

3.     Licensing activation

Licensing for mature applications can be an issue in at least two ways.

First, the licenses may not work on cloud-based VMs. Many software vendors use a licensing mechanism that uses certain aspects of the physical hardware, such as network card information, to generate a unique license tied to that particular computer. I’ve seen cases where, with some cloud providers, the hardware signature changes whenever a virtual machine is started or a new instance is spawned. In these cases, the licensing system in the software complains about it not being a valid installation, and the application won’t start.

And one other consideration for licensing is that if you are reinstalling a mature application and need to request a new license or activation code from the vendor, then you need to ensure that the vendors do actually still issue new codes for that version. If you have software that is more than a few years old, you will need to check with the vendor to make sure that they can provide you with new codes.

4.     Server database issues

Another major consideration when migrating mature applications is the migration of server-based databases such as SQL server databases.

First, you need to check the three issues described previously. Next, you need to ensure that if you change the type or version of the database that your application will continue to work. Changing versions of the same database server application is less risky but still requires testing to verify.

One last thing to keep in the back of your mind is field-size restrictions. This is not an issue with the database server itself, but you could potentially run into issues with the field-size limits imposed by the schema of the application. I ran into a problem with one client because the third-party vendor application that we were migrating had a field limit of 20 characters for a field that stored usernames. This had been fine when it was being run on premises, but when we moved it to the cloud the usernames were based on a different, and longer, domain name. The crux of the story is that this fixed-length field could not support the longer usernames, and because the application was from an external vendor the field size could not be changed by the client. This is certainly one trap to keep in the back of your mind.

What traps have you found?

We’ve looked at four potential traps when migrating mature applications to the cloud:

1. Operating system compatibility and availability
2. Application installation software availability
3. New license creation and license compatibility with modern VMs
4. Server database issues

This list can act as a good checklist when assessing the viability of moving a workload to the cloud. There are plenty more traps to be aware of though, and I hope to cover some more in a future post.

Have your say

But how about you? What problems or issues have you come across when migrating mature apps to the cloud? Please leave a comment here, or follow me on Twitter @ThingsESaid. I encourage you to share your ideas with the cloud community so that we can all learn from each other.

Share
Comments: 1
Ethann Castell

About Ethann Castell

Ethann has a broad IT background which includes project management, strategic consulting, solutions architecture and software engineering. Always the innovator, he has founded and lead two different IBM business partners and has successfully brought several commercial software products to market. Ethann’s qualifications include an MBA, PMP, Scrum Master and Six Sigma Green Belt. He is an IBM Cloud Ambassador and is fluent in several programming languages. Away from work, you’ll most likely find Ethann hiking in a remote location or supporting his local Rugby Union team. He lives in Sydney, Australia.
This entry was posted in Managing the Cloud and tagged , , , , . Bookmark the permalink.

One Response to Four traps to avoid when migrating mature applications to the cloud

  1. murphb96 says:

    This is a great article that hits on some very important considerations when utilizing the cloud. One other area where I have seen organizations fall into traps is when it comes to search and eDiscovery of data stored in the cloud. Traditional search and eDiscovery tools were not architected to truly support the cloud. The vendors may claim to support the cloud, but are simply re-branding their existing offerings. Data hosting, especially where the vendor’s manual labor is routinely required to upload and process data, does not meet defined cloud standards. Neither does a process that exports data through APIs or other means out of its resident cloud environment to slowly migrate the cloud data to the vendor tools, instead of deploying the tools (and their processing power) to the data where it resides in the cloud. Without a means to search data in the cloud, many of the benefits of storing it there will be lost.

    In order to truly support IaaS cloud deployments, eDiscovery and enterprise search software must meet the following three core requirements:

    1. Automated Installation and Virtualization. The eDiscovery and search solution must immediately and rapidly install, execute and efficiently operate in a virtualized environment without rigid hardware requirements or on-site physical access. This is impossible if the solution is fused to hardware appliances or otherwise requires a complex on-site installation process. As hardware appliance solutions by definition are not cloud deployable and with enterprise search installations often requiring many months of on-premise man hours to install and configure, whether many of these vendors will be able to support robust IaaS cloud deployments in the reasonably foreseeable future is a significant question. Conversely, a truly virtualized solution within the Amazon Web Services (AWS) public cloud can be installed remotely and on-demand by launching an Amazon Machine Image (AMI) than contains the object code and installer of the application.

    2. On-demand self-service. In its definition of cloud computing, The National Institute of Standards and Technology (NIST) identifies on-demand self-service as an essential characteristic of the cloud where a “consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.”
    Many hosted eDiscovery services require shipping of data to the provider or extensive behind the scenes manual labor to load and configure the systems for data ingestion. Conversely, solutions that truly support cloud IaaS will spin up, ingest data and fully operate in an automated fashion without the need for manual on-premise labor for configuration or data import.

    3. Rapid elasticity. NIST describes this characteristic as capabilities that “scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.” This important benefit of cloud computing is accomplished by a parallelized software architecture designed to dynamically scale out over potentially several dozen virtualized servers to enable rapid ingestion, processing and analysis of data sets in that cloud environment. This capability would allow several terabytes of data to be indexed and processed within 2 to 4 hours on a highly automated basis at far less cost than non-cloud eDiscovery efforts.

    However, many characteristics of leading eDiscovery solutions fundamentality prevent their ability to support this core cloud requirement. Most eDiscovery early case assessment solutions are developed and configured toward a monolithic processing schema designed to operate on a single expensive hardware apparatus. While recently spawning some bold marketing claims of high speeds and feeds, such architecture is very ill-suited to the cloud, which is powered by highly distributed processing across multitudes of servers. Additionally, many of the leading eDiscovery and enterprise search solutions are tightly integrated with third party databases and other OEM technology that cannot be easily decoupled (and also present possible licensing constraints) making such elasticity physically and even legally impossible.

    If you are interested in seeing a search and eDiscovery product that actually supports the cloud in a way that meets the above criteria, check out X1 Rapid Discovery (http://www.x1.com/products/x1_rapid_discovery/).

Comments are closed.