Thinking about moving your Oracle enterprise applications to the cloud? Excellent. There are many benefits to cloud computing, but first you have to get there — and it can be (but doesn’t have to be) a daunting process. As you determine the best approach for your organization (e.g., public or private clouds, hosted and managed services, etc.), keep in mind the actual, physical migration and what “cutover” entails, not to mention the demands of ongoing application maintenance. Understand that enterprise applications have unique requirements, particularly because they are often highly customized to meet the specific business needs of an organization.
Cloud migrations can’t be performed successfully on the fly, or by skeleton crews or by DBAs that have only conducted software upgrades a few times a year. Oracle expertise and hands-on migration experience are crucial to the initiative. In this slideshow, Data Intensity, LLC shares seven tips for enterprises looking to migrate their Oracle enterprise applications to the cloud.
Cloud Migration Dos and Don’ts
Click through for seven dos and don’ts organizations should consider when migrating Oracle enterprise apps to the cloud, as identified by Data Intensity, LLC.
Do a Reality Check
Do a reality check – “build vs. buy.” Evaluate whether you have the budget, 24×7 staff resources and Oracle expertise in-house to perform a migration, as well as maintain the applications once in the cloud. Keep in mind that with public clouds like Microsoft Azure and Amazon Web Services (AWS), you don’t need to manage infrastructure, but you do need to manage your applications, and neither of these public clouds have specialized Oracle services.
Do Your Homework
Do your homework – know what has been changed from standard Oracle functionality. There are always customizations, modifications and extensions made to enterprise applications over time (and likely, by many different parties) to meet an organization’s specific business needs. If your applications are moving to the cloud, all of this development work is moving too. If you don’t have strong development standards (e.g., no hard coding of extensions), you’ll need to remediate and migrate each and every customization and extension — which, for many organizations, can be in the hundreds.
Don’t Risk Unnecessary Downtime
Don’t risk unnecessary downtime – make sure you know what data transfer capabilities your chosen cloud provider affords you (this applies to every cloud approach — public, private, hosted or managed services). Each cloud has its own standards for data transfer; data migration between different platforms is not transparent and must be performed as quickly as possible. For example, Azure only offers Windows and Linux; this means full-cycle platform migration for the customers on AIX/Solaris/HP-UX. No organization can afford to shut down business while a migration occurs. Therefore, to minimize platform-change risks, leverage resources with proven migration experience.
Don’t Break Your Interfaces
Don’t break your interfaces – organizations have many interfaces, from Oracle enterprise apps to legacy systems as well as interfaces to external systems such as point-of-sale (POS) or payments — all of which can be broken during a migration. Therefore, you must diligently test every interface before migration cutover.
Do Perform Stress Testing
Do perform stress testing – before cutover. Be sure to test the system before the migration to avoid performance issues on “the day of” and following. Emulate the cloud system as well as the actual number of production users (don’t forget users around the globe) so that you can fix any problems well ahead of time.
Don’t Leave Users Out of the Planning Equation
Don’t leave users out of the planning equation – in addition to performing stress testing, test user acceptance. After all, users don’t care about what infrastructure you take advantage of, they are concerned about application performance, and want to feel confident that things will run as expected (or even better) after the migration.
Do Treat Cutover as a Major Event
Do treat cutover as the major event that it is – planning for the big day should begin a minimum of two weeks in advance. Do not change anything (not previously planned) on the day of cutover. And no one should be reading notes on what needs to take place “the day of.” Everything should have been previously emulated and tested to ensure that there aren’t any surprises!
