Moving older-but-still-working applications from on-premises to cloud is a tricky, but not impossible, business.
Moving on-premises workloads to the cloud is not a trivial exercise but it doesn’t have to be overly painful.
One of the biggest issues in such migrations is that the technologies that have run on-premises until now are set up and operate differently than newer cloud-based applications. Still, most companies can navigate this deployment minefield if they plan carefully and execute well.
Below are seven steps to an on-premises-to-cloud migration that Oracle followed as we moved hundreds of our own applications to Oracle Cloud Infrastructure (OCI).
1. Prioritize your applications
First, the company should determine how critical each of its legacy apps is to the business, the relevance of the technology used, and how fast that app can be moved from on-premises to the cloud.
At the outset of Oracle’s own migration project in late 2019, our team evaluated more than 600 applications. After a rigorous rationalization process, we ended up moving ‘just’ 350 of these to OCI. While some of our apps were more suited to go directly into SaaS cloud apps, others needed to be decommissioned because they just weren’t as important to the business as they were 10 years ago.
But, before either sunsetting or moving any applications, the company should look at what each application or customization does and explore whether there is already similar capability in a SaaS cloud app, such as Oracle Fusion Cloud Human Capital Management (HCM). Rather than moving every single HR customization to the cloud individually, it might be better to build those functions into a cloud-native SaaS application.
2. Design application blueprints with security in mind
The second step is to design application blueprints and metadata systems. These not only help companies organize applications into distinct categories so they can be easily accessed, but they also help document procedures for how these apps are to be managed, and who can access them.
An application’s security requirements have a big impact on how it’s managed once moved to the cloud. For example, pluggable and container databases have different rules for what can sit in the same database stack, what can sit in the same subnets, and what the segregation of duties are that determine who can access those components.
From a design standpoint, it is critical to determine up front how each application will be managed in the cloud, and who can access those apps, before determining which cloud services should be deployed. If the company just makes general assumptions about where to put the applications, without regard for what their different security requirements are, there will be problems down the road.
3. Create tenancies for specific types of workloads
At Oracle, we decided very early in the process to segregate our production tenancies from the company’s development tenancies in the cloud architecture. An OCI tenancy refers to the root compartment that holds all of your cloud resources. It can be further segmented into compartments allowing for distinct access controls. These controls can be applied broadly or specifically to organize and administer common services.
This decision enabled Oracle’s HR, finance, marketing, and other departments, to set up their own security rules within their development environments, while ensuring those rules were thoroughly tested and validated before moving them into production. For developers, it meant more freedom to experiment, share code, and make changes using development tenancies that are walled off from the company’s everyday operations.
While these production and development tenancies are segregated, we also built pipeline workflow automation, so the teams can develop in one tenancy and securely push their code to the other.
4. Build common foundation services
In any cloud environment, it’s important to have a set of common foundation services, such as a Domain Name System (DNS) and sendmail service, which can be shared across a company. We put those services in a dedicated compartment within an OCI tenancy that other departments can access as needed.
While an individual tenancy is a secure and isolated partition within OCI, a compartment allows further segmentation for access controls. These controls can be applied broadly or specifically to organize and administer common services.
To build Oracle’s common foundation services, our team consolidated them into a single compartment and allowed all of the other departments to utilize them. This model enables centralized, efficient management of services for license and access controls and logging. As the foundational services for the tenancy have a standard pattern, regional instances can be replicated or scaled as required
5. Implement orchestration and deployment platforms
Like many application developers, Oracle takes advantage of continuous integration and continuous deployment (CI/CD) methods to manage its pipelines. CI/CD techniques help automate building, testing, and deploying applications in the cloud. Our team built a dedicated compartment for pipeline services to support CI/CD where source code, artifacts, and deployment services can be repurposed, without compromising the source control systems.
Rather than giving everyone root access to make changes, this model provides an automated workflow that allows only authorized people to configure templates or code. This is crucial in preventing someone from deleting files, or changing a configuration, or doing something else that could potentially bring the entire system down.
6. Use (and reuse) infrastructure as code
Using the right deployment platform makes it easier for DevOps teams to provision infrastructure resources, track changes, and document and reverse deployments. Our team used OCI’s Terraform infrastructure-as-code tools to help them instantly version and share files containing the necessary steps to provision cloud resources.
OCI’s Terraform stacks help our teams configure everything from a single tenancy to multiple infrastructure components—such as virtual cloud networks and API gateways—or platform components like Oracle Autonomous Data Warehouse. And, with a few simple APIs within OCI’s Resource Manager, we can reuse our existing code templates to make changes to our portfolio applications.
7. Write runbooks and governance policies
Application runbooks provide detailed operating procedures and governance policies that help DevOps teams with tasks, such as automating routine maintenance activities, responding to system alerts and outages, and defining how infrastructure resources should be provisioned and configured.
Our team built runbooks so that we could easily locate the environment-as-code templates and quickly automate any changes to the applications that our HR, finance, and other operations teams need. These runbooks can also quickly spin up testing environments for new applications, without having to design new components from scratch.
For example, once an HR or finance exec suggests a change to a runbook or governance policy, our team simply highlights the proposed change, sends it to the business owners for approval, and within a few hours or days, the updated runbook and policy are published. This means they do not have to review every line of code, service definition, and security policy. And that, in turn, has saved months of development time.
Summing Up
All of these steps align with two guiding principles that are key to success when building and deploying applications in the cloud.
First, in nearly all cases, Oracle looks to build cloud-native applications first. However, if that is not possible, we then construct microservices that take advantage of all the new functionality available in OCI. Using these microservices we replicate features and functions of the older software.
Because we’re building apps differently than in the past, we can take advantage both of standalone services, such as an on-premises servers, and cloud services, such as Oracle Autonomous Database. It doesn’t have to be one or the other. It can be everything in between.
