Organizations across all sectors are gradually delivering more services through the cloud, to enjoy all the benefits this can bring. Independent software vendors’ (ISV) customers are no different. With many already experiencing the benefits of cloud in other areas of their operations, they’re now looking to do the same around the often mission-critical applications they buy from ISVs. There are several credible enterprise cloud providers, and smart ISVs are adopting multivendor cloud strategies, selecting the best cloud for specific purposes.

For your Oracle-based applications and their databases, Oracle’s cloud is nearly always best in terms of performance, cost-effectiveness and ease of migration. This is because all parts of the Oracle technology stack come from the same vendor and are engineered to work together. We’ll therefore focus on migrating your Oracle-based applications to the Oracle Cloud for the remainder of this guide.

Why you need to get it right first time

When you’re migrating an important or even critical part of your customers’ operations to the cloud, you need to get it right first time. The potential financial and reputational damage to your business (and potentially your customers’) if you don’t is unthinkable. To help you achieve success, here are nine things to consider as you plan the move.

1. Choose the right flavour of Oracle Cloud

You’ve got several options when it comes to migrating your application to Oracle Cloud, and it’s important you choose the right one if it’s to perform well.

For most workloads, the standard Oracle Infrastructure as a Service (IaaS) offering will suffice, though you need to select the appropriate version:

• Bare metal server: This provides access to a server, giving you ultimate flexibility, including the ability to use your own hypervisor

• Dedicated compute: This includes a server with a hypervisor and guest operating system. All of this will be for your sole use, and you get full access to the guest OS

• General compute: This includes a server with a hypervisor and guest operating system on shared infrastructure. Again, you get full access to the guest OS

If you need high performance, perhaps for tier-one database workloads, consider the cloud options that use Engineered Systems. There’s also the storage-only option, if your customer just wants to use the cloud for application backups. Lastly, if you or your customer are concerned about security or must guarantee the geographical location of data, there’s the Oracle Cloud Machine. This appliance sits in your customer’s data center and is priced on a consumption (pay-for-what-you-use) basis. This provides dedicated infrastructure and many of the benefits of cloud, inside their own firewall. They will, however, still need to pay the data center costs. This approach can be a gamechanger for customers in highly regulated sectors.

2. Make sure you can offer attractive SLAs (and deliver on them)

Switching your customers to a Software as a Service (SaaS)-based approach will almost certainly mean you have to provide a guarantee around availability levels. And this can be challenging, because Oracle Cloud (like other cloud vendors) only offers a so-called ‘Service Level Objective’. This is less stringent than a formal Service Level Agreement (SLA), and gives you as the ISV no recourse to Oracle if your application becomes unavailable as a result of the cloud data center being unavailable. But under your SLA with your customer, you may still have to pay a service credit. Linked to this is another issue: in a customer’s own data center or data room, they (or you) have complete control of when maintenance windows are scheduled. In the cloud, however, these timings will be determined by your provider. What if your customer needs your application available during these scheduled downtime windows?

Both these issues demonstrate the need for you as the ISV to architect your customers’ cloud platforms in a way that enables you to confidently deliver the availability they require, and back this up with an SLA you know you can achieve.

3. Don’t assume you can keep the same architecture

The previous point outlines one of the reasons why replicating your customers’ on-premises architectures in the cloud may not be the best approach. There are others besides. They all boil down to the fact that keeping the same architecture could hamper your ability to deliver your customer the promised benefits of cloud. Assess how you can optimize the application’s environment for cloud by resizing, reconfiguring or re-architecting it.

4. What’s your application connected to?

Enterprise-scale applications are almost always connected to a wider ecosystem of databases, services and other applications. Before you move your application to the cloud, you need to understand what impact this will have on your customer’s other applications or processes that rely on it or its data. Take these additional requirements into account when you design the cloud architecture for your customer, and look at where you may need to reconfigure other applications and services to enable them to continue to link seamlessly with yours.

5. How will you deliver performance?

Think about the performance impact of moving data between the cloud, your customer’s on-premises architecture and its end users. Particularly where large volumes of information are involved, you’ll need to plan for how to deliver the performance your customers (and theirs) require. What steps can you take to reduce the amount of data that has to be moved between the cloud and on-premises, for example? Or could you co-locate related on-premises infrastructure in a data center closer to the cloud to minimize latency?

6. What about security?

Security needs to be a central part of your plans from the word go. Involve your own and each customer’s information security teams to ensure you implement (and can document) appropriate measures. Make sure you can deploy their existing enterprise security tooling into the cloud environment, and apply the same level of rigour you would with an on-premises implementation. On a more granular level, make sure you define the security requirements per application and per dataset, ideally on a tiered basis. This will help you and your customers decide what data can reside in the cloud and what can’t.

7. Licensing

In the Oracle world, the cost and complexity of licensing means it always requires close attention. However, as an ISV, there are options for you to move to simpler licensing models, which help free up funds to invest in cloud transitions. For your customers, running your application from the cloud can help reduce their license requirements and enable them to run a leaner, more economically sustainable estate.

8. Role changes

Moving to the cloud could mean role changes in your ISV business. Your responsibility will now extend beyond the application itself, so you’ll need someone to oversee and be accountable for the cloud infrastructure it’s running on. The strategic importance of this means it will typically involve a director, VP or C-level appointment. For your customers, moving your application to the cloud should mean they have a smaller on-premises estate to manage. Consequently, they may be able to free up resources from administration to focus on higher-value work, such as innovation and new product and service development.

9. Plan the migration

Lastly, you need a proven, repeatable plan for how you’ll architect and build each customer cloud environment, integrate it with other systems, migrate to it and then operate it sustainably. This is critical for two reasons. Firstly, because you need to deliver success on time, every time, so can’t afford to leave anything to chance. Secondly, because you’ll be delivering a lot of these transitions, you don’t want to be reinventing the wheel every time when it comes to the process you follow.

Conclusion

When you’re looking to move critical parts of your customers’ operations to the cloud, you need to get it right first time. By planning carefully and keeping these nine key things in mind throughout, you’ll be in the strongest possible position to deliver the benefits of cloud to your customers and your own business. In our final piece, we’ll outline a proven process of migrating an application to Oracle Cloud, and demonstrate how you can deploy your first customer pilot in as little as 30 days and full production operation in just 90 days.