While sometimes warranted, changing databases is a huge undertaking for almost any enterprise. An IT department embarking on such an endeavorshould plan for a major upheaval, with sizeable up-front costs, a host of compatibility issues and the need to retrain key employees. Still, some companies seem to be doing it. A recent IDC report showed that sector leader Oracle is losing market share to rivals IBM and Microsoft.
Gartner analyst Betsy Burton said true database migrations, in which information on an existing system is moved to a new database, are rare. What is more common is a piecemeal approach, with corporations choosing to set up multiple databases from multiple vendors.
“I don’t see a lot of people unplugging leading vendors like Oracle,” Burton told the E-Commerce Times. “But I’d say 90 percent of the organizations out there now work with multiple databases anyway. A lot of clients that I work with think it’s important to have alternatives to Oracle for negotiation purposes.
“It [says] to them, ‘See, you’re not the only game in town,'” she added.
Avoiding Vendor Lock-In
In the past, so-called vendor lock-in, in which a company becomes dependent on a single database because of a specific application it runs, was a major impediment to database changes.
But the situation has changed in recent years. While analysts say that making heterogeneous systems work together is still a major issue, the increasing sophistication of the application integration industry, along with a proliferation of open-source products that aim to be compatible with anything, has helped make this hurdle one that can be cleared.
So, although a database changeover is still expensive and time-consuming and often puts strain on IT departments, Burton said the cost can be justified if the move supplies additional productivity or other gains.
Proceed with Caution
In fact, database migrations can produce long-term payoffs. For instance, Burton said that IBM has offered incentives for its DB2 product to customers who migrated from Informix databases.
Other advantages may include additional security, Siebel Systems CIO Mark Sunday told the E-Commerce Times. He notedthat, regardless of potential advantages, the decision about whether to break free of an existing database is not to be approached lightly, particularly when the investment for large companies may be in the seven-figure range.
As a result, the value proposition “has to be pretty overwhelming” before most enterprises will consider setting aside a central piece of computer infrastructure, Sunday said. Instead, most database moves are taking place as part of larger strategic plans and in smaller steps.
“We’re in an environment where slow, measured movements are favored over big, bold ones,” he explained.
No Quick Fix
If an enterprise does choose to undertake a database switch, whether incremental or massive, it should be prepared for the long haul. Experts say a changeover can consume an IT department’s entire focus for weeks or months, making some outside help a must, since more hands will mean a shorter time frame for implementation.
One good ingredient is a well thought-out but flexible calendar. Although crash-style changeovers can be accomplished in a couple of weeks, enterprises should allocate a few months to such a project if they wish to do it right, according to Roger Smith, CIO of IT provider NCS Technologies. He also advised leaving ample time for testing and building in extra time for surprises.
Overall, to ensure a smooth transition, IT staff should start by drafting or mapping a process for the switch and making sure all parties impacted are aware of the plan well in advance. This may be more complex than it sounds, since coordinating a changeover could require working around projects currently running on the database to be replaced.
Ready To Rewrite?
For example, a mid-size corporation moving from an Oracle database probably would have to rewrite dozens — at least — of proprietary SQL queries in order to ensure that all of its data migrated successfully.
“The proprietary stuff is what really keeps more people from changing,” Gartner’s Burton said, explaining that the manual labor involved can seal a decision not to switch databases. Even those services that claim to automate the process still often require line-by-line coding, she added.
The bottom line, Burton said, is that the process is expensive and time-consuming, but “if there are gains to be had in terms of productivity — obvious and immediate ones — then it might be worthwhile.” By carefully planning technical work, companies should be able to drastically increase their odds of achieving a smooth transition and avoiding unexpected delays.
Loading ...
I must dispute the assertion that IBM is offering incentives to the Informix community to migrate to DB2. I AM very active in the user group community of Informix and I have never even heard a rumour of such a thing.
I agree with the above post. Which of the "lock-in" vendors are you shilling for? If TCO is the issue what about a contracted conversion specialist and PostgreSQL… Firebird… Berkeley DB… etc?
Even redesigning a database in the same program can be a lengthy task. The DBA here before me designed a mess of a database and it has been 2 months just designing and importing. Working on the in-house programs now.
The timeframes listed in this article are in my opinion **very** optimistic. Our government agency is in the process of a database change from an old and little-known DBMS called Unify to Informix. The process has been ongoing since 1997 and is expected to continue for at least two more years. At this time approximately 1/3 of 94 distributed databases have been upgraded from embedded-C/Unify to Informix with Java web. The applications converted consist of over a million lines of C-code, converted (with enhancements and extensions) to 1.6 million lines of Java. Bottom line: Don’t underestimate the level of effort to change databases. Unless it’s a straight conversion with no enhancements, extensions, or any other kind of modifications anticipated …. it is a very long-term, expensive, and tedious effort.
Migrations need not be either expensive or excessively risky. Companies such as IBM with many years’ experience in performing these migrations can aggressively address the cost of the migrations while keeping customer risk to very manageable levels. It can be a huge undertaking, true, and there can be retraining issues in those I/T shops that have singlemindedly focused on a single vendor’s product, but the up-front costs need not be massive or insurmountable and compatibility issues can be managed – along with a host of potential technical problems – by skilled conversion specialists.
Hiring an outside conversion team can keep a company’s I/T department from becoming locked up over conversion issues for many months at a time.
Database conversions are not a long-term skill needed in any I/T shop. A database conversion is like an automotive tune-up. You don’t usually do it yourself, because it can be messy and there are lots of technical details to attend to – details we don’t need for our "normal" day-to-day lives – but you can hire qualified outside help and trust them to get the job done for you. Who needs to take the classes and be an apprentice to a mechanic when a $65 tune-up is available just down the street?
Conversion specialists have a whole bag of tricks ready to go to work for the customer – including pre-developed custom SQL function replacements for a variety of databases, such as Oracle and Teradata.
The bottom line is that database conversions need not be either expensive or time-consumming, and if there is a need to reduce the total cost of ownership to cut I/T operating costs, there is no real barrier to taking action to save money now.
Your article spreads unnecessary fear, uncertainty, and doubt at a time when companies need to take aggressive action to cut their costs.
Sorry, Keith. Although you have an interesting article, some of your facts are particularly suspect. Which of the "lock-in" vendors are you shilling for?