Learn About Migrating Application Data to the Cloud

Your organization may use applications that support a wide range of business functions, from traditional back-office processes to business-critical manufacturing, supply-chain and customer-facing applications. If you're considering moving application data from on-premises to Oracle Cloud, assess what data needs to be transferred to the cloud, understand the available data storage options in Oracle Cloud Infrastructure, and select an appropriate data transfer method.

You can migrate your application data to Oracle Cloud Infrastructure with minimal re-architecture, re-integration or business process changes, and will result in a solution that is more flexible, more reliable, and delivers higher performance at a lower cost than deployments running on-premises or with other cloud providers.

Benefits of Moving to the Cloud

Oracle Cloud Infrastructure offers unique services, infrastructure capabilities, tools, and support that are optimized for migrating applications and its data from your on-premises to the cloud.

There are significant performance benefits when you run your applications on Oracle cloud.
Oracle Cloud Infrastructure provides enterprise grade security at every level of the stack, to ensure user isolation, data encryption at every stage of the life cycle, fine-grained security controls, compliance, and visibility through comprehensive log data and monitoring solutions.
Oracle offers the most comprehensive database migration services in the industry, so there will be one that exactly matches your requirements.

However, your strategy for moving your on-premises applications and its data to the cloud depends on your environment, customized configurations, and the applications that use your data sources.

Identify Application Components

When you move an application, it's important to identify all of its components, especially if you plan to update how the data is structured. Applications have four basic components: clients, software, connectivity, and data.

Clients: Before you move the application, answer the following key questions:

Who are all the clients that use this application?
What kind of access does each client need for this application?
Do the power users have different access requirements than normal or report-only users?

Building a matrix of the users and their requirements helps to architect the application move.

Software: What software is required for the system to work? Identify whether the application has any middleware or database requirements. Be sure to list all the basic requirements for the application. This move might also be an opportunity to either scale up or scale down the application.

Connectivity: Identify the connectivity requirements, and understand what the access requirements will be:

Is latency currently an issue for this application? If so, what is the latency threshold?
Has the connection to Oracle Cloud Infrastructure FastConnect, traffic over the internet, or an IPSec tunnel over the internet been identified?
How much bandwidth does the application require?
Will the clients be making round trips with the data or is it all going to be used and stored in Oracle Cloud Infrastructure?
Are there special VPN or VCN security lists?
Are subnets required to separate the clients, SQL Server, and the data?

Data: Access to the application data is critical in any computing environment, including a cloud environment. One of the core issues in cloud computing is architecting the data storage around the compute systems, whether that storage is an object store, a block volume, or a file system. Large sets of data pose a different set of problems for migration. Calculate the amount of data that must move, whether that's a few gigabytes or a few petabytes.

Moving an application also gives you the opportunity to archive or reorganize the data to better suit the needs of the organization. Answer the following questions about the organization, management, and retention of the data:

How much of the data needs to move for the application to function properly?
Does the data need to be accessed across geographies or across availability domains?
If a major outage occurs, how much data can be lost? Is there a scale for acceptable data loss?
What kind of backup policies are needed to ensure compliance with organizational policies?
Are clones of the data required?
Does the application have any features that can help facilitate the migration between systems?

This list of questions isn't exhaustive, but it's the bare minimum that you should consider before moving to the Oracle Cloud Infrastructure.

Migration Scenarios

Depending on your priorities, you may choose from a few different approaches to migrating your on-premises applications to the cloud. Oracle Cloud Infrastructure provides reference architectures that support a broad spectrum of options.

There are many factors that can impact the optimum migration path from on-premises to cloud:

Is the application complete, requires few updates, and has a fixed workload?

“Lift and Shift” is an approach that makes as few changes to the infrastructure as possible. It reduces the chances of introducing differences in behavior, while still delivering the cloud benefits of improved performance from using the best hardware, storage and networking, as well as the financial benefits of moving from a capex to an opex model. Improve the database by moving to a managed version of Oracle database, improving reliability and reducing admin workload.

Is the application still an active project, with regular updates and version releases?

“Move and Improve” lets you upgrade the components of your application infrastructure to the latest versions, such as migrating WebLogic to version 12.2 and Oracle database to version 19c, and uses an Oracle validated architecture that can be deployed from Terraform scripts. This implements the best practices for running applications on Oracle Cloud Infrastructure. This approach makes it easy to spin up/down instances of the applications for dev and test work and improves the quality of production releases.

Do you want to implement a cloud native architecture, with support for elastic scaling, continuous deployment, and self-healing?

This enables the deployment of WebLogic based applications on Kubernetes clusters of Docker containers. Using OKE, Oracle Cloud Infrastructure’s managed Kubernetes service, it is easy to build highly resilient, scalable infrastructure, while levering your existing application code. This infrastructure is ideal to modern devops approaches to software development.

Across each of these approaches, Oracle offers choices to use database-as-a-service options for your applications, while preserving your investment in perpetual database licenses through its “Bring-Your-Own-License” (BYOL) program.

Current status	Goal	Type	Target Validated Architecture
Any custom application running on any Oracle database.	Improve reliability, performance, and security. Lower TCO. Minimize migration risk.	"Lift and Shift"	Move the application stack to a BM or VM on Oracle Cloud Infrastructure. Migrate database to Oracle Database Classic Cloud Service (BYOL).
JavaEE/WebLogic applications running on any Oracle database.	As “Lift and Shift,” plus: upgrade to latest WLS, automate dev/test/production deployments, implement HA and DR, consolidate databases.	“Move and Improve”	Deploy JavaEE/WLS to VMs/BMs by using Terraform scripts. Migrate databases to Oracle Autonomous Database, Oracle Database Classic Cloud Service (VM or BM) or Oracle Database Exadata Cloud Service. Implement advanced HA and DR options.
JavaEE/WebLogic applications running on any Oracle database.	As “Move and Improve,” plus: increase flexibility, elasticity, and improve developer productivity with extensive automation options.	“Modernization”	Deploy JavaEE/WLS to Docker/Kubernetes clusters, by using Terraform scripts. Migrate databases to ADB, Oracle Database Classic Cloud Service (VM or BM) or Oracle Database Exadata Cloud Service. Implement advanced HA and DR options.

Oracle can help you understand the considerations to choose the scenario that best fits your requirements and provides validated architectures to implement these scenarios.

Decide on the Best Migration Strategy

After you inventory your environment, you should decide on the best migration strategy.

Consider the following before you begin the migration process:

The best time of day to perform the migration
Downtime requirements
Database and data set size
The source and target database character sets
The source and target database versions
If the source database contains user-defined data types
The source database and the target database platform (endian)
Security considerations
A strategy for large workloads