Oracle Cloud Migration Steps with Low Risk & Maximum Value

Cloud migration of existing IT applications and infrastructure provides opportunities for organisations to save cost, provide greater levels of service and deliver a competitive advantage.

While the migration of certain technologies to cloud services is a no brainer – the migration of large, mission-critical database platforms can be more challenging. The associated planning, reconfiguration for dependent systems, testing and operational setup of the cloud platform can alter the cost/benefit of the whole migration.

In this post, I’ll review the benefits and requirements for Oracle cloud migration of complex, mission-critical databases. Then we’ll look at some practical cloud migrations steps an IT manager can use to deliver low risk, high-value migrations for the organisation.

This is a comprehensive post and here are quick links to the key points.

Contents

• Initial Considerations for Migrating Large Mission-Critical Databases
• High Risk/Low Return
• Cloud Migration Infrastructure Requirements May be Higher
• Cloud Migration Environment Dependencies
• Cloud Migration Benefits
• Firstly, Consider your Cloud Migration Objectives
• A Practical Approach to Could Migration
• Phase 1 – Database & System Backups to Cloud
• Phase 2 – Provision Development/Test Environments
• Phase 3 – Adopting “Cloud Native” Capabilities
• Phase 4 – Enhancing The Hybrid Database Cloud Platform
• Future Possibilities

Initial Considerations When Migrating Large Mission Critical Databases

Database size and downtime windows are two elements that can complicate the migration of a large mission-critical Oracle database to the cloud.

Even though there are database technologies available to support effective migrations (e.g. Oracle Multitenant, Oracle Data Guard, it is the peripheral changes around the database platform that can make the required downtime to the “system” unacceptable.

Some of these issues can be eliminated if there is a compelling reason to re-platform the database. But re-platforming mission critical Oracle systems can be a complex and risky exercise. Even when every endeavour is made to mitigate the risks associated with a move – the larger and more complex the system, the higher the chance of something falling through the cracks.

Also, without an appropriate network infrastructure in place, moving large databases from the corporate data centre to the cloud may be unacceptable from a network stability perspective.

High Risk/Low Return

From a pure business case perspective there can times when the case to move a large system to the cloud https://burgess-consulting.com.au/blog/cloud-migration-considerations-1773/does not add up. At this point weight should also be given to the intangible opportunity cost of not embracing cloud technologies.

Cloud Migration Infrastructure Requirements May be Higher

Depending on the target cloud database deployment, a substantial increase in “infrastructure” – or cloud services may be required to support the database platform workload requirements.

Consolidated on-premise database environments deployed on a common infrastructure platform may have to deploy across multiple cloud services to meet performance or security requirements. This additional cost can increase if there is limited ability to share complimentary workloads across cloud services.

Cloud Migration Environment Dependencies

Mission critical Oracle database platforms typically have a large number of interfaces and systems dependencies. Relocating a core database from on-premise to the cloud may also require substantial effort to reconfigure and test system interfaces. Detailed and tested cloud migration steps are critical to success.

Additional performance and security considerations come to play where co-located on-premise systems now have to interface to databases located in remote data centres. In these cases, the performance and security implications introduced from the cloud migration can outweigh the benefits.

Cloud Migration Benefits

Operations

Repetitive maintenance operations can be drastically reduced when deploying on a database cloud service. Software patching, upgrades and backups can be performed with little to no human effort.

Provisioning

Deploying new database environments or cloning existing environments can be fully automated using cloud native tools. Manual installation and provisioning activities that can take days or weeks to complete on-premise, can be reduced to hours or even minutes.

Functionality

The ability to provision and scale database platforms dynamically with near zero lead time can offer significant benefits.

Data analysis, application testing and ad-hoc reporting requirements can all be accommodated without having to go through lengthy capex approval processes, procurement and provisioning lead times.

Cloud databases can be destroyed when finished reducing the risk and effort associated with decommissioning obsolete environments.

License Cost Optimisation

Database functionality that would typically require a license on-premise and associated costs can be consumed as needed as a service. This can alter the cost/benefit of using certain database features as needed without having to commit to license and ongoing support costs.

We have covered some of the challenges and benefits faced when Oracle databases shift to this new paradigm. Now we can dive into the strategy we adopt for clients migrating complex Oracle databases to the cloud,  while maintaining existing performance, availability and security.

Firstly; Consider your Cloud Migration Objectives

Before we jump into the cloud migration steps, let’s examine some common objectives needed to guide the approach taken.

Incremental Adoption

Effective cloud migration strategy involves incrementally adopting new technologies and procedures into our critical environments. This is to avoid the risks of making large, wholesale changes to our core systems, which are typically too significant to be acceptable.

Concept, Test, Consume Approach

New technology needs to be put through a conceptual evaluation before proper use. It can then be tested for fit to the purpose. Only then can it be embedded into your business’ critical infrastructure and operations.

This approach requires commercial flexibility when using IT resources. We do not want to be locked into lengthy contracts should the solution not meet requirements.

Right-Size Provisioning

You want to make sure that you are consuming the right type and amount of cloud services. You don’t, for instance, want to over-commit and waste money.

You also don’t want to start with too little and find yourself in “bill shock” territory due to unplanned additional spending.

Therefore, it’s important that you discuss your options with either a sales rep of the service you are looking to invest in, or unbiased database consultant before committing to anything.

Remove/Reduce Operational Overhead

We want to adopt new technologies to remove or significantly reduce the operational overhead of running complex Oracle database platforms. Taking advantage of cloud services to perform repetitive, mundane operational tasks is a quick and easy way to deliver immediate cost and efficiency benefits.

Can you Direct Connect your Databases?

It is possible to connect cloud services directly to your on-premise databases. This can be a valid approach for later stages in the cloud journey.

With the goal of incrementally developing a robust hybrid cloud database platform with these cloud migration steps, you could look at direct connect options later in the cloud journey.

Here is what you should consider before you direct connect your on-premise databases:

Security of test environments

Deploying your test and development databases in the cloud using backups removes the need to allow inbound connectivity from your cloud services into your corporate data centre.

However, it can be an extremely complex and time consuming exercise to allow this – particularly network zones hosting the organisations database platforms.

Performance of test environments

For most use cases your application servers should be as physically close to your database servers as possible to reduce latency and maximise performance.

In some uses cases – particularly Integration, BI and mobile applications – connecting these cloud services to your on-premise databases may introduce unacceptable overheads if the network traffic has to traverse multiple network devices and zones.

This problem can be magnified if the cloud services required are located on the other side of the world.

A Practical Approach to Cloud Migration

The following cloud migration steps will provide a progressive path for organisations to adopt the cloud for their large, mission critical systems.

These cloud migration steps will minimise commitment, cost and risk while providing additional benefits that may not be feasible on-premise.

Phase 1 – Database & System Backups to Cloud

Harnessing the benefits of cloud services is the foundation of a cloud strategy. So an effective first cloud migration step will be to make database and system backups available on the cloud.

You can use the example of evaluating cloud storage from a data archival backup solution.

When considering an “on-premise” based data archive strategy we need to consider:

1. Tape archive service providers.
2. Procurement of on-premise tape backup solutions.
3. Restore and recovery SLA.
4. Training and skills for IT teams to implement and operate the technology.

Evaluating cloud storage and backup solutions compared to on-premise solutions can be a useful exercise to evaluate the cost, flexibility and functionality offered with a “cloud mindset” in place.

However, it’s not a good idea to re-architect an existing on-premise backup solution to be exclusively cloud based, or have any operational dependency on the cloud based backups.

What you should do is supplement your existing on-premise backup strategy with a cloud based backup solution. This allows you to test the waters by addressing both the technical and business aspects of data management in the cloud.

Placing database backups in the cloud requires consideration of:

1. Data security requirements for backups that may be stored outside a country’s borders and the potential regulatory and compliance issues this introduces.
2. Tools, methods and procedures to manage cloud platform resources for the target cloud platform.
3. Network connectivity and bandwidth requirements between the corporate data centre and the cloud service provider. If your connectivity requirements are to connect via direct access methods to your cloud service provider and not over public internet then this needs to be considered at this stage as the network costs to cross-connect from non-partner data centres can far outweigh the cloud service cost benefits.

Completing this phase of the journey enables organisations to:

• add value through additional data backup protection
• evaluate the total cost of adopting cloud services into their IT landscape
• minimise up-front commitment costs (cloud storage being one of the cheapest services to consume)
• requires no changes to existing applications and minimal changes to existing operational procedures.

Phase 2 – Provision Development/Test Environments

The ability for an IT organisation to stand-up,tear down, test and develop systems quickly and efficiently can be a major contributor to their ability to innovate product and services.

There are many ways this can benefit the organisation as a whole from lowering risk of system changes to supporting rapid development and test cycles.

While the on-premise technologies are available to easily support provisioning of test/development systems, there needs to be alignment between:

1. The underlying database platform infrastructure to support thin provisioning.
2. Data security compliance requirements – which need to be met when using test environments.
3. The tools and procedures available on the deployed database release.
4. The knowledge and experience which exists within the IT teams – to develop and enhance the database provisioning framework.

When there is not alignment of the above, thin provisioning database environments on-premise may not be possible or the costs may far outweigh the benefits. This in turn limits the organisations ability to innovate.

But, now that we have migrated our database backups to the cloud, we can very quickly and easily stand up test and development environments – without having to develop, implement and test a whole environment to support database thin provisioning.

Oracle Database Cloud Service (DBCS) allows for backups from both on-premise and cloud databases to be used as the source for a DBCS instance. This can be as simple as a single command utility call to provision a copy of your on-premise database in the cloud.

At this point of the cloud migration steps we are utilising higher tier cloud services to deliver greater cost savings and efficiencies. We are somewhat dependent on the new capabilities to support innovation – yet our core systems and data remains on-premise and low risk

The level of lock-in is not high at this stage. If for some reason the expected benefits of adopting cloud based dev/test environments are not realised we can turn them off with no impact to existing business operations.

Phase 3 – Adopting “Cloud Native” Capabilities

Now the organization is comfortable with using the cloud for database backups and provisioning test and development environments we can look to migrate disaster recovery environments..

For some organisations this may be as far as they wish to go on their cloud journey.

However, it is at this point of the cloud migration steps that we believe organisations can truly tap into the value cloud services have to offer – massive scalability, functionality and flexibility at a low entry point or per unit cost compared to standing up the equivalent capabilities on-premise.

Cloud Test Environments Enabling Innovation

We can now look to use cloud native services with our cloud database environments.

There are several uses cases for these databases now that we have them in the cloud.

Business Intelligence (BI)

Cloud native Business Intelligence solutions that may not be technically or financially feasible to implement on-premise can be connected to “cloud native” database environments sourced from on-premise databases.

Integration

Cloud native Integration solutions that require low-latency database access can be connected to replica “cloud native” database copies. This will be useful where an on-premise database is part of an integration chain, but the cost/complexity of providing direct access to the on-premise data outweighs the benefit.

Mobile Application Development

Cloud native Mobile Development platforms can be connected to “real” database copies. This avoids the challenges of data replication and synchronisation.

Cloud native non-production databases can be included in agile development approaches quickly and easily using the available automation frameworks.

Adopting Cloud Native Emerging Technologies

Development of new applications using Artificial Intelligence, Machine Learning and Blockchain technologies can be simplified when development and test databases are hosted with a cloud provider.

Locating on-premise data in the cloud – whether through backup or disaster recovery copies – removes the need to synchronise large volumes of data through replication methods. Cloud based test and development databases facilitate agile development practices by exposing the database environments as “services” alongside other cloud services that form the development environment ecosystem.

An Established Hybrid Cloud

During this cloud migration step, you are using higher value services to augment our organisations data and provide new application and data capabilities.

The cloud database backups and dev/test environments developed in phase 1 and 2 are now essential parts of the operating model. The organisation should be familiar and feel comfortable with working across a hybrid environment, and any implementation issues are worked through and resolved.

We can then start to evaluate whether “legacy” technologies that have become obsolete from our cloud adoption can be decommissioned.

Phase 4 – Enhancing The Hybrid Database Cloud Platform

By now, you should have a mature hybrid cloud operating model and are realising cost benefits by removing obsolete processes and technology from your IT environment.

The next of the cloud migration steps is to evaluate whether “legacy” technologies that have become obsolete in the cloud adoption can be decommissioned.

You can also look at using cloud capabilities to enhance your on-premise systems and business operations.

By using your database backups deployed in Phase 1 and the adoption of native cloud capabilities in Phase 3 – you can re-engineer on-premise business processes to improve performance, cost and quality in ways that would not be possible without adopting cloud technologies.

Enhancing Existing Architecture

Let’s take an example where business users require a complex financial report once a month.

The report generation depends on the completion of the monthly financial period close cycle and the report is scheduled to run over a weekend. It currently takes 36 hours to complete on the on-premise system and is projected to take up to 48 hours with new business acquisitions planned and organic growth.

Failure of the report to run over the weekend can cause up to a 3 day delay in month end financial reporting completion.

Now, your analysis has indicated that Oracle Exadata would achieve the performance requirements for this workload. Testing has shown this report can be optimised to run in 30 mins on the Oracle Exadata having a direct benefit of saving 2 days each month end. However, due to hardware infrastructure refresh plans, this solution can not be considered for another 18 months.

Fortunately, we can use the cloud capabilities that we have built on in earlier cloud migration steps to solve this problem.

Using cloud based database backups we can provision an Oracle Exadata Cloud Service database. The summary data required for our monthly close can be generated on the Oracle Exadata Cloud Service and then copied back to your on-premise system: removing the need to run it over a weekend.

Because we have adopted a “cloud mindset” from the earlier phases of the journey. The Oracle Exadata Cloud Service can be turned on for as long as it is required to run the report. The right sized service is made available, and charged, for only as long as required to solve a specific problem.

Compared to the on-premise world, there would typically be months of planning and approval required for such an investment.

In addition, the on-premise solution would likely have to accommodate the workload for the whole database platform and not just this specific use case – potentially increasing the overall investment substantially.

Future Possibilities

There are many possibilities available when we start integrating our on-premise database platforms with cloud technologies to solve existing business problems.

Migrating database workloads to the cloud can be a major undertaking. But by using existing tools and these tried-and-tested cloud migration steps, provisioning and integrating on-premise databases to a cloud platform can be done incrementaly, with lower risk.

Using these cloud migration steps to adopt cloud technologies can create a solid foundation by improving agility and scalability thus preparing your business for future success.