SQL migration projects in healthcare are known for schedule and budget overruns. Many project managers think data migration is relatively simple until the project starts. Instead of handling an Oracle to SQL Server migration project as a serious undertaking, many include it in a larger legacy conversion project. As a result, many migration projects don’t turn out as planned.
Here are five migration pitfalls and how to mitigate them.
1. Poor Scope Estimation
Migration projects are complicated. You need to document in detail all the data and data structures that have to be converted.
The scope definition will include the full database definition, views, stored procedures, all connected applications, and reporting tools. There’s also a need to get the most knowledgeable in-house personnel to work on the project and assist with quality assurance.
It is essential to have a thorough understanding of the data to be moved. Also, take note of any third-party apps or any requirements that may lead to scope creep or budget overruns.
2. Absence of Centralized Documentation
Documentation for this type of project tends to be quite large. It’s important to have all the documentation for the SQL migration in a single digital file. This can serve as a single source of truth for the entire project.
Some of the aspects of the documentation that may require special attention include:
- Object conversion lists
- Quality assurance by in-house personnel
- Pre and post-conversion system documentation
- Code templates
You can use a project collaboration tool to organize your documentation for effective maintenance and tracking.
3. Inaccurate Calculations
When you use SQL Server Migration Assistant (SSMA) to convert a view in the Oracle database, it will do it successfully. But if it has division calculations, you will get inaccurate answers.
A common occurrence is the truncation of mathematical calculations involving division. For example, if you divide 5 by 4, you may see 1 in your new SQL Server view. On the other hand, Oracle returns 1.25. So what’s the reason for this? It’s SQL Server’s default behavior.
Remember that you have to configure SQL Server to give you the number of decimal places you want.
4. Depending on Emulated Functions
When you use SSMA, it will create its own SQL functions to emulate those imported from Oracle. Obviously, these functions can reduce migration time.
However, there’s a hidden performance cost that you will discover when you run these functions. If you have comparison functions that work on tables or views with millions of rows, you will discover how long it can take to run your view. Converting the same view to use native SQL server functions will produce significant performance improvements.
5. Taking the Least Bid
The databases that healthcare providers use support core operational functions. Migrating a database that supports your electronic health records (EHR), laboratory information system (LIS), or practice management system must be handled with utmost care.
Right from the planning phase till final implementation, you need the help of a specialist who has done several such migrations in a similar setting. You can’t afford bugs, poor database performance, or omissions that will have serious consequences on your hospital’s operations. It is important that you work with SQL Server professionals who are conversant with the Oracle database.
Get Professional Help for Your SQL Migration Project
If you need to convert or migrate data from your Oracle database to SQL Server, contact MediQuant now at 844.286.8683. Schedule a free appointment here, and let’s discuss your migration needs.