Tackling technical risk in database migrations

Share this post:

Technical risk is one of the most common migration worries organizations face, and the potential technical risks vary depending on the type of migration.

So far, this series has covered custom code application migrations as well as migrating ISV applications (see part 1 and part 2). Now I want to discuss technical risk for database migrations, with input from my IBM Systems Lab Services Migration Factory colleagues Rick Murphy and Mark Short.

Migrating databases

To get started, there are two guiding principles that reduce risk:

  1. Never touch the source database: We never modify the source database during a migration. During the go-live weekend, we shut down the source applications and start the cut-over to the new target. If a problem arises, we simply stop the migration and restart the production database on the source system. This gives the client a solid feeling that a back-out plan will work if needed.
  2. Isolate the migration from the client’s day-to-day operations: We use copies of the production instances, called staging servers, for most of our test migrations. This isolates the migration from the client’s day-to-day operations—so no outages are required on the client’s production environment and there is no chance of the migration process bringing down the client’s business.

Most database migrations are relatively low-risk projects, but clients will always worry about losing and/or corrupting valuable data during the migration process. We will talk a bit later about how we guard against that happening, but first we want make some general comments about database migrations.

We’ll be talking about cross-platform migrations in this blog post. That’s where the hardware vendor and operating system change. It is also possible to change the database management system during cross-platform migrations. For example:

Source Database Source Platform Target Database Target Platform Comments


Oracle Sparc/Solaris Oracle Power/AIX

Source and target platform changed and database remains the same


Oracle x/86/Linux DB2 Power/AIX Source and target platforms changed as does the database


Database upgrades can also be part of a cross-platform migration. They’re not the same type of upgrade you’d do if the source and target platforms didn’t change, even though some clients call this process a migration (that is, migrating from Oracle 10.x to Oracle 12.c).

We use automated scripts to assist with the collection of key database metrics and a variety of IBM and vendor-supplied tools to assist with the migration process. The XenoBridge database migration tool is an IBM asset, and our preferred tool for most migrations except for those where the database is too large and cannot be migrated within the allotted outage window. In those situations, we have several replication tools that can be used.

XenoBridge has many built-in features to ensure data integrity during the migration and provides a validation report when the migration is complete, showing that all of the data from the source database has been successfully migrated to the new target database.

XenoBridge can also migrate from an older database version to a newer version as part of the migration process. For example, migrating directly from Oracle 11 on the source to Oracle 12 on the target. This ability to migrate and update in one step is one of the most attractive features of XenoBridge. Upgrades can affect the application code so some up-front work is required to see if any code changes are needed.

Key considerations

There are a number of metrics to consider when we do a database migration, and we have listed a few of the key ones for your consideration:

  • Source database vendor and version
  • Target database vendor and version
  • Will upgrades be required?
  • Size of the production instances (MB, GB, TB)
  • Available downtime window
  • Location of the source and target systems and connection speed between them
  • Number of databases to be migrated
  • Availability of a test plan

Testing with mock migrations is still key

Database migrations use the same “mock/test” migration process described in my previous blog for ISV migrations. All databases will go through multiple mock migrations, with ample test time in between to thoroughly test the database prior to going into production on the new target systems. It’s unlikely, after the mock migrations, that something will cause the production migration to have problems, but if we suspect a problem, we simply stop the migration process without harming the original source database.

The key points related to database migrations

  • All database migrations, regardless of size, utilize the same basic process.
  • We use automated scripts and tools that reduce risk and cost.
  • Mock migrations will ensure a database has been thoroughly tested before cutover.
  • The migration can be stopped and started over if a problem is suspected without fear of corrupting the original source.

As always, working with consultants who have years of experience doing these migrations is the best way to reduce risk. Reach out to IBM Systems Lab Services Migration Factory if we can help with your next project.

What’s next?

In upcoming blog posts, I’ll talk about some of the other common worries we see—worries about how much a migration will cost and how long it will take, as well as how it will affect the company’s operations and employee skills. Please stay tuned!

Thanks to Rick Murphy and Mark Short for their contributions to this article.

Senior Technical Solutions Manager, IBM System Lab Services Migration Factory

More Services stories

Pushing new industry standards with SAP HANA on IBM Power Systems

At IBM, we believe that collaboration is everything, which is why we are thrilled to announce that we were named SAP’s Infrastructure Partner of the Year. Our collaboration runs deep – IBM and SAP have been driving innovation together for more than 45 years and, together, our two companies are innovating with the goal of […]

Continue reading

How to choose the best IT infrastructure for SAP HANA

As companies face the looming 2025 challenge to migrate to SAP HANA, many leaders are wrestling with the decision to deploy HANA appliances, move to SAP HANA Cloud or stay put on their current database stack that they have spent years investing in to their unique environments. IBM has worked with many clients who have […]

Continue reading

Human capital development: An investment that can pay off

Top-performing companies recognize not only the importance of their people but also the need to provide the right skills to enable their employees. Seventy-one percent of CEOs surveyed cited human capital, ahead of products, customer relationships and brands, as the leading source of sustained economic value, according to a recent study from IBM. Eighty-four percent […]

Continue reading