Migration: One Year Later

A re-examination of the <i>IBM Data Management</i> special report reveals our coverage was on target

One year ago, we published a special report on migrating from Oracle environments to IBM® DB2® 9.7 database environments—“Migrate from Oracle or Sybase to DB2 in Weeks,” Issue 4, 2010. We looked at new technology that simplified migration by making DB2 capable of delivering many common Oracle features natively. We talked about how to plan for a migration, how to make the most out of the new DB2 capabilities, and where organizations would need to spend extra time to be sure that their migrations succeeded.

What a difference a year makes. Since we published our story, many organizations have done their own migrations and reported their experiences to IBM, to industry analysts, and to the trade press. So, how did we do? Where did our coverage meet expectations, where did we fall short, and what’s changed since then? Let’s take a look.

How compatible is it?

Last year, after talking with IBM engineers and hearing about some early customer results, we were impressed with the ability of DB2 to handle Oracle and Sybase code natively. We wrote that, “Most Oracle and Sybase applications can now be moved to DB2 9.7 with only minor modifications.”

If anything, we may have played this one a little conservatively. Over the past year, we’ve seen several reports of successful migrations where organizations were able to run their Oracle applications—including some third-party applications—on DB2 9.7 with zero changes. Throughout 2011, reports from industry observers, including IDC and others, corroborated the extent of the native support that DB2 provides for Oracle applications (see sidebar, “Resources”).

Here’s an example: over the past year, a leading global distributor migrated three Oracle applications to DB2. They had a remarkable degree of success from the start: one application needed no code changes, another needed only minor changes, and for the third, 94 percent of the code came over clean, 5 percent had minor syntax changes, and 1 percent needed rewriting. That last 1 percent of code dealt with XML translation and would have had to be rewritten even if the company stayed with Oracle, as those functions are no longer supported.

Eyes wide open

When we talked to IBM last year, we asked the IBM team to name some technical issues organizations needed to keep an eye on during migrations. IBM engineers provided a list of areas where a tech professional would probably need to intervene. Several were minor, but there were three that we thought the most likely to require significant attention. The first was trigger support; when we wrote the article, DB2 did not allow you to perform updates to tables from within a BEFORE trigger, and it did not allow trigger actions to be combined the way that a PL/SQL multi-action trigger does. The second was partition handling, as certain types of Oracle database partitioning would force you to update your table layout. The last major hurdle was third-party software dependencies written into the code.

In retrospect, there was one issue that we didn’t specifically call out but probably should have: testing. Of course, when considering the overall cost of a migration project, the time and expense of testing applications in a new environment absolutely needs to be factored in (for an example of how testing and validation can affect your project schedule, see “Major financial firm switches from Oracle to DB2 in 12 hours” on page 24). Some observers argued that the native compatibility features of DB2 could help mitigate testing costs to a certain extent. Others recommended running a full test cycle as the prudent course of action.

We went back to IBM to investigate how the compatibility features had changed in the ensuing year and found some interesting news. We spoke with Serge Rielau, the lead architect for the Oracle compatibility features in DB2 for Linux, UNIX, and Windows.

The first thing we learned is that the state of DB2-Oracle compatibility is something of a moving target because the team is constantly making and releasing improvements (see sidebar, “What’s improved in DB2 9.7?”). For example, that lack of support for PL/SQL triggers? Fixed. “We added full support for multi-action PL/SQL triggers as well as updates in BEFORE triggers in Fix Pack 4, which was made generally available in April,” says Rielau.

We also asked about support for complex nested objects that need to be processed by PL/SQL. These often occur in situations where data is entered through a form in a web browser. The browser (or web server) logic may package up the data into a set of nested objects, which it expects the database to be able to decode.

Here, we got a good news/bad news reply. The bad news is that we didn’t cover this compatibility issue in our original story—the development team simply did not expect nested complex objects to be popular. The good news is that it will probably not be an issue for much longer. Rielau wouldn’t make any promises, but it’s clear that the team has their eyes on a solution.

What’s improved in DB2 9.7?

In addition to enhanced compatibility features, the IBM Data Movement Tool (IDMT) continues to add capabilities. IDMT was already a dependable vehicle to migrate database objects and data, with interactive and background options. Now there’s a new option to specify the number of JVMs, which provides scalability. The Auto Fix utility gives developers a temporary quick fix to increase out-of-the-box compilation of PL/SQL source files. And for the unusual scenario of a schema without tables, such as a schema containing only procedures, there is a feature that will enable migration of DDL and objects.


When does it make sense to migrate?

One of the biggest decisions that an organization needs to make about migration is figuring out whether the return on investment is sufficient to justify the cost. Most observers focused on the direct costs of the RDBMS platform, but it turns out that licenses aren’t the only places where organizations can recoup their investment.

In April 2011, IDC reported on an Oracle-to-DB2 migration that the Coca-Cola Bottling Co. Consolidated (CCBCC) undertook to support its SAP ERP system. The report noted that CCBCC was able to reduce its licensing costs by moving to DB2. But IDC writes that the company was also able to reduce its database storage space: “By using [IBM DB2] Deep Compression—a dictionary-based approach to replace and index repeating patterns with short symbols, compressing the data to 160 tables—SAP ERP systems storage requirements went down to 3TB from 5TB prior to migration. As a result, no hardware upgrades were required. In addition, the duration of manufacturing runs was also reduced by 65%, from 90 minutes to 30 minutes.”

The year also turned out to be a bit unusual on the migration front. Several organizations found themselves looking for alternatives as a result of Oracle’s decision to cease future development on Intel Itanium processor–based servers. That drama is still playing out, but this could be a time when organizations looking for long-term stability consider migration. In an article for ZDNet, Daniel Kusnetzky recommended that organizations “consider everything that would be needed to make the transition work” and choose “a supplier that has the tools, the services, the partners, and systems to create a long-term solution to this problem.”

Kusnetzky also notes that “IBM certainly can be seen as a strong supplier of products and services that can address this issue. The company offers a broad portfolio of systems, software and professional services to help in a migration. They also have an extensive, worldwide partner ecosystem [that] can offer help wherever the customer is located.”

Report card

In our original story on Oracle and Sybase migration, we wrote that “DB2 9.7 is compatible with applications and databases developed for Oracle and Sybase at a level that you might not have thought possible.” So how well you think we did in our coverage may depend on how compatible with Oracle and Sybase you thought DB2 9.7 was in the first place.

Overall, we believe that our assertions matched up nicely with what independent observers reported during the past year. But no matter what, with many organizations seeking strategies to cut costs, improve performance, and establish a stable information-management foundation, it looks like migration will be a hot topic for some time to come.


Migrate from Oracle or Sybase to DB2 in Weeks (IBM Data Management, Issue 4, 2010)

DB2-Oracle compatibility, including the MEET DB2 tool

HP vs. Oracle over Itanium: A look at your options by Daniel Kusnetzky

IDC, Buyer Conversations: Coca-Cola Bottling Co. Consolidated’s ERP Upgrade Journey. APEJ View: Doc#AP2670107T, April 2011.

IBM DB2’s Maturing Oracle Compatibility Presents Opportunities, With Some Limitations: 22 July 2011. Gartner Doc ID#G00214082.

Simpler Database Migrations Have Arrived! 9 Feb 2011. Forrester Research.