Not every organization should dump Microsoft SQL Server, according to Mike Sheffey, CEO of Versora, a migration tools vendor. Sometimes the vendor lock-in is too strong to break without overhauling everything in the enterprise. But when there is a window of opportunity, Sheffey says companies should look into the open source database MySQL. In this four-part Q&A series, Sheffey covers the reasons to switch from and the reasons to stick with SQL Server. He also offers how-to tips on manual and automated migration processes.
What is the No. 1 reason why businesses start looking for alternatives to Microsoft SQL Server?
Mike Sheffey: The No. 1 reason businesses start looking for alternatives to Microsoft SQL Server is cost. IT organizations are becoming more focused on business value and are asking questions: 'Are our software investments beyond our needs? Are there cheaper alternatives which are the right size for our specific needs and do not lock us into a long-term relationship with a vendor?'
Is that reason the best reason to switch? Are there other better reasons?
Sheffey: Though cost and avoiding vendor lock-in are compelling reasons to switch, especially in light of the quality of the MySQL database, there are other important considerations, including security and flexibility or [the need to assume] greater control of their development processes.
What security concerns can cause IT shops to reconsider using Microsoft SQL Server?
Sheffey: Because Microsoft SQL Server is tightly integrated into the Windows platform, it is exposed to Windows virus attacks and, as a result, is a vulnerable database. There have been numerous documented virus attacks on Microsoft Windows, with the worst attacks specifically targeted toward SQL Server.
A prime example is the Sapphire/Slammer worm which exploited a buffer overflow vulnerability in computers on the Internet running Microsoft SQL Server. The worm infected at least 75,000 hosts and caused network outages and such unforeseen consequences as canceled airline flights, interference with elections and ATM failures.
Open source databases, such as MySQL running on Linux, are much harder to attack for a variety of reasons. First, these databases do not run as an administrative user, so even if they are compromised, a virus won't spread as rapidly. Second, since the code is open source, far more developers are looking at it to make sure it is secure. Thousands of database administrators from organizations worldwide using open source databases can contribute security patches more rapidly than a single company such a Microsoft.
Why would an open source database be more flexible than Microsoft SQL Server?
Sheffey: Many companies are finding that by using an open source database, they experience greater control of their development processes when compared to using proprietary software. Not only can the company view and modify the source code to fix bugs and add needed features, they have control over the future development of the code.
After a consultant or vendor has developed a specific open source application for a customer, that customer is free to use a different consultant or vendor for future development, maintenance and enhancements if needed.
If you were a database doctor, what obvious and not-so-obvious symptoms would an IT system demonstrate that would indicate a database change is needed?
Sheffey: For smaller enterprises, a switch is warranted if the cost of the database license far outweighs the salaries of database administrators. Business advantages are in people!
Other indicators are if an organization is forced to upgrade to a newer version of a database or OS in order to see the latest patches; if more time is spent on application maintenance - applying patches, fixing viruses and making sure the system is up -- compared to database queries and getting info onto the database; and if the organization feels that being locked into one vendor compromises or hinders future IT plans or limits the scope of business.
Could you offer some database migration planning tips?
Sheffey: The most important planning consideration is determining whether currently used applications integrate with the new database. In-house applications may need to be partially rewritten. Embedded SQL statements may need to be changed depending on their complexity. Proprietary applications that only 'talk' to Microsoft SQL Server need to be evaluated for necessity and replaced if possible.
In the planning stage, adequate time needs to be budgeted for testing so that there are no hiccups after the migration is completed. Lastly, make sure you don't disable or delete the Microsoft SQL Server database until the MySQL database migration is complete and accurate.