How To Test SQL Server Migrations Using Log Shipping

What is the key to SQL Server upgrade project success? - Preparation.

Prep work is going to take 80-90% of the time.

SQL Server installation and setup are going to be an easy part.

Why is preparation important? Because to do this right – you only get one try!

And rollback is nasty - a ton of downtime. The manager leading the project will not look very good.

Backstory

Some time ago, someone asked me how to test the SQL Server migration with minimal downtime and the least impact on customers.

In this example we're using a database (DB) named InQuire_DemoA on Source Server.

Step-by-step guide

1. We will back up and restore InQuire_DemoA to the Destination Server with precisely the same name: InQuire_DemoA.
   This DB is what you will test against.
   That way, you have less to reconfigure on your end.
   So you test against the same DB in the new location (NY as an example) as you have on Source Server (CA as an example).
2. At the same time, we will back up and restore DemoA from the Source to the Destination Server and configure log shipping from CA to NY.
   So DemoA will be log shipped from the Source to the Destination Server as DemoA_red9. This DB will be a read-only copy. All data, stored procedures, table changes, etc. will be captured from the Source to the Destination Server.
3. You will do testing on NY. After testing is complete and (typically) during the migration window, we will drop DemoA (test DB), rename DemoA_red9 (read-only) to DemoA and set DemoA live. This now becomes your production DB.

Why log shipping?

• It can minimize downtime, even for large databases.
• Log shipping may not be as new and shiny as availability groups, but it has very few blockers for implementation. After you get it running, it doesn't add any additional workload to your legacy databases.
• Log shipping also supports a mix of SQL Server versions and editions like Standard or Enterprise, which other migration options lack.
• Log shipping is easy to set up, made even easier by the dbatools.

Conclusion

1. Database upgrades and migrations happen every 3-5 years. Or less.
2. If you are using your internal staff, those people wouldn't have done this task often.

It's essential to find trustworthy experts with current knowledge and experience to ensure your Migration or Upgrade project is done right.