Migration Pain in the Real World

Database migration is made even more difficult by vendors. Loose interpretation of the SQL 92 standard means data exported from one relational database won't always import cleanly into another without heavy massaging--and not just for the data, but for the admin, too, who after spending long hours writing scripts and suffering failure after failure deserves a massage and a stiff drink.

Moving from one J2EE platform to another would seem like a no-brainer as well. If your code is strictly based on J2EE, it should be no problem, but if you've used the proprietary extensions all app vendors love to provide in the guise of "making things easy for the developer," you are out of luck. Limber up your fingers because you'll be modifying code, a dangerous and tedious cycle that requires rewriting and retesting systems and puts a huge dent in your corporate soda/energy drink fund.

If you're smart, when you do that rewrite you'll look at anything that's vendor-specific and start modularizing it so that it can be easily replaced if you decide to make another change. It's just not cool to rewrite business logic and potentially introduce errors that will take months to debug. And if there's a way to get the job done without using vendor-specific extensions, you can bet I'll use it--even if it means more work up front.

If the only way a vendor can keep customers is to make it difficult to migrate from one product to a competitor's, then it is doing something wrong. I should want a product because it's the best in class or because it offers the best value-adds without locking me in to a particular brand of Kool-Aid. Vendors must keep up with the times and not fall behind the feature sets offered by others. Then they'll have my business.

Post a comment or question on this story.