Benefits of Lift and Shift for EBS to OCI Migration

What is Lift and Shift for Oracle Cloud

OCI lift and shift is a cloud migration approach that moves an existing application, workload, or IT environment from on-premises infrastructure to Oracle Cloud Infrastructure (OCI) with minimal changes to the application itself. Also known as rehosting, the approach allows organizations to move workloads to the cloud while preserving their existing applications, configurations, customizations, and business processes as much as possible.

Rather than redesigning an application or replacing it with a cloud-native or SaaS alternative, lift and shift focuses primarily on moving the underlying infrastructure to OCI. This makes it particularly useful for organizations that want to accelerate cloud adoption, reduce dependence on physical data centers, or address aging infrastructure without undertaking a large-scale application transformation at the same time.

For Oracle E-Business Suite (EBS) customers, OCI lift and shift can provide a way to continue running existing EBS applications in the cloud while retaining important customizations, integrations, and business processes. Organizations can subsequently modernize individual components as part of a longer-term cloud roadmap.

It is important to distinguish lift and shift from re-platforming. Rehosting generally involves moving a workload with minimal changes, while re-platforming introduces selected modifications to take advantage of cloud capabilities without completely redesigning the application.

Why Use Lift and Shift for Oracle Cloud Migration?

Organizations typically consider OCI lift and shift when they want to move workloads to the cloud without the time, cost, and business disruption associated with extensive application redevelopment.

Reduce Data Center Dependency

Moving workloads from on-premises infrastructure to OCI can help organizations reduce their dependence on physical data centers and the associated infrastructure management responsibilities.

This can be particularly valuable for organizations facing data center consolidation, hardware refresh requirements, infrastructure capacity constraints, or increasing operational costs.

Accelerate Cloud Adoption

Because lift and shift generally requires fewer application changes than refactoring or rearchitecting, organizations can move workloads to OCI faster. This allows the business to begin using cloud infrastructure capabilities without waiting for a complete application modernization program.

Preserve Existing Applications and Investments

Organizations can continue using applications that already support their business processes instead of immediately replacing them.

For EBS customers, this can mean preserving valuable application knowledge, configurations, customizations, integrations, and existing business processes while changing the underlying infrastructure.

Minimize Business Disruption

A lift-and-shift migration generally introduces fewer changes to the application and user experience than a major application transformation. This can reduce the amount of retraining and business-process change required during the initial cloud transition.

Create a Foundation for Future Modernization

Lift and shift does not have to be the final stage of cloud adoption. Once workloads are operating on OCI, organizations can identify opportunities to optimize infrastructure, modernize integrations, automate operations, or refactor selected application components.

This allows organizations to separate infrastructure migration from application modernization and approach transformation incrementally.

Support Business Agility

Cloud infrastructure can make it easier to provision resources and environments as business requirements change. This can be particularly useful for organizations managing business growth, mergers and acquisitions, divestitures, new projects, or temporary environments.

OCI Lift and Shift Process

A typical OCI lift-and-shift process involves moving the existing workload from its current infrastructure to an appropriately designed OCI environment while minimizing changes to the application.

The exact process varies by workload, but generally includes the following stages:

1. Assess the Existing Environment

The source environment is evaluated to understand its applications, operating systems, databases, storage, integrations, network dependencies, performance requirements, and security requirements.

2. Design the OCI Target Environment

The organization defines the OCI architecture required to support the workload. This can include compute, storage, networking, databases, load balancing, security controls, backup, and disaster recovery.

3. Prepare the OCI Environment

The required OCI resources, networking, security policies, connectivity, and supporting services are configured before migration.

4. Move the Workload

The application and associated data are transferred to the target OCI environment using an appropriate migration method.

5. Validate the Environment

The migrated workload is tested for functionality, performance, integrations, security, data integrity, and operational readiness.

6. Perform Production Cutover

Once testing is complete, the production workload is moved to OCI according to the planned cutover strategy.

7. Optimize After Migration

After the workload is running on OCI, organizations can review resource utilization, performance, security, availability, and cloud costs and make adjustments where necessary.

For complex enterprise workloads such as EBS, the migration approach and sequence should be determined based on the specific application and database architecture.

Key Components of an EBS to OCI Lift-and-Shift Migration

Oracle E-Business Suite is a useful example of how OCI lift and shift can be applied to a complex enterprise application environment. An EBS lift-and-shift migration typically requires consideration of several interconnected components.

EBS Application Tier

The EBS application tier contains the application services required to run the E-Business Suite environment. Its operating system, configuration, customizations, integrations, and infrastructure dependencies should be assessed before migration.

Oracle EBS Database

The database is a critical component of the EBS architecture. Organizations need to consider database version, size, performance, availability, storage, backup, recovery, and any RAC or other high-availability requirements when designing the OCI target environment.

Compute and Storage

OCI compute and storage resources provide the infrastructure required to run the EBS application and database components.

The target resources should be sized according to workload requirements rather than simply reproducing the existing on-premises infrastructure configuration.

Networking

The OCI network architecture needs to account for virtual cloud networks, subnets, routing, security rules, load balancing, and connectivity between EBS and other enterprise applications.

For hybrid environments, connectivity between OCI and on-premises systems is particularly important because EBS often depends on external applications and integrations.

Security and Identity

Security controls should be incorporated into the OCI architecture before migration. This includes network security, identity and access management, authentication, data protection, and appropriate administrative controls.

Backup and Disaster Recovery

Backup and disaster recovery requirements should be considered as part of the target architecture. The appropriate approach depends on the business’s recovery point objectives, recovery time objectives, workload criticality, and regulatory requirements.

How Does EBS Lift-and-Shift Automation Work?

Automation can reduce the manual effort involved in deploying and managing EBS environments on OCI.

For an EBS lift-and-shift project, automation can support activities such as infrastructure provisioning, network configuration, environment creation, cloning, backup, and lifecycle management.

The target architecture can be defined before deployment, including the OCI compute resources, virtual cloud network, subnets, routing, security controls, storage, and load balancing requirements.

Automation is particularly valuable when organizations need to create multiple EBS environments. For example, development, testing, training, and production environments can have repeatable deployment processes rather than requiring administrators to configure each environment manually.

A certified Oracle cloud MSP/MSE can also help organizations incorporate automation into the migration process, identify dependencies that require manual intervention, and establish repeatable operational procedures after migration.

Oracle Cloud Infrastructure Configurations for Lift and Shift

EBS customers can use different OCI infrastructure configurations depending on their workload requirements, environment size, availability requirements, scalability needs, and preferred level of infrastructure management.

Option 1: Single-Node EBS on OCI Compute

A single-node configuration combines the EBS application and database tiers within a single compute environment.

This approach can be appropriate for evaluating EBS functionality, development, testing, demonstrations, or environments where independent scaling and high availability are not primary requirements.

Best suited for: Development, testing, demonstrations, and evaluation environments.

Option 2: Multi-Node EBS on OCI Compute

A multi-node configuration separates the database tier from one or more application tiers.

This architecture provides greater flexibility because application resources can be scaled independently according to workload requirements.

It can support a broader range of EBS environments, including production, development, testing, and training environments.

Best suited for: Production and other environments requiring greater scalability and architectural flexibility.

Option 3: EBS on OCI Compute with Oracle Database Services

Organizations can also run the EBS application tier on OCI compute while using an appropriate Oracle database service for the EBS database.

This approach allows organizations to select database infrastructure based on requirements such as performance, availability, scalability, and database management.

The appropriate database configuration should be determined based on the EBS architecture, workload characteristics, availability requirements, and supported Oracle configurations.

Best suited for: Organizations looking to combine OCI compute flexibility with Oracle database infrastructure and services appropriate to their workload.

What Are the Deployment and Management Choices for OCI Lift and Shift?

Moving a workload to OCI does not necessarily mean the organization must manage every component itself. Organizations can choose how much infrastructure and operational responsibility they want to retain.

1. Self-Managed OCI Environment

The organization manages its OCI infrastructure and application environment, including provisioning, monitoring, security, backups, patching, and ongoing administration.

This approach provides the greatest level of control but requires appropriate internal Oracle and cloud expertise.

2. OCI with Managed Platform Services

Organizations can use OCI platform and database services to reduce some infrastructure management responsibilities while continuing to manage important parts of the application environment.

This model provides a balance between control and operational efficiency.

3. Fully Managed OCI Environment

Organizations can engage a qualified managed services provider to handle infrastructure and application administration, monitoring, backup, performance management, and other operational activities.

This can be appropriate for organizations that want to reduce the internal operational burden associated with managing EBS and OCI.

When Should You Choose OCI Lift and Shift?

OCI lift and shift can be a suitable approach when the primary objective is to move workloads to the cloud quickly while minimizing application changes.

It is particularly worth considering when:

• The existing application continues to meet business requirements.
• The organization wants to reduce data center dependency.
• Application redevelopment is not currently a priority.
• The business needs to accelerate cloud adoption.
• Existing customizations and integrations are still required.
• The organization wants to minimize business disruption.
• Infrastructure scalability is becoming a concern.
• The organization plans to modernize applications incrementally.
• Internal cloud skills are still developing.
• The business needs a practical first step toward broader cloud adoption.

For EBS customers, lift and shift can be particularly useful when the organization wants to retain its existing EBS environment while modernizing the infrastructure layer first.

When is Lift and Shift Not the Right Approach?

Lift and shift may not be the best choice when the primary objective is to completely modernize an application.

A different migration strategy may be more appropriate when:

• The application requires significant architectural changes.
• The organization wants to adopt cloud-native services immediately.
• The existing application has substantial technical debt.
• Maintaining the existing application is more expensive than replacing it.
• The organization is moving to a SaaS platform.
• Existing infrastructure dependencies make rehosting impractical.
• The application’s architecture prevents it from benefiting meaningfully from cloud infrastructure.

In such cases, re-platforming, refactoring, rearchitecting, rebuilding, or replacing the application may provide a better long-term outcome.

How Can Organizations Make OCI Lift and Shift Successful?

A successful lift-and-shift project depends on more than moving workloads from one infrastructure environment to another.

Organizations should:

1. Assess dependencies before migration rather than assuming the application can simply be copied to OCI.
2. Design the target OCI architecture based on actual workload requirements.
3. Validate networking and integrations before production cutover.
4. Test application functionality and performance in a non-production environment.
5. Define backup and disaster recovery requirements before migration.
6. Plan the production cutover and rollback strategy.
7. Monitor resource utilization and costs after migration.
8. Create a roadmap for future modernization where additional transformation is required.

For complex EBS environments, working with an experienced Oracle cloud partner can help organizations assess dependencies, design the OCI architecture, automate repeatable processes, and manage the environment after migration.

Frequently Asked Questions (FAQs)

What is OCI lift and shift?

OCI lift and shift is a cloud migration approach in which an existing application or workload is moved from on-premises infrastructure to Oracle Cloud Infrastructure with minimal changes to the application’s code and architecture. It is also commonly referred to as rehosting.

Is lift and shift the same as rehosting?

Yes. Rehosting is the commonly used term for a migration approach that moves an application to a new infrastructure environment with minimal modification.

Is lift and shift the same as re-platforming?

No. Re-platforming involves making selected changes to take advantage of cloud capabilities, whereas rehosting generally aims to move the workload with minimal changes.

Can Oracle EBS be moved to OCI using lift and shift?

Yes. Oracle E-Business Suite can be deployed on OCI using appropriate infrastructure configurations. The exact architecture depends on the EBS and database environment, workload requirements, integrations, availability requirements, and other technical considerations.

Does OCI lift and shift require application changes?

Not necessarily. The objective of rehosting is to minimize application changes. However, individual applications may still require remediation because of operating-system dependencies, integrations, networking, security requirements, licensing, or other technical constraints.

Does lift and shift reduce cloud costs?

It can reduce certain infrastructure and migration costs, but it does not automatically guarantee lower total operating costs. Cloud resource sizing, utilization, storage, networking, licensing, backup, and ongoing management all affect the final cost.

Can organizations modernize applications after lift and shift?

Yes. Lift and shift can be used as the first stage of a broader modernization roadmap. Once the workload is operating on OCI, organizations can progressively evaluate opportunities to re-platform, refactor, rearchitect, or replace selected components.

Is OCI lift and shift suitable for production workloads?

It can be, provided the target OCI architecture is appropriately designed and validated for the workload’s performance, availability, security, backup, disaster recovery, and scalability requirements.