As newer versions of SQL Server are released, we plan implement to upgrade to higher versions and during this process, we may also upgrade to new and powerful servers with better hardware and latest Operating System. Also, as part of data center relocation, we migrate the SQL Server instance from one server to another server in new data center. The process of migration involves lot of steps and need to plan and implement the steps so that, at end of migration, we have SQL Server instance running without any problems.
This article covers a scenario where we want to migrate SQL Server instance from one server to another server. This is applicable for scenarios where we are migrating between servers which have same versions of SQL Server installed or new servers having higher version of SQL Server. Goal of the migration is that there is minimal downtime when we switch the applications from old server to new server.
Below are the high level steps involved in migration.
– First, we need to perform these steps on test server, so that we can find the issues that can arise during the migration before hand and also to test if the applications work without any problems after migration.
– If we are migrating to a higher version of SQL Server, then need to document the issues that can arise with the migration by running Upgrade Adviser and prepare documentation with remediation steps to fix those issues as part of the migration. If we are migrating to new server with same version of SQL Server, then no requirement of upgrade adviser.
– Install the required version of SQL Server instance on the new server.
– Apply latest Service Pack or Cumulative Updates.
– Script logins from existing server and Create those logins on the new server.
– Script all the jobs on existing server and create them on the new server, keep them disabled. Create maintenance plans on new server similar to existing server.
– Configure Database Mail if used.
– Create any linked servers if required.
– Configure SQL Server settings like Max Server Memory, MaxDoP, backup compression settings, etc on the new server.
– Configure OS or Network settings on new server like Lock Pages In Memory, Perform Volume Maintenance Tasks, etc.
– Backup all User databases on existing server, copy the backups to new server and restore them. Document the time it took for performing backups, copying backups to new server and for restoring of databases.
– Fix Orphan Users for all user databases.
– Enable backup and maintenance jobs like rebuild index, Update stats, etc on new server.
– Change the compatibility level of user databases to latest version(If migrating to higher version).
– Perform Application testing to make sure the application is working without any problems and performance is acceptable.
– Once, everything looks fine and got permission to move ahead, plan for the Go-Live of new server.
– Our goal here is to have minimum downtime during the Go-Live process, so we need to either setup Logshipping or Database Mirroring between existing and new servers.
– Configure Logshipping from existing server to new server for all user databases and make sure backup, copy and restore jobs are running without any issue.
– Before Go-Live, make sure Logins and jobs are same on both the existing and new servers.
Start of Down Time
– Disable all jobs on existing server.
– Run logshipping backup jobs on existing server, once it completes successfully, disabled the job.
– Run logshipping copy jobs on new server, once it completes successfully, disabled the job.
– Run logshipping restore jobs on new server, once it completes successfully, disabled the job.
– Remove the logshipping configuration between existing and new server.
– Bring the all user databases online on new server by running “restore database databasename with recovery”.
– Enable all required SQL Server Agent jobs on new server and disable the same on old server
– Fix the orphan users.
– Change the compatibility level of all user databases to latest version(If migrating to higher version).
– Point the application to use the new server.
End of Down Time
– Test the Application to make sure it is working as expected.
– Later run rebuild indexes and Update Statistics on all user databases.
– If there are any issues, try possibilities of fixing those issue, if it is taking time and decided to rollback, refer below RollBack plan.
– If no rollabck required, take SQL Services offline on old server and decommission the old server.
– Verify all the user Databases are online on old server.
– Point the application back to old server.
– Enable all required jobs on old server and disable the same on new server.
– Test the application.
You can also use database mirroring instead of logshipping, just replace the steps related to logshipping with database mirroring related steps.
Hope this was helpful.
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.