Why Oracle Cloud Migrations Fail — and How to Prevent It
Oracle cloud migrations have a structural failure pattern that Redress Compliance observes repeatedly across enterprise engagements: the technical migration team focuses on infrastructure lift-and-shift, the commercial team focuses on cloud platform pricing, and the licensing dimension — which determines whether the migration creates compliance exposure — is addressed after migration completion, if at all. This sequencing error is the root cause of most Oracle cloud migration budget overruns and post-migration audit findings.
The 20 checks below address all three dimensions — technical, licensing, and operational — in the order they should be validated in a pre-migration readiness assessment. Any item rated High Risk that cannot be confirmed as compliant before migration should trigger a hold on the migration timeline until the issue is resolved or a documented risk acceptance decision is made at appropriate authority level.
Complete this checklist before committing to cloud platform selection, contract signature, or migration project initiation. High Risk items that fail indicate migration-blocking issues. Medium Risk items require mitigation planning. Low Risk items are governance hygiene checks that improve long-term compliance posture.
01Has a complete Oracle software inventory been produced — covering all Oracle Database instances, editions, versions, Options, Packs, and Middleware — across all environments including development, test, and staging?High Risk
Expert NoteA complete Oracle software inventory is the non-negotiable foundation of any cloud migration readiness assessment. Development, test, and staging environments are frequently omitted from migration scope — but Oracle licences cover all environments unless Oracle has explicitly granted a restricted licence, and non-production Oracle deployments in cloud create BYOL requirements identical to production. The inventory must capture: product name, edition, version, Options and Packs in use (from DBA_FEATURE_USAGE_STATISTICS), licence metric (Processor or NUP), and the server or VM hosting each instance. Redress recommends using Oracle LMS scripts — not Oracle's scripts, which may be used to extend Oracle's audit rights — supplemented by independent SAM tool discovery.
02Has the current Oracle virtualisation topology been documented — including VMware cluster boundaries, vMotion scope, DRS settings, and any existing hard partition configurations — as it determines the baseline BYOL licence requirement?High Risk
Expert NoteThe on-premises virtualisation topology determines the current licence requirement, which in turn determines whether cloud BYOL will create a surplus or deficit. An enterprise running Oracle on a shared VMware cluster — where soft partitioning applies — may be licensing all physical processors in the cluster, which represents a large licence pool that can be applied to cloud BYOL. Alternatively, an enterprise running Oracle on a hard-partitioned environment may have a smaller licence pool that limits cloud BYOL capacity. Documenting the virtualisation topology as-is, and understanding what the post-migration on-premises topology will look like, is essential before determining BYOL availability.
03Have Oracle Database versions been assessed for cloud platform compatibility — particularly for Oracle Database versions 11g and 12c, which may require upgrade before migration to managed cloud services?Medium Risk
Expert NoteOracle Database 11g (11.2) is not supported on most cloud managed database services and requires significant testing for compatibility with cloud infrastructure libraries. Oracle Database 12c Release 1 (12.1) has limited cloud managed service support. A migration plan that assumes version equivalence between on-premises and cloud Oracle Database is a common planning error — enterprises frequently discover version incompatibilities during migration testing, adding months to migration timelines. Conduct a version compatibility assessment for every Oracle Database instance against the target cloud service specification before finalising the migration architecture.
04Has Oracle E-Business Suite, JD Edwards, PeopleSoft, or Siebel application compatibility with the target cloud environment and Oracle Database version been validated against Oracle's cloud certification matrix?Medium Risk
Expert NoteOracle application suite compatibility with cloud environments is governed by Oracle's certification matrix — a frequently updated document that specifies which application versions are certified on which Oracle Database versions and which cloud platforms. Oracle EBS R12.1 on OCI, for example, has specific certification requirements including Oracle Database version, WebLogic version, and OCI shape family. Migrations of Oracle application suites without reference to the certification matrix routinely encounter post-migration support issues, where Oracle refuses to provide support for uncertified configurations. Validate every Oracle application against the certification matrix before finalising cloud architecture.
Is your Oracle cloud migration technically and commercially ready?
Redress Compliance conducts pre-migration Oracle readiness assessments — covering licensing, architecture, and governance in a single engagement.05Has a BYOL entitlement analysis been completed — confirming that sufficient perpetual licences with active support exist to cover all Oracle Database and Middleware deployments in the target cloud environment?High Risk
Expert NoteBYOL entitlement analysis is the most frequently skipped step in Oracle cloud migration planning, and the most consequential omission. An enterprise that migrates Oracle Database to AWS or OCI without confirming that its on-premises perpetual licences cover the cloud deployment is running unlicensed Oracle software from day one of migration. The BYOL analysis must confirm: sufficient processor licence count for the target cloud instance vCPU/OCPU count, active Oracle support on all licences being applied, edition matching between on-premises licences and cloud deployment, and Options and Packs coverage for all features enabled in the cloud. This analysis should produce a written BYOL entitlement statement signed off by the Oracle licensing lead before migration commences.
06If the organisation holds an active Oracle ULA, has the ULA scope been reviewed to determine whether cloud deployments are within ULA scope — and has Oracle account team confirmation been obtained in writing?High Risk
Expert NoteULA cloud scope is the single most litigated Oracle licensing question in cloud migrations. Most ULAs exclude cloud deployments from scope unless explicitly negotiated otherwise. An enterprise that migrates Oracle workloads to cloud during an active ULA, assuming the ULA covers cloud, is creating post-certification exposure that Oracle will pursue aggressively. Written confirmation from the Oracle account team that cloud deployments are within ULA scope is necessary but not sufficient — it must be backed by explicit ULA agreement language. Have the ULA agreement language reviewed by an independent Oracle licensing specialist before proceeding.
07Has the post-migration on-premises Oracle licence position been modelled — including what licences are released by migrating to cloud, and whether released licences create compliance gaps for remaining on-premises workloads?High Risk
Expert NoteCloud migration typically reduces on-premises Oracle deployment but does not automatically reduce licence requirements if shared virtualisation environments remain. An enterprise that migrates a subset of Oracle VMs from a VMware cluster to cloud may still need to licence all physical processors in the on-premises cluster for the remaining Oracle VMs. The post-migration on-premises position must be modelled before migration to avoid a scenario where cloud BYOL licences are applied, but on-premises compliance gaps remain. This model must cover: remaining on-premises Oracle deployment, virtualisation topology changes post-migration, and available licence pool after BYOL assignment.
08Has Oracle Java SE deployment in the target cloud environment been assessed — including whether Java instances in cloud are covered by existing Oracle Java SE Universal Subscriptions or require additional subscription?Medium Risk
Expert NoteOracle Java SE Universal Subscription is an employee-based metric that covers all Java deployment globally regardless of platform — meaning Java in cloud is covered by the same subscription as on-premises Java. However, enterprises without a current Java SE Universal Subscription that deploy Java in cloud environments must purchase the subscription based on total employee count. A cloud migration that introduces additional Oracle JDK instances — through application server deployments, automated tooling, or container images — without a Java SE subscription creates exposure. Audit Java deployment in the target cloud environment as part of migration readiness, and confirm Java SE subscription coverage or purchase requirements.
09Has Oracle Cloud Infrastructure (OCI) been formally evaluated against AWS, Azure, and GCP — including the financial impact of OCI Support Rewards — before cloud platform selection is finalised?Medium Risk
Expert NoteOCI is systematically under-evaluated in cloud platform selection decisions for Oracle workloads, because cloud architects frequently apply hyperscaler-first assumptions without modelling OCI's Oracle-specific financial advantages. OCI Support Rewards can reduce Oracle annual support spend by 25–33% of OCI BYOL usage — a benefit that can add £200,000–£800,000 annually in support savings for a large Oracle estate, making OCI substantially cheaper on a total cost basis than AWS or Azure even if infrastructure costs are comparable. Any Oracle cloud migration plan that excludes OCI from evaluation without explicitly modelling Support Rewards has not been properly assessed.
10For workloads migrating to OCI, has the target OCI shape been selected and validated against Oracle BYOL requirements — including OCPU count, shape family, and whether Bare Metal or VM deployment is required?Medium Risk
Expert NoteOCI shape selection is both a performance and a licensing decision. The OCPU count of the target OCI shape directly determines the processor licence requirement under BYOL (2 OCPUs per processor licence for EE). OCI Bare Metal shapes require full socket licensing under Oracle's physical server rules, not the 2-OCPU BYOL rule, making Bare Metal substantially more licence-intensive than equivalent VM shapes. OCI Flexible shapes (VM.Standard.E4.Flex, VM.Standard3.Flex) allow OCPU count to be set to the minimum required for the workload, enabling BYOL optimisation. Select OCI shapes in conjunction with BYOL licence modelling rather than purely on performance specifications.
11Has Oracle Exadata Cloud Service or Exadata Cloud@Customer been evaluated for database-intensive workloads, and has the Exadata BYOL pricing model been compared against standard VM-based BYOL deployment?Low Risk
Expert NoteOracle Exadata Cloud Service offers a unique BYOL model where Oracle provides a credit against the cloud service charge for each processor licence applied under BYOL — creating a different financial calculation than standard VM-based BYOL. For database-intensive workloads where on-premises Oracle Database licence volumes are high, Exadata Cloud BYOL can produce better economics than standard OCI VM BYOL, particularly when combined with Support Rewards. Exadata Cloud@Customer — which deploys Exadata infrastructure in the customer's data centre, managed by Oracle — provides OCI-equivalent BYOL and Support Rewards benefits while maintaining data residency for regulated workloads.
12For containerised Oracle Database deployments (Kubernetes, OpenShift), has the Oracle Database operator licensing model been reviewed — Oracle's container licensing follows the host node processor model, not the container CPU model?High Risk
Expert NoteOracle Database in containers is among the most misunderstood Oracle licensing scenarios in cloud migrations. Oracle does not recognise container CPU limits or Kubernetes resource quotas as hard partitioning — meaning Oracle requires licensing of all physical or virtual processor cores on the Kubernetes node running the Oracle Database container, regardless of the container's CPU limit setting. This is identical to the VMware soft partitioning rule applied to containers. An enterprise that deploys Oracle Database in a shared Kubernetes cluster with a 4-CPU container limit, believing it requires only 2 processor licences, must actually licence all processors on all nodes the container can be scheduled to — potentially 10–50× more licences. Oracle container deployment requires either dedicated node pools or OCI, which has specific container licensing provisions.
13Has Oracle Cloud support (Premier Support, Extended Support) for all Oracle products being migrated been confirmed — and has the Oracle support boundary between Oracle-managed cloud services and customer-managed BYOL been documented?Medium Risk
Expert NoteOracle cloud support boundaries are frequently misunderstood by enterprise IT teams. For Oracle Cloud managed services (Oracle Autonomous Database, Oracle Database Cloud Service with managed option), Oracle provides infrastructure and database-level support. For BYOL deployments on OCI, AWS, or Azure, Oracle provides software-level support (fixing bugs in the Oracle software) but not infrastructure support — the cloud provider supports the infrastructure. This boundary matters when diagnosing issues: Oracle Support may decline to investigate problems that could be infrastructure-related, requiring the customer to engage both Oracle Support and the cloud provider. Document this boundary in the operations runbook before migration.
14Have Oracle Database backup, recovery, and business continuity requirements been validated against cloud-native capabilities — including RPO/RTO targets, backup retention policies, and cross-region failover architecture?Medium Risk
Expert NoteOracle Database backup and recovery in cloud requires careful architecture to meet enterprise RPO/RTO requirements. Oracle Recovery Manager (RMAN) is available in cloud BYOL deployments and can integrate with cloud object storage (OCI Object Storage, AWS S3, Azure Blob). Oracle Data Guard for high availability requires Active Data Guard licences for read-active standby configurations. Oracle GoldenGate for zero-downtime migration is separately licensed and must be included in BYOL or cloud subscription planning. Map every backup, recovery, and HA Oracle product against the cloud architecture before finalising the design.
15Have Oracle Database performance baselines been established on-premises — AWR reports, ASH data, wait event profiles — to enable meaningful post-migration performance validation in cloud?Low Risk
Expert NotePost-migration performance validation requires on-premises baselines for meaningful comparison. Without AWR and ASH baselines from on-premises production, it is impossible to objectively determine whether cloud performance is equivalent, better, or worse. Oracle AWR data collection uses the Diagnostics Pack — confirming that Diagnostics Pack is already licensed is a prerequisite for using AWR as a migration baseline tool. Export AWR snapshots from at least 30 days of on-premises production operation before migration, covering peak and off-peak periods. These baselines are also valuable for Oracle BYOL compliance validation, as they document which database features were in active use on-premises.
16Has monitoring and alerting for cloud Oracle Database deployments been designed — including Oracle Enterprise Manager integration, cloud-native monitoring, and BYOL licence consumption tracking?Medium Risk
Expert NoteOracle Enterprise Manager (OEM) can monitor Oracle Database deployments in cloud BYOL environments, providing licence management plugin functionality for tracking Options and Packs usage via DBA_FEATURE_USAGE_STATISTICS. OEM itself requires Oracle Database licences for its repository database. Cloud-native monitoring (OCI Monitoring, AWS CloudWatch, Azure Monitor) can supplement OEM for infrastructure-level visibility. The critical monitoring requirement specific to BYOL is licence consumption tracking: as cloud instances scale, the processor licence consumption changes, and monitoring must alert when consumption approaches the BYOL entitlement ceiling. This alert should trigger before auto-scaling events exceed available BYOL.
17Has a migration risk register been created that explicitly captures Oracle licensing risks, BYOL calculation assumptions, and the commercial consequences of each risk materialising?High Risk
Expert NoteOracle licensing risks in cloud migration are rarely captured in migration risk registers — they are treated as a separate workstream or deferred to post-migration review. This separation creates the conditions for ungoverned migration decisions that create compliance exposure. The migration risk register should include: BYOL entitlement shortfall risk and its financial exposure, ULA scope uncertainty and its resolution timeline, on-premises compliance gaps that migration may expose, and auto-scaling licence consumption risk in production. Each risk should have an owner, a mitigation plan, and a residual risk acceptance threshold. This register should be reviewed at every migration steering committee.
18Has the Oracle account team been formally engaged on the migration plan — including written notification of cloud deployment intent and documentation of Oracle's response to BYOL applicability questions?Medium Risk
Expert NoteEngaging Oracle's account team on migration plans is both a commercial and a compliance risk management step. Oracle's account team will use migration notification as an opportunity to promote Oracle cloud and to identify any licence compliance concerns — both commercially motivated. However, formal engagement also creates a documented record that Oracle was informed of the migration intent. Written Oracle account team responses to BYOL applicability questions — even if those responses are commercially motivated — create an evidentiary record that can be useful if Oracle later disputes the BYOL claim. All Oracle account team communications about BYOL should be documented and retained.
19Has a post-migration Oracle licence review been scheduled — within 90 days of migration completion — to validate that actual cloud deployment matches the pre-migration BYOL entitlement analysis?Medium Risk
Expert NotePost-migration licence reviews are the most effective tool for identifying and remediating BYOL compliance gaps before Oracle's GLAS team does. Cloud migrations invariably produce a deployment that differs from the pre-migration plan: instance types change, additional environments are spun up, Options are enabled that were not planned. A 90-day post-migration review — comparing actual cloud Oracle deployment against the pre-migration BYOL entitlement analysis — identifies these gaps while remediation is straightforward. This review should be conducted by an independent Oracle licensing specialist, not by the migration team or Oracle's account team.
20Has an independent Oracle licensing specialist — separate from the cloud platform vendor and Oracle's own team — reviewed the complete migration plan for licensing compliance before migration commencement?Low Risk
Expert NoteCloud platform vendors (AWS, Microsoft, Google, Oracle itself) provide migration planning assistance as a commercial service — they are not independent sources of Oracle licensing guidance, and their migration assessments do not carry liability for licensing compliance errors. An independent Oracle licensing review — conducted by advisers with no commercial interest in the cloud platform selection — provides the only objective validation of BYOL eligibility, Options and Packs coverage, and ULA treatment. The cost of an independent review (typically £15,000–£40,000 depending on estate complexity) is a rounding error compared with the commercial exposure of a post-migration Oracle audit finding, which routinely exceeds £1M for enterprise estates.
Proceeding with Confidence
A cloud migration readiness assessment that addresses all 20 checks does not delay migration — it accelerates it by identifying and resolving issues before they create migration-blocking surprises. The enterprises that move fastest to cloud with Oracle workloads are those that front-load the licensing and governance work: they know their BYOL position, they have selected the right cloud platform for their Oracle estate, and they have a post-migration governance model that prevents compliance drift.
Organisations that skip the readiness assessment do not move faster — they move into a cloud environment with hidden compliance exposure that Oracle's GLAS team will surface on its own timeline, creating commercial disruption at the worst possible moment.
Download the Oracle Cloud Migration Assessment Guide →