AWS this week announced a new service to streamline application server migration to the cloud. The AWS Application Migration Service is an evolved version of their existing CloudEndure offering with some nice enhancements for manageability and auditability. My first reaction to the announcement, as an experienced Oracle licensing professional, is that this will benefit many organizations greatly in accelerating their cloud journey and also lead to potentially horrible outcomes the next time they get caught in a license audit by a software vendor.
Why Lift and Shift Tools Change Instance Size
Services such as CloudEndure and Application Migration Service are very useful but organizations need to be aware of the limitations of these tools and the possible bad outcomes. I tend to refer to these tools as naive lift and shift engines. They simply take existing workloads in an existing datacenter and attempt to translate them as faithfully as possible to the AWS EC2 environment. Often these tools can’t find an EC2 instance shape that exactly matches the originating server or virtual machine, so they find the closest possible instance shape unless a human operator manually specifies an instance shape. The net result is that systems migrated via these tools often end up with a bit more or less resources in terms of virtual CPU (vCPU) or RAM. For most applications these slight resource adjustments make no practical difference and can be disregarded. For software that uses these resources as a licensing metric there are potentially catastrophic outcomes for licensing compliance.
How vCPU Licensing Turns a Resize into a Compliance Gap
Many software vendors license software based on a vCPU metric in the cloud, and some of those vendors also have cloud licensing rules that differ substantially from their licensing rules in on-premises datacenters. Using a naive lift and shift engine to migrate a physical server or virtual machine containing software licensed on a vCPU basis will very frequently result in the migrated cloud instance not being in license compliance.
A 2 vCPU Oracle VM That Came Out with 4
To illustrate, I’ll relate an example from a client I worked with a few years back. They were keen to use CloudEndure to perform mass migrations as part of a datacenter evacuation. Several pilot test cases were utilized and one of them was a non-production vSphere VM that hosted an Oracle Database Enterprise Edition workload. The VM in question had only two vCPUs but a generous helping of RAM as databases are notoriously memory hungry.
When the Extra vCPUs Show Up in an Audit
CloudEndure migrated the workload successfully which was unsurprising as it’s a high-quality tool. I was the only one to be alarmed by the resulting migrated workload, as I noted that the migrated platform now had 4 vCPUs instead of 2. As vCPUs are a licensable metric for Oracle software this meant that the naive migration tool had created a licensing liability that the client probably wouldn’t have noticed until the next audit. While this was just a pilot test case and the client had sufficient license to cover this pilot use case, I have talked with organizations that didn’t realize their lift and shift cloud migration tools had caused them massive software licensing liabilities until the Oracle license auditors presented them with a bill.
Review Licensing Before You Migrate
Migrating to the cloud is a great idea. Tools like AWS Application Migration Service are a great idea for easing migration efforts. Performing a cloud migration without a thorough understanding of software licensing implications is a terrible idea and a recipe for disaster. I implore any organization thinking of a cloud migration to consider retaining expert help in order to ensure that the migration is truly beneficial from a total cost of ownership perspective and doesn’t contain expensive budget-destroying hidden licensing liabilities.
Before you size the target platform, model your licensing there.
