Database Migrations Are Finally Becoming Simpler

Lately I have been getting quite a few inquiries on database migrations asking me about migration approaches, best practices, and tooling. Some of the reasons why companies are looking at migrations are because of staffing issues, scalability and security concerns, and cost-saving strategies. Migrations have always been complex, time consuming, and expensive, because each DBMS has proprietary data structures, data types, and SQL extensions. Once you choose a DBMS, you get locked into its platform, often creating a challenge when looking to migrate. Some companies told me that it took them more than a year to migrate some large and complex applications, which is not surprising. Although, tools and services have helped with migrations in the past, they have not been comprehensive and automated, which would make the process simple. Like an IT manager in the retail sector recently told me, “We did not want to spend a million dollars on tools and services just to save a million dollars on our database platform; it just didn’t make sense.”

The good news is that there is a new option that has recently emerged and has been gaining ground. Enter the “database compatibility layer,” which changes the way migrations are done. IBM DB2 9.7 for Linux, UNIX, and Windows offers out-of-the-box compatibility for Oracle’s PL/SQL and Sybase ASE, which allows many applications to run against DB2 without any application code changes. Although the database compatibility layer does not offer 100% compatibility today, based on customer feedback from more than two dozen interviews that I have conducted this year, one can usually expect 90% or more compatibility, requiring only minor code changes. This is huge, which makes migrations simpler, taking only days and weeks as opposed to months and years. IBM jointly developed the database compatibility layer technology with vendors EnterpriseDB (for Oracle compatibility) and ANTs (for Sybase ASE compatibility), who also offer their own database migration solutions.

The database compatibility layer finally opens up the door to more migrations, reducing risk and making them cost effective. I estimate that so far, some 300 companies have migrated their databases using the database compatibility layer, and this is likely to become the standard approach for database migrations in the future.

I would love to hear feedback on database migration experiences using the compatibility layer or other approaches -- things that have worked for you and things that did not. Also, are you looking to migrate anytime soon or holding back because of the risk involved?

Cheers,

Noel

Comments

Migrations for non-relational databases to DB2

Hello Noel,

We have a Unisys DMS on OS2200 (non-relational) that we try to move to DB2 v9.7

It would be great if you could recommend some approches / best practices for the same

Thanks in advance

-Sree

Open source as a migration alternative

Noel,

In light of these discussions, I was surprised to see that Postgres lagging behind in terms of performance and other features. I find that a radical shift and wonder if you could explain more on this. I would think Postgresql would be a viable alternative and perhaps more attractive with recent events with SUN and MySQL's future.

I see alot of information (for example) to the contrary.

http://www.randombugs.com/linux/mysql-postgresql-benchmarks.html

Open source as a migration alternative

Excellent Link. I really do hope to see more databases migrate to Postgres.

Migration.

Noel,
Do you have any comparisons between different RDBMS for OLTP systems? I would love to see any comparisons between oracle, db2 and sybase for OLTP systems since we are planning for migration.

Are HP Itanium server users stuck with Oracle price increases?

Hi Noel, IBM and SmarterQuestions is tackling this idea right now at SmarterQuestions.org. The world of database migrations has undergone a paradigm shift with IBM DB2 9.7 which can run Oracle PL/SQL and Sybase T-SQL with little to no change since DB2 9.7 includes a “compatibility layer”. DB2 9.7 also drastically lowers the cost of migration, and allows you to migrate in days or weeks rather than months. Please visit SmarterQuestions.org to join our discussion about cost-effective ways to move off Oracle: http://bit.ly/gMY1Zp

DB2 9.7 migrations

I think the database world is going through interesting changes with IBM coming out with significant changes to their patent databases like Informix and DB2. Both Informix and DB2 has been added many features that are handy in today's high demanding data storage. For example Informix's flexible grid technology is very handy if you have many instances involved in a cluster environment. DB2 on the other hand has added enhanced migration features which enables easy migration from competitors like Oracle and SQL server. In data warehouse environments (where huge amounts of data is involved), DB2 clearly ends up as a winner because it can handle complex queries with ease. I have dealt with an environment where Oracle and DB2 were running in parallel and needless to say Oracle used to crash a lot whereas DB2 was rock solid. I hope IBM databases starts getting its due and more importantly I hope IBM sales guys does a good job taking this message to the world.

OS2200 - DMS Migration

We have a Unisys DMS on OS2200 (non-relational) that we try to move to Oracle 11i.

It would be great if you could recommend some approches / best practices for the same.

Thanks in advance

Oracle dropping Itanium makes migrations really important

With Oracle discontinuing support for Itanium, there are bound to be many HP customers looking fo alternatives to oracle for their hardware. IBM's DB2 and Microsoft SQL Server are the two natural choices. DB2 has a significant edge as most of the Oracle Itanium customers are on Linux/HP-UX so moving to SQL Server would switching platforms which is a huge deal for most customers. Also, with the DB2 having out-of-the-box Oracle compatibility, the cost and effort of going to DB2 would be a fraction of what would be required for a move to MS SQLServer.

http://freedb2.com/2011/03/23/oracle-not-so-subtle-hint-to-hp-customers/