Migrating to SQL Server from another Database platform has a number of considerations
1) Create an inventory of existing applications. Separate into off-the-shelf and in-house
2) Ensure sufficient licenses on existing database platform can be retired to enable maintenance costs to decrease.
3) For off-the-shelf .
Does the vendor support SQL Server?
If they don’t is there a timeline to introduce SQL Server support?
Usually vendors won’t support an application if the database platform is not certified. Application functionality may rely of database specific functions. Migrating would require full-compatibility analysis.
Applications relying on built-in database administration can be more complicated to migrate
4) For in-house:
Which existing features aren’t supported by SQL Server?
Discuss with SQL Server Consultant , the level of risk associated with migrating onto SQL Server from another platform.
Design a Proof of Concept plan . The key question should be “which features are not compatible?” with a follow-up question “how much work/cost is required to redesign/program?”
5) Two-tiered/three-tiered. As a “rule of thumb” I’ve found three-tiered applications easier to migrate onto SQL Server. Two-tiered applications often have all the logic in the sql language layer , resulting in complex objects , difficult to untangle.
6) Business Case. Migration is an expensive task. Creating a case to justify switching to another database platform is important. Complete a full cost-analysis and present to management.
Author: Jack Vamvas (http://www.sqlserver-dba.com)
