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
One 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.