Database Migration Vendor example essay topic

Building a Case for Database MigrationContentsSection Title Page 1.0 Purpose 3 2.0 Why Do Companies Migrate? 3 3.0 What Inhibits a Decision to Migrate? 4 4.0 The Migration Process 5 5.0 Competitive Overview 6 6.0 Summary and Conclusion 6 1.0 Purpose This document provides a supporting framework for enterprise IT departments to make business decisions on how best to migrate from one database system to another. It is written as a guide to structure a business case for presentation to upper level management. 2.0 Why Do Companies Migrate? Given the critical nature of database applications in the life of a business, it is often hard to believe that a company would choose to jeopardize its operations by moving to another vendor's database system.

Indeed the fact that some business applications were written many years ago and were modified over the years by personnel who may no longer be in the company, it is understandable that there is not only trepidation about making a move to a new database system, but also there may be a high cost associated with the mechanics of the migration. But the fact is that companies vehemently oppose being trapped on one vendor's products because there can be serious consequences such as higher total cost of ownership (TCO), less scalable solutions, a lack of developers, and more. But there are also issues about the flexibility of the business and how it can be negatively affected by the inability to move quickly because of being trapped on a single database platform. The key reasons why companies migrate are: a) Expensive maintenance contract renewals from a vendor that force a decision to pay or migrate to a less expensive platform. b) Expensive upgrades by the vendor forcing you to either upgrade or migrate. c) Pressure to create a consistent face to a company's customers following a corporate merger drives the migration of one company's applications to the database platform of the other company in the merger. d) Opportunities to leverage On-Demand or Service Oriented Architectures (SOA). e) Pressure to more rapidly improve or update applications in a dynamic marketplace. One impediment to this is the limited availability of applications development personnel, internally or externally, for some database systems (e.g. Oracle). A natural solution is to migrate to a database vendor that has a strong development environment with many certified developers such as.

NET and SQL Server. f) Pressure to drive TCO down often results in a drive to consolidate platforms, management systems and personnel. A major aspect of this is the migration of applications to fewer server platforms or to less expensive server platforms. g) Pressure to rapidly add new revenue producing customer service applications usually means that new applications need to be deployed on existing DB infrastructure without need to rewrite the application. In addition, this migration driver relies on the existing DB infrastructure being very scalable and this may drive a company to migrate to a new server platform entirely. It is very important to understand the key drivers to migrate, because this gives you insight to the form of the value proposition you ultimately use to win approval from executive management for the entire project. 3.0 What Inhibits a Decision to Migrate? What are the key things to consider when pushing a decision to perform a database migration project?

Just as important as it is to understand the drivers for migration, one must understand the inhibitors to migration. Understanding these inhibitors and the degree to which they concern the executive management of the company, is the key to finding the right migration vendor as well as selling your concept up the decision chain. The key inhibitors are: a) Cost of manual migration is high because of the sheer volume of code requiring conversion, difficult conversion cases due to differences between database systems and the need to perform testing of the converted code to ensure correct conversion. Look for a solution that automates much of the labor intensive work in the migration process allowing the IT staff to focus on the most difficult conversion choices. b) Time to complete manual migration is another serious issue because companies need to ensure continuous operation, or they need to deploy a new application quickly or they have a need to make a decision on a contract renewal. Look for an automated solution that performs the bulk of the conversion in a matter of hours or days depending on the complexity of the conversion and the number of databases needing conversion. As a result, the time to complete a migration project is primarily the time it takes to perform integration and test and is a small fraction of the time it would take without automation. c) ROI on the migration project is a question companies have to deal with no matter what the reasons for the migration.

But given the need for new hardware, software and the effort to migrate, all coming from different vendors, the ROI can be unclear. Look for a solution that provides an on-demand assessment of the nature of the migration. It must estimate the total manual work required and the level of automation available with the vendor's migration tools on your specific databases. As a result, it would be much easier to perform the required ROI studies. d) Disruption of business during the migration is a concern. Look for a solution that can be used on a copy of the database. A migrated version can be created, integrated and tested independently of the running database until a cut over is deemed appropriate. e) Database systems can be radically different because of proprietary extensions to the basic standard database languages (e.g. SQL) and may cause issues in performance or accuracy of database queries.

Look for a solution that provides a reliable automated conversion virtually eliminating errors during the migration process. In addition, look for automated testing integrated into the migration tool set to ensure the conversion works properly. 4.0 Building the Case for a Particular Migration Approach There are many aspects to consider in a database migration beyond the migration itself. Preparing for the migration requires consideration of and executing plans for database backup, parallel operations, application replacement, and often, database cleanup. Following the migration there are the issues of migrating users and business processes to the new system. These can be significantly large efforts in and of themselves.

In fact, it may be a decision to do some of these tasks that caused the issue of whether or not to migrate to another database system to come up. Nonetheless, when considering the actual migration tools and process and the cost-benefit analysis needed to make the decision about which system to migrate to and which vendor to use, the costs of these important but peripheral activities can confuse the situation. Fortunately, one can separate the migration tools decision from these issues. The end-to-end database migration process can be viewed as consisting of 7 phases as follows: 1. Assessment Phase - each database and application is evaluated to determine the number of stored procedures, functions and packages and assess the level of complexity of each object. Estimates are then made of the work required and a project plan is created.

A GO-NO GO decision is usually made at the end of this phase. 2. Schema Conversion - database schema is converted from one database system to another with adjustments made to accommodate database system differences. 3. Data Migration - data is migrated onto the new server in accordance with the newly converted schema.

4. Business Logic Conversion - each object of the business logic is converted from the original dialect to the new database system's dialect. 5. Testing of the converted code - the converted business logic is tested against the newly migrated data to ensure that the results are identical to the pre converted code. 6. Application Migration - application logic is converted typically by replacing the original embedded database system calls with calls consistent with the new database system dialect.

7. Testing, integration and deployment - the converted code is integrated with the overall system and tested extensively under load to ensure it is ready for operational deployment. Ensure your migration vendors provide you a proposal that includes all of these phases and that the time to execute, the costs associated with and the guarantees for each phase are spelled out in their proposal. In addition, you need to ensure a complete understanding of the database permissions required by the vendor and that corporate security is involved in planning physical and logical access to meet the vendor's needs as while maintaining corporate security policies. 5.0 Competitive Overview As an aid in considering solutions for database migration, the following table summarizes the competitive landscape in database migration tools. The top row are the migration process phases and the table shows what companies have tools or consulting services that address each phase.

Phase Company Assessment Schema Data Business Logic Application Testing Conformance DB Best Y Y Y Y Y Y Y AdventNet Y Y Inspirer Y Y Y Artin Soft Consulting Informatica Y MS DTS Y Real Soft Y Y Embarcadero Y Quest Y Sybase Y CA Y ETL Vendors Y As of the completion of this paper, DB Best was acquired by Microsoft Corporation. 6.0 Summary and Conclusion There are many reasons to move from one database system to another. The process is complex and involves many important activities peripheral to the formal migration itself. A methodology was presented to analyze the formal database migration and place it in the context of an enterprise decision for making the move. The methodology focuses on what specific issues need to be addressed by a database migration vendor so that a complete analysis can be presented to executive management. Finally, a competitive overview is presented to assist IT personnel in identifying sources of database migration tools.