Why Database Manager makes a decision to migrate data between different database platforms? Or to migrate from existing database to a completely new platform?
The first reason that comes to mind is outgrowing the existing system. Let’s say you started a business using ordinary MS Excel spreadsheets with several calculated fields. Or Microsoft Access is used for storing simple set of data. Everything works great until your company becomes bigger and more much data should be involved in business processes. Generally MS Access is limited to 2 Gb database size and supports 10-20 concurrent users. So it cannot be considered as a solution for a heavy access load, web access or doing data warehousing of every transaction over the next 10 years.
At this point DB Manager needs to step in and look ahead to a solution that fits expected database requirements the best.
If you are stuck to Microsoft technologies consider the following solutions for database migration/ synchronization:
Converters for Non-Microsoft database target platforms are available as well:
- MS Access to MySQL
- MS Access to Oracle
- MS Access to PostgreSQL
- MS Access to Firebird
- MS Excel to MySQL
- SQLite Export/ Import tools
Another reason that forces DBA switching from one DBMS to another are license fees, some of the DBs are too good in terms of performance but they cost you dearer.
The tools listed below assist to migrate data from proprietary dbms to open source database engines.
- SQL to MySQL
- SQL to PostgreSQL
- SQL to Firebird
- SQL Azure export software
- Oracle to MySQL
- IBM DB2 to MySQL
On the contrary, if you know that volume of managed data will not rise much or you just need using partial set of data from huge server database there is no need to utilize expensive SQL Server database power. In this situation it will be enough using databases like Access or SQLite.
Resources required to run the software efficiently are vary from one db engine to another. For example performance may be improved greatly by moving from SQL to PostgreSQL , which demands significantly fewer system resources.
The developer who wrote the original system isn't available.
The cost of developers is too much or they're not available. Try to find a person who knows Clipper and see how much they cost.
The code is unmaintainable. If there is no documentation and no in-line comments then there is just a little chance that anyone other than the original developer can maintain it. Though code itself may be extremely efficient. In most cases it is easier to completely rewrite this code for a new DBMS than support obsolete DB.
The software is no longer supported. There are many dead platforms out there that would still perform their tasks today until you don't need to upgrade the OS or hardware.
For example Microsoft doesn’t plan supporting MS Visual FoxPro users after Jan, 2015. There will no any further updates or patches for FoxPro anymore. So it is a right time to consider exporting outdated FoxPro databases to other up-to-date database engines.
Read more about available targets for FoxPro migration
Company has made a strategic decision to use a specific DBMS for all projects for consolidation on a set of skills/ tools. Or new code released by the vendor requires a specific database. Sometimes it would be a political decision to centralize entire shop on one-vendor products, e.g. Oracle, Microsoft or IBM, shedding Products from competing vendors completely.