Cloud migration projects have a consistent and frustrating pattern of costing significantly more than the business case projected. The infrastructure cost of the destination cloud environment is usually modelled reasonably well. The cost of the migration project itself, including the implementation partner fees, the testing effort, and the cutover management, is typically included at some level. What is consistently underestimated, and in many cases entirely absent from the initial business case, is the licensing cost of the migration itself and the licensing changes that the migration creates in the on-premises estate.
These hidden licensing costs do not require unusual circumstances to materialise. They are structural features of how enterprise software licensing works that become commercially visible at the moment of cloud migration, even though the underlying licensing mechanics have been present and documented throughout. The problem is not that these costs are secret. It is that they sit in a different conversation from the one that cloud migration teams typically have, and they require licensing expertise to identify and quantify that most cloud infrastructure projects do not include on the team.
This blog examines the most significant hidden licensing costs across the major vendor categories, why they consistently derail cloud migration business cases, and what organisations can do to surface them before they become unexpected expenses.
Oracle: The Cloud Migration Licensing Trap
Oracle database cloud migrations generate licensing complications that organisations consistently underestimate. The first and most important is understanding how Oracle’s licensing rules differ between on-premises virtualised environments and authorised public cloud platforms, because these are treated very differently and confusing them is one of the most common and costly mistakes in Oracle cloud migration planning.
On-premises, Oracle does not recognise most hypervisors including VMware vSphere and Microsoft Hyper-V as valid mechanisms for limiting processor licence counts. This is Oracle’s published soft partitioning policy. When Oracle database software runs in a VMware cluster, Oracle’s position is that every physical host in the cluster must be licensed, regardless of how many virtual machines are actually running Oracle. A cluster with ten hosts, each with 16 cores, requires all 160 cores to be licensed for Oracle if any one of those hosts could run Oracle under VMware. This is the on-premises soft partitioning problem that organisations migrating from VMware need to address or carry into cloud.
In contrast, Oracle has published an Authorised Cloud Environments policy that covers AWS, Azure, and Google Cloud specifically. Under this policy, Oracle permits BYOL deployment on standard cloud virtual machine instances, with licences counted based on the number of vCPUs assigned to the instance using a 2 to 1 conversion ratio: two vCPUs equal one Oracle processor licence. This is significantly more favourable than the on-premises soft partitioning rule and is why public cloud migration can, in some cases, actually reduce Oracle licence counts compared to a VMware on-premises deployment. The commercial risk arises when organisations are unaware of the specific rules, exceed the vCPU counts their licences cover as they resize cloud instances, or deploy Oracle across multi-node configurations or container orchestration platforms in ways that fall outside the Authorised Cloud Environments policy and reintroduce complexity. Oracle Cloud Infrastructure uses its own OCPU-based model with direct BYOL provisions, eliminating the cluster-wide licensing problem entirely, which is one of the genuine commercial arguments for OCI for Oracle database workloads.
Deloitte’s cloud migration advisory practice publishes research on the commercial and licensing dimensions of enterprise cloud migrations, including the Oracle licensing complexities that most commonly generate unexpected cost in migration programmes. Their Deloitte cloud migration commercial planning and licensing research address the licence assessment work that should precede any Oracle database cloud migration, covering the core factor analysis, sub-capacity eligibility assessment, and the total licensing cost calculation that belongs in every Oracle cloud migration business case.
Microsoft: The Parallel Running Cost Nobody Budgets For
Microsoft cloud migrations, particularly those involving SQL Server on-premises to Azure SQL migration, create a parallel running cost that is often absent from migration business cases. During the migration and validation period, both the on-premises SQL Server environment and the Azure SQL environment are operational simultaneously. If the on-premises SQL Server is covered by Software Assurance, the Azure Hybrid Benefit provisions allow the Azure SQL cost to be reduced. However, the on-premises SQL Server support cost continues during the parallel running period, and the Azure SQL consumption cost is incurred in addition to it.
The duration of the parallel running period is consistently underestimated in migration planning. Complex SQL Server environments with significant stored procedures, dependencies on specific SQL Server features, and integration with surrounding applications typically require months of testing and validation before the cutover from on-premises to cloud is safe to execute. A parallel running period of three to six months is not unusual for complex migrations. For large SQL Server estates, the incremental cost of that parallel running period can be substantial.
Microsoft 365 migrations from on-premises Exchange and SharePoint to cloud equivalents create a similar dynamic. User mailboxes must be migrated in batches while the hybrid environment that supports both on-premises and cloud users remains operational. The hybrid environment licensing, the migration tooling cost, and the operational overhead of running a hybrid Microsoft 365 environment all add to the total migration cost in ways that are rarely fully captured in the business case.
SAP: The Custom Code and Add-On Licensing Dimension
SAP cloud migrations, whether to Rise with SAP or to S/4HANA on OCI, generate hidden licensing costs through two specific mechanisms that are consistently underestimated.
The first is the custom code rationalisation requirement. Most mature SAP on-premises environments carry substantial custom ABAP code developed over many years. Moving this code to the cloud environment requires technical review, compatibility assessment, and in many cases rewriting to conform to the clean core requirements of the cloud deployment. The licensing cost here is not direct, but the project cost of the code rationalisation work is often significantly larger than initial estimates, and the timeline of the migration project is directly determined by how long the code rationalisation takes. Projects that underestimate this scope consistently run over time and budget.
The second mechanism is the SAP add-on licence gap. The Rise with SAP bundle covers a specific set of SAP products. Organisations that are currently running SAP add-ons outside the bundle, including products like SAP SuccessFactors, SAP Ariba, SAP Concur, or SAP Analytics Cloud, need separate commercial arrangements for these products that are not included in the Rise with SAP subscription. Discovery conversations with SAP during the commercial evaluation phase of Rise with SAP adoption do not always surface these gaps comprehensively, and they emerge as additional cost items when the migration reaches the detailed scoping phase.
Computer Weekly covers SAP cloud migration commercial developments and the specific licensing and cost dimensions that organisations encounter when moving from on-premises SAP to cloud deployment models. Their Computer Weekly SAP cloud migration commercial and licensing coverage provide independent analysis of the hidden cost patterns in SAP cloud migrations, drawing on real-world deployment experience that helps organisations build more realistic business cases for Rise with SAP and related cloud migration programmes.
IBM: The ILMT Gap in Container and Cloud Environments
IBM cloud migrations create a specific and often poorly anticipated licensing cost through the ILMT coverage gap. IBM’s sub-capacity licensing, which allows organisations to licence IBM software based on the processor capacity actually allocated to IBM software rather than the full physical host, depends on the deployment and continuous maintenance of IBM License Metric Tool. ILMT must be correctly configured and producing valid sub-capacity measurements for the sub-capacity licensing entitlement to be valid.
When IBM workloads are migrated to cloud or container environments, the ILMT configuration that was adequate for the on-premises environment frequently does not automatically cover the new cloud or container deployment. IBM Cloud Pak workloads in Kubernetes or OpenShift environments require IBM License Service rather than ILMT, and the configuration of ILS for complex, multi-cluster container environments is not trivial. Organisations that migrate IBM workloads to cloud or container environments without first verifying that their IBM measurement tool coverage extends to the new environment are creating a sub-capacity licensing gap that IBM can identify and use as the basis for a compliance finding.
The Data Egress Cost That Appears After Migration
One of the most consistently overlooked cloud migration cost categories is data egress. Moving data out of a cloud environment, whether to on-premises systems, to a different cloud, or to customers or partners, incurs charges from every major cloud provider that are not incurred in on-premises architectures. For applications with significant data movement requirements, particularly analytics workloads that pull large data volumes to on-premises BI tools, integration platforms that move data between cloud and on-premises systems, and customer-facing applications that serve large data payloads, egress costs can be substantial and are frequently absent from cloud migration business cases because they are not visible during the technical architecture assessment phase.
DATAVERSITY covers enterprise data architecture and the commercial implications of data movement costs in hybrid and cloud environments. Their DATAVERSITY enterprise data architecture and cloud migration cost research address the data egress cost dimension of cloud migration planning, including the architectural approaches that minimise egress cost and the data governance framework changes that organisations need to make when their data architecture transitions from on-premises to cloud environments.
What to Do: Building a Complete Migration Business Case
The practical response to the hidden licensing cost problem is straightforward in principle and demanding in practice. Before any cloud migration business case is finalised and approved, it needs to include an explicit licensing cost model that covers the parallel running period, any changes in the licence metric that result from the migration, any software entitlements that need to be acquired or expanded to support the cloud deployment, any licence measurement tool reconfigurations required, and any add-on product gaps in cloud bundle coverage. This licensing cost model should be produced by someone with genuine expertise in the specific licensing mechanics of the vendor whose software is being migrated, not by the cloud infrastructure team or the implementation partner whose primary expertise is in cloud architecture.
The World Commerce and Contracting association publishes research on cloud migration commercial governance and the contract management practices that prevent hidden licensing and commercial costs from derailing migration programmes. Their WorldCC cloud migration commercial governance and contract management research provide frameworks for building the commercial oversight of cloud migration programmes that surfaces licensing cost dimensions before they appear as unplanned expenses during execution.
Conclusion
The hidden licensing costs that derail cloud migrations are not truly hidden. They are the predictable consequences of well-documented licensing mechanics applied to a new deployment context, and they are entirely avoidable with the right expertise at the right stage of the migration planning process. Organisations that invest in licensing expertise as part of their cloud migration team, rather than treating licensing as a post-migration compliance concern, will produce more accurate business cases, execute migrations with fewer commercial surprises, and achieve better total cost of ownership outcomes than those who discover these costs during execution.
