In an organizations’ IT modernization journey, database migrations are often considered as easy tasks that can be completed with a quick turnaround time. Database modernization offers many benefits, however the perception of the migration journey being straight forward and effortless is a myth that is soon broken as soon as the migration journey begins. With adequate planning, tools and migration strategy, this transformation will become a well-managed execution within the required timelines. Through this document, we would navigate through the various myths of Database migration highlighting the common pitfalls and how the same can be managed better. The steps will also highlight the effort intensive activities visà-vis tool enabled activities to provide a perspective on efforts involved while migrating databases.

Key drivers for any database migration are:

• Digital transformation of Applications
• Database consolidation
• TCO (Total Cost of Ownership) reduction through open-source adoption.
• IT Operational efficiencies through managed services - Cloudification

Database migrations fall into two main initiatives:

1. Heterogenous migrations (Migrating from one Source database to a different database, Platform migration).
2.  Homogenous Migrations (Lift and Shift of databases)

 Misconceptions and Facts on Database Migrations Myth1: Database migration can be carried out as an infrastructure exercise.

Fact: Database migration cannot be carried out as lift and shift from source to target. A proper due diligence of database and application landscape need to be undertaken. An automated discovery using various tools reduces the effort up to 60%. Following impacts need to be analyzed:

• Database consolidation opportunities
• 6R (Rehost, Re-platform, Repurchase, Refactor, Retain, Retire) assessment approach to DB modernization to finalize the migration strategy.
• Application impact analysis and move group planning.

Myth2: Database migration effort is determined by the size of Schema

Fact: The database migration efforts are driven not only by the number of DB objects and data volume but primarily by the complexity of conversion of the DB program objects. When the databases have been in the enterprise over decades, in addition to data, there is usually complex business logic embedded in the database program objects. No migration tool can provide One Click 100% automated conversion. The database migration effort is primarily driven by:

• Unsupported Datatypes and functions, table Null values, Partition type and Indexes.
• Heavy business logic implementation in DB Program code (Stored Procedures, Packages, Views, Triggers, Functions) using proprietary features of source Database
• Usage of Non-ANSI SQL and dynamic SQL
• Transaction management and Exception handling.
• Embedded SQL in application and usage of native database APIs like CTLIB, DBLIB, OCI etc.
• Performance optimization ( Due to the fact : Change in Database Engine)
• Functional validation between source and target.
• Remediation and Testing of Integrations.
• Parallel Run (Due to zero down time / other business requirements)

Myth3: Applications require only database driver changes to make it work

Fact: Application remediation is not only about database driver changes. Application remediation is largely a manual effort, as no tool can effectively identify the database touchpoints and modify them There are multiple factors as listed below that determine the complexity of Application remediation effort:

• Application technology version and its compatibility with target.
• Availability of database drivers for target databases.
• Usage of 3rd party libraries that may not be supported on target.
• COTS applications compatibility with target.
• Usage of ORM (Object-Relational Mapping) frameworks vs usage of embedded SQL
• Application redesign

Myth4: Data migration is all about lift and shift of data to target

Fact: Although automation plays a key role in data migration there is still a manual effort up to 10% to carry out a successful data migration. The effort is focused on the following areas:

• Adequately profile source data to map right datatype on target to avoid data quality issues and data loss.
• Downtime requirements and Infrastructure availability to plan data migration.
• Selection of data migration tools
• Platform changes to account for Indianness changes to data.
• Data consolidation for one-many/ many -one database migrations.
• Data co-existence during parallel run.
• Data validation

Myth 5: A Migration Project requires only white box testing

Fact: End-to-End Testing is integral to the success of Migration project. Data validation tools, Query Validation tools, Schema validation tools and other testing tools automate the testing by 70%. Some key testing activities to be carried out:

• Functional and Performance baseline on source environment
• Post migration testing to compare results against baseline.
• Performance testing and Tuning
• Pre-prod parallel testing for critical workflows
• User acceptance testing
• Post implementation validation.

Conclusion

Though migration tools play a vital role in database migrations, it does not help to carry out a 100% automated migration. A ‘One Size fits all’ approach cannot be adopted, and level of manual effort required is determined by the factors we have seen above. TCS with its expertise of migrating hundreds of databases has perfected a 5D methodology (Discover, Design, Develop, Deploy, Decommission) that provides a wholistic approach with time tested steps that will ensure a successful database migration. The 5D methodology is well supported by automation (Developing in house tools and assets, enhancing tool as the db migration project progresses) to accelerate the migration in a consistent and accurate manner and achieve the expected automation in database migrations.