Nick Walter, Principal Architect

The Licensing Trap

In my role with House of Brick, I get the opportunity to assist many of our clients with migrating their business-critical databases to the public cloud.  While every client and every migration plan is unique, I’ve observed a trend of common mistakes or misconceptions about the process of migrating to the cloud that occur again and again among my clients.  Lately, I’ve taken to reviewing these common pitfalls right at the beginning of migration planning, which has been successful in preventing my clients from experiencing issues that slow down or derail cloud migration plans.  I thought it would be negligent not to share all these issues with readers of our House of Brick blog, so today I present the third blog in my series on common database cloud migration pitfalls.

In part three, the topic is licensing for enterprise database products.  For various reasons, the customer-centric, enterprise database providers such as Oracle and Microsoft have made licensing their database software in public cloud environments more confusing than it needs to be.  Microsoft just this week took flak for “clarifying” that on-premises licenses can’t be migrated to dedicated hosts in the cloud.  Even more concerning, Oracle is notorious for creating a deliberately nebulous environment of confusion and fear around their licensing.  Both providers, of course, provide exceptions or better terms for customers willing to migrate licenses to their own cloud offerings.

Going into a long description of the specific licensing rules for SQL Server and Oracle databases in public cloud environments is beyond the scope of this article, but I do want to talk about the licensing traps that I’ve seen clients fall into during their cloud migrations.

Consider Licensing Implications
The first licensing trap that most organizations fall into is not realizing that they need to carefully consider the licensing implications of migrating to the cloud.  For just about any enterprise database platform, the licensing rules for public clouds differ markedly from on-premises licensing, so careful study is required to inform the migration plan and avoid costly licensing mistakes.  A good cloud migration plan should feature a study of licensing implications for any commercially licensed software on the servers being migrated, and the results of that study should inform the rest of the plan.  In particular, I urge all clients to look into potential differences in licensing metrics between on-premises deployments and public cloud deployments, as well as any explicit or implicit irrevocable license conversion that may be occurring as part of a move to the cloud.  For example, Oracle’s published document Licensing Oracle Software in the Cloud Computing Environment changes the metrics from physical core to virtual CPU licensing, and also requires twice as many licenses per process core as on-premises deployment.  As a result, organizations that overlook that change in a cursory reading tend to find themselves very license deficient after a cloud migration.

Understand the Exact Changes
The second licensing trap is not understanding the exact changes that will be introduced to migrated servers by the migration tools being used.  Regardless of whether a server migration is done by hand, by reinstalling applications, by automated conversion tools such as CloudEndure, or another method, it’s important to look at the post-migration state of the systems when calculating licenses (not the pre-migration state).  I’ve seen plenty of clients land in hot water licensing wise despite a very solid migration plan, because they didn’t realize that the staff doing the hands-on work of migrating a server decided to add six duplicate copies of a cloud instance for testing during migration, or that CloudEndure would increase the number of vCPUs in a VM during migration.  Therefore, it is critical to understand what the post-migration state of the servers will be, and to not only consider that state during migration planning, but also to circle back to the topic during (and after) the migration to compare the planned cloud estate with what actually exists.  Too often admins, put on the spot during a rushed migration project, make tactical decisions to keep things moving that end up having considerable licensing implications.  Building sanity check steps into a cloud migration plan to catch these issues and address them prior to a software licensing audit can save an organization from significant costs down the road.

Educate Your Users
The third trap that many organizations fall into is simply a failure to educate their users on all the implications of the first two traps.  Even one administrator, with the power to launch new cloud instances or duplicate existing ones, can inadvertently create a massive licensing liability if they are unaware of the licensing constraints around the software in a virtual instance.  Traditional procurement and change control processes, which have gated acquisition of new servers or new deployments and prevented these kinds of mistakes in an on-premises world, are usually insufficient after a public cloud migration.  For example, I’ve personally witnessed an administrator upscaling an AWS EC2 instance from m5.large to c5.5xlarge “just to try it” (on a temporary basis) after receiving performance complaints.  Since it was a temporary change, for a few hours in a non-production environment, and in response to a user-reported issue, the administrator did not feel the need to go through any change control process.  While that’s a reasonable troubleshooting approach, this particular instance had licensed database software installed and the move from a two-vCPU m5.medium to a 16-vCPU c5.9xlarge immediately introduced 14 vCPUs of additional licensing liability.  I could list several similar examples, but I trust the point has been sufficiently made.  Having a solid licensing plan is not sufficient, it must be coupled with communication and educating administrators who have the power to alter any aspects of the systems that relate to licensing metrics.  Only when all such administrators are fully on board with the licensing plan and its constraints, and instances have been appropriately tagged to avoid surprises, can this trap be fully avoided.

Conclusion
In the end, an IT organization that takes all of these traps into account can avoid experiencing expensive licensing deficiencies as part of their cloud migration.  I strongly advocate that all organizations looking into large-scale cloud migrations consider not only their licensing needs for commercial software, but also whether a cloud migration represents a good opportunity to consider consolidating or eliminating costly software that isn’t cloud friendly.