Yes, it's true - all database vendors offer ways to migrate their databases from version to version. However, I see more and more people choosing data replication instead. Why? I'll answer that in this post. More importantly, I'll provide tips for those just starting out.
So... the most common reasons I hear for choosing replication are these:
- I want to test my apps on the new database using a live feed of data from the old database
- I want to migrate tables one application at a time.
- I'm on an older version and I want to skip over any versions between mine and the latest version.
- I don't want to migrate everything at once, especially if something later forces me to fallback to the previous release.
- I want to migrate from my old vendor to DB2.
In other words, one major undlying theme here is flexibility that traditional migration methods don't always allow.
My Nine Tips
To be clear, while just about any replication technology can be used for database migration, my list has a Q Replication flavor to it. That's the technology I see people using most often. They choose it for its conflict detection and resolution as well as its excellent scalability
for low-latency and high volume replication.
Tip 1: Forget 'Migration', Think 'Replication'
Face it. Some people have bad experiences with software migration. I'm one of them :) If you are, too, don't let that make you think replication is somehow different once the word migration is thrown in. It isn't. A migration scenario is hardly different from any replication scenario where you want to offload work to another database or balance workloads between databases. If you view it this way, my take is you'll be less apprehensive and figure out what you need to do faster.
Tip 2: Determine Which Type of Replication You Want to Use
Unidirectional (one-way) or bidirectional (two-way). Some customers prefer one-way because it's a simpler configuration to set up and manage. However, if you decide you need to fallback to the previous release, you may find it a challenge since the old database won't have changes made to the new database. Contrast that with two-way. Two-way keeps both sites in sync, making fallback much easier.
Tip 3: Avoid conflicts
If you choose two-way, a conflict can occur when two sites change the same row at roughly the same time. Q Replication helps you manage this through conflict detection and resolution. However, if you can plan your application and user workload to avoid conflicts, you should save yourself the trouble of having to manage conflicts. By the way, this is the same recommendation the Q Replication team has for any two-way replication scenario, not just migration.
Tip 4: Upgrade Replication Before You Begin
If you already use Q Replication with the old database, consider upgrading it before migrating the database. This give you access to the latest enhancements and fixes before you start replicating. This is relatively easy since InfoSphere Replication Server can be be installed completely independent of your old database.
Tip 5: Choose How You Want to Create Objects in the New Database
One possibility for some databases is to back up the old one and restore it on the new server. Another way is to use your own DDL to create everything (table spaces, tables, indexes, etc). You do keep a copy of all your DDL. Right? :) You can also use the replication administration tools. However, I don't recommend these for migration because they do not make an exact duplicate of your source objects. For example, they won't create all source indexes on target tables, just the primary key used by replication.
Tip 6: Test Your Apps with a Live Feed of Data from the Old Database.
Pretty much everyone tests to make sure apps run fine on the new database. Replicating data keeps the new database current with the old and may increase your comfort level with how well the new database works.
Tip 7: Migrate Users and Apps in Subsets Rather Than All at Once
For example, migrate read-only users and apps such as reporting first. These are likely the easiest to move since they don't make changes that could conflict with updates from apps on the old database.
Tip 8: Migrate Independent Apps at Different Times
By 'independent', I mean they have no overlap in data they use. For example, an HR app may have no overlap with retail web apps or production manufacturing apps. That gives you the option of migrating one app's tables without affecting your other apps. If you hit problems, this approach can limit the number of problems you have to deal with at one time when compared to migrating all apps at once.
Tip 9: Start Subscriptions in Smaller Groups Rather Than All at Once
I hope you're noticing a trend here :) I feel it's almost always better to manage both replication and migration in small chunks rather than doing everything in bulk. So, for starting subscriptions, consider starting 100 at a time, get through 100, and then start the next 100.