OCI Migration Lessons Learnt

MarkBurgessMark Burgess  |  

We made the decision to migrate our hosting environment to Oracle Cloud Infrastructure a little over a year ago. This blog post is a collection of lessons learnt from our OCI migration, along with insights of what we would have done differently with the benefit of hindsight.

OCI Migration Strategy

The scope and approach for the OCI migration was a balance between change v risk/delivery time.

The project had to be delivered under a fixed deadline – any unnecessary change could derail the project resulting in significant financial and compliance costs.

We understood that moving from on-premise to cloud would provide opportunity to change processes and tools used to manage the system.

A complete “lift and shift” approach was taken to minimise change and keep within the project deadlines. The migration alone was a complex project on a tight delivery timeframe. We did not want to introduce additional, unnecessary tasks into the scope that could risk the migration.

In Hindsight: Evaluate high level options to modify tools/processes – particularly operational support systems. In our case we migrated the existing server backup solution “as-is” to cloud to avoid introducing additional change activities during the migration. In hindsight we could have adopted a “cloud native” approach early on that would have reduced post-implementation effort and cost to eventually migrate to a cloud native solution.

Environment Configuration

OCI provides pre-configured templates and utilities that allow cloud infrastructure to be provisioned quickly and easily.

In some cases, you may end up with a configuration that is difficult to adopt to your workload characteristics easily. It is likely you won’t have a detailed understanding of your workload/cost relationship until a few months have passed post-migration. It is at this stage that you may be in a position to change your cloud service configuration or adopt cloud capabilities, but can’t due to constraints imposed by the “one-size-fits-all” provisioning model.

Whilst it may take a little more time up-front, reviewing and understanding the configuration options for your services and how they influence the cost/workload relationship, is an important activity. This will guide you whether a “wizard” generated configuration is suitable, or whether something more bespoke is required.

In Hindsight: Evaluate what pre-configured tools and templates provide and whether the output provides the flexibility required to manage the environment. In some cases it may be beneficial to “build” your own provisioning templates, and then migrate into the built environment. In our case, for our Oracle EBS migration to OCI, we used the Oracle eBusiness Suite Cloud Manager to provide a simple and easy way to provision the cloud environment. After migration we had to “adopt” our on-premise environment configuration or face the expensive re-engineering of our SOP to work with the “new” configuration deployed by EBS Cloud Manager.

Standard Operating Procedures

We had a huge number of standard operating procedures that had to be “migrated” to OCI. These ranged from simple reporting utilities to complex environment cloning and refresh procedures. We took the “lift-and-shift” approach to migrating our procedures as well.

We then spent considerable time and effort “re-engineering” the procedures to work effectively in a cloud environment along with automating complex workflows to be “cloud native”.

Why did we do this the hard way?

We had the sunk cost fallacy around “moving” processes to cloud. Ie..we spent years fine tuning process xyz – how could it possibly be better in cloud?

We had detailed documentation for the processes that had taken considerable time to mature over the years. We didn’t want to “replace” that investment.

In Hindsight: After migrating to cloud and using powerful automation tools on top of cloud services to replace existing tools and procedures we know the following:

  • Seek out to actively replace maintenance tasks and procedures with cloud services where possible during the OCI migration phase.
  • In most cases, a cloud service will exist that can automate or replace existing processes/activities.

The cost saving and efficiency benefits from adopting cloud services AND automation platforms is phenomenal. Taking this approach to your SOP opens up further opportunity to increase the ROI for your OCI cloud migration and reduce ongoing opex .

Adopt “process” automation where possible.

One of the key cloud benefits often heard is the focus on how quick it is to provision in cloud.

This is only part of the story.

OCI provides a massive cost/efficiency multiplier when you automate processes using cloud services + automation tools. Combining OCI capabilities with tools such as Ansible, enables organisations to significantly reduce the time and effort spent operating and maintaining “legacy” SOP.

In addition, OCI allows you to standardise many activities – there is only one way to do most operational tasks. This allows the creation of operational “templates” that can be adopted and enhanced across all environments. Automate your Oracle Database quarterly patch activities once (and remember it’s usually not just running opatch for this), and you can reuse that automation investment repeatedly in OCI.

In Hindsight: Understand the options available to automate process flows in cloud environments particularly around post-provisioning configuration and regular maintenance tasks. For example, if you are migrating Oracle Database to OCI, Oracle Database as a Service provides API endpoints to perform regular tasks such as patching and backups. True efficiency gains are achieved when combining the cloud service capabilities with an automation framework such as Ansible.

The intangiable cost savings are huge.

For us, the tangible cost savings of migrating to OCI were marginal when factoring in the migration project cost.

What we were unable to do until we had completed the OCI migration, was understand the intangible cost savings. These are huge and result from less effort, less people, less management overhead.

We have standardised our provisioning around API’s and one way to do things. This results in significant efficiencies when maintaining and supporting customer systems.

We have significantly reduced the inherent complexity in our environment – this reduces the “knowledge” cost and makes it easier to support.

We have taken the flexibility of cloud provisioning and infrastructure management and added process automation to everything we do. The Ansible playbooks are declarative and relatively easy to understand the purpose and tasks being done. This is a significant departure from complex documentation sets that required regular maintenance to remain current.

In Hindsight: Understanding and accounting for intangible cost savings during the OCI migration planning phase can be very difficult. OCI provides a great foundation to automate tasks that can typically require expensive resources to maintain and execute. With correct implementation, the effort savings can be significant and the benefits are compounding year after year.


Hopefully our lessons learnt help those contemplating the same journey. Whilst the net benefits of the Oracle Cloud Infrastructure migration have been overwhelmingly positive, with the benefit of hindsight there are some things are would have done differently that would have compounded our gains even more.

Looking for help with planning your OCI migration? Get in touch with us today.

About the Author

Leave a comment

Send this to a friend