March 1, 2023
Moving to the cloud, changing service providers, upgrading your host hardware, consolidating data centers, or switching to new software — they all might necessitate a database migration.
Moving a database is not a task to be taken lightly, but it can lead to more centralized and efficient management, lower storage costs, and/or reduced license requirements. To minimize your risk and downtime, follow these database migration tips.
Before embarking on any migration work, you’ll need to catalog your database servers.
For each database, note whether you are read or write heavy. Decide if any downtime is acceptable, and if so, how long that downtime can be before it negatively impacts users or your organization at large. Check for any integrations or features in use, like disaster recovery or high availability.
Is the database server linked to Single Sign On? Does it have Application-to-Database dependencies? Use scripts to identify login information and machine identifiers for applications connecting to each database and catalog accordingly. Some applications may need to be updated to a new version along with the databse. Finally, perform a performance analysis if you already haven’t so you have a base measurement.
Decide who needs access and how your current database platform enables — or is unable to meet — your goals and requirements around accessibility, functionality, and compatibility.
Standardize your data now as long as you’re digging around in the database. Deduplicate (which can reduce costs as you migrate), check for outdated information or any data types that do not belong in this database, and archive old data that will not be used.
Based on the performance analysis and information gathered in step one, you should have a good picture of the specifications required for your new database. You’ll also need to calculate costs for licensing of any new software, whether apps or database platforms. Consider the long-term effects of support and business impact as you migrate and troubleshoot. Will you add or continue disaster recovery / high availability? Those windows may affect when you can successfully migrate, and the tools you are using may need to be reconfigured or updated for the new database.
Be sure to leave enough time and resources for testing and troubleshooting throughout the migration process. Each application that is dependent on your database must be tested before it moves to production.
You may want to prioritize specific databases or even specific entries that are critical to your business. Ranking your data based on importance is one step that could be taken during the information gathering / categorization phase, if it is not already built into your data management policy.
Keep all stakeholders informed on the progress and potential disruptions to their daily work. Prepare any necessary trainings for use of new platforms.
Double check that data is compatible with the destination platform, whether you are moving it directly or extracting, transforming, and loading (ETL). Enter the source database information into the target and vice versa and replicate your data. Here is where you’ll use one of several migration methods like simple backup/restore process (restoring to the new environment), detach/attach data, manual schema building with data import, log shipping, or a wizard/purpose-built tool.
These tips are generally common sense, but it is worth the additional time and work to follow all of them when moving a critical multi-terabyte database. Be sure to rollup updates and hotfixes, run database checkers, and verify your backup/DR solutions before migrating; and after your job is complete be sure to thoroughly verify integration with applications. And of course don’t forget to decommission your old VMs or physical servers! Otherwise your cost/performance savings will be largely for naught.
.png){kind=logo}
We're here to help you tackle what's next in your digital journey.
