Where do you start when your organization decides to undertake an Oracle database migration to the cloud? Migrating to the Cloud by Tom Laszewski and Prakash Nauduri attempts to answer this question. Our featured chapter, “Methodology and Design,” will addresses Oracle cloud migration options, basic methodology and design, things you should consider before getting started and what to expect.
Like any software development project, migration projects require careful planning and good methodology to ensure successful execution. When migrating from one database platform to another a good portion of the database design can be carried forward, especially the schema design for relational database migrations. It may be necessary to make some changes to the existing design and architecture if you want to leverage new features in the Oracle database in favor of older mechanisms, such as using database table partitioning and Oracle Real Application Clusters (RAC) to support multiple workloads instead of maintaining different databases in sync with database replication technologies. Therefore, a certain amount of rationalization is possible when migrating to Oracle from other databases, resulting in consolidation of many databases and schemas from the source database into a few schemas in Oracle. To enable such rationalizations and other optimizations in database design, it is essential to understand a typical migration project life cycle and the importance
Of all the options for client/server application migrations compared in Chapter 1, database migration is the most common because it allows users to migrate to new database platforms, yet leave applications intact, with no changes to existing functionality and business rules, including the languages in which the applications were originally developed. This approach provides the easiest migration path to a new platform, and ensures business continuity in the new environment, along with fewer upheavals. In cases where applications have become very difficult to maintain and update with new features to support business requirements, they are rewritten in new languages that leverage the latest technologies and standards. Such migrations turn into completely new software design and development projects instead of just platform migration efforts. In cases where the business functionality provided by an application is critical for the business and the goal is to make the application accessible from various channels (browser, mobile devices, etc.), the application is typically retooled to run in an environment which emulates a server to allow multiclient, multichannel access.
Legacy applications deployed on IBM mainframes and other proprietary and legacy platforms are usually retooled to run on open and distributed platforms using software that can mimic IBM mainframe environments or that can effectively provide the same capabilities on their own (e.g., Oracle Tuxedo).
Which migration option you choose will depend on your business requirements and constraints (e.g., time, cost, and feasibility). The easiest migration option is to Web service-enable an existing application so that it can interact with other applications on the Web or with applications deployed in a cloud environment. Of course, this approach also requires that these applications be modified to incorporate Web service capabilities by using either third-party solutions or native features, without requiring significant modification. Even if an application written in a language such as Visual Basic or PowerBuilder is not able to access other applications over the network, it can be modified to do so. It is also not necessary for every program comprising an application to be modified. Only programs that provide important reusable business services need to be identified and modified to Web service-enable them. Migration options such as database platform migrations and replatforming applications developed on legacy platforms are very popular because they are easier to execute and realize the benefits of such migrations quickly. On the other hand, migration options involving a complete rewrite/rearchitecture of an application or development of a completely new piece of software are less likely to be chosen due to the cost and time involved in executing such projects.
Lately, new technologies have emerged that aim to provide database transparency to applications. These technologies basically allow you to capture database calls issued by an application and then translate them on the fly to execute them against the target database. The goal of this approach is to significantly reduce application changes as a result of database migrations. However, organizations need to thoroughly test these technologies for performance and for accuracy of the converted SQL statements before deploying them in mission-critical environments. Some database vendors are making big claims that, using these technologies, database migrations can be completed within weeks. However, from the authors’ experience, testing alone requires significant effort. These emerging technologies definitely have a role in reducing the overall migration effort in large migration projects by reducing changes to the application due to database migrations.
About the Authors:
Tom Laszewski is currently the Director of the Oracle Platform Migrations Group. He has more than 20 years of experience in databases, middleware, software development, management and building strong technical partnerships.
Prakash Nauduri is currently the Technical Director of the Oracle Platform Migrations Group. He has more than 18 years' experience working with databases, middleware, development tools/technologies, software design, development and training.
This was first published in January 2012