Migration in the context of enterprise and web-based applications means moving from one platform to another.  Database Migrations are particularly complicated as you have all the challenges of changing your software platform, where some old features are missing, or behave differently and some new features are available and you’d like to take advantage of those.

In the world of databases, some developers try to build database independent applications, especially using ORMs (object relational mappers).  On the surface this seems like a great option, build your application to use only standard components and features, and then you can easily move to a different platform when requirements dictate.  Unfortunately things are not quite that simple.

Database independent applications necessarily shoot for the lowest common denominator of all of your database platforms, thus lowering the bar on what high-performance features you might take advantage of on the platform you are currently using.

Here are some scenarios:

1. Building an application which needs to support multiple database backends for customer sites
2. Building an application in dev and test for proof of concept.  May port to an alternate database in the future.
3. Don’t want to be locked into one vendor, but have plans for only one platform currently.

These are all good reasons to think about features, and database platforms from the outset.

For situation #1, you need to be most serious about cross-platform compatibility from the start.  Build modules for each database platform, with platform specific code isolated in that module.  If the particular feature you want to use is available only on one of the two platforms, the alternate platform will have to include its implementation of that feature in the database specific module.  Also by isolating all database specific interactions to one module, you have also put boundaries around that code.  If you choose to support another database platform in the future, you merely need to rewrite that database interaction module.

For situation #2, you would use a similar tactic, but won’t necessarily have to implement all the routines in that module for the alternate platform.  Just keep those features, and differences in mind during the development phase.  Where possible document those differences, and comment code liberally.  This will go a long way towards preparing you if you do decide to go for a different database backend.

In situation #3, this may be more of a philosophical concern at this stage.  Don’t get overly dragged down by this, as it’s hypothetical at this stage.  Sometimes developers labor under this concern from previous bad experiences migrating to a new database platform.  But to some degree this is the nature of the beast.  Database platforms include a myriad of different features, datatypes, storage methods, and coding languages.  In many ways this is where their power lies.

Sean Hull discusses on Quora: What is a database migration and why is it important?

Related posts:

1. Oracle to MySQL Migration Considerations