🥇Migrating backup data from a new version of MS SQL Server to an older version

Background

Once, to reproduce a bug, I needed a backup of the production database.

To my surprise, I encountered the following limitations:

The database backup was made using version SQL Server 2016 and was not compatible with my SQL Server 2014.
My work computer had Windows 7, so I couldn’t upgrade SQL Server to version 2016.
The supported product was part of a larger system with a heavily interlinked legacy architecture and also accessed other products and databases, so deploying it on another station could take a very long time.

Given the above, I concluded that it was time for non-standard workaround solutions.

Data Recovery from Backup

I decided to use a virtual machine Oracle VM VirtualBox with Windows 10 (a test image can be obtained for the Edge browser from here). SQL Server 2016 was installed on the virtual machine, and the application database was restored from the backup (the instruction).

Setting Up Access to SQL Server on the Virtual Machine

Next, it was necessary to take some steps to enable external access to SQL Server:

For the firewall, add a rule to allow requests on port 1433.
Ideally, access to the server should not go through Windows authentication but via SQL using a login and password (it's easier to set up access). However, in this case, do not forget to enable SQL authentication in the properties of SQL Server.
In the SQL Server user settings on the User Mapping tab, specify the user role for the restored database as db_securityadmin..

Data Transfer

The actual data transfer consists of two stages:

Transferring the data schema (tables, views, stored procedures, etc.)
Transferring the actual data.

Transferring the Data Schema

We perform the following operations:

Select Tasks -> Generate Scripts for the database being transferred.
Select the objects needed for transfer or leave the default value (in this case, scripts for all database objects will be created).
Specify the settings for saving the script. It’s most convenient to save the script in a single file in Unicode encoding. This way, if something goes wrong, there’s no need to repeat all the steps.

After saving the script, it can be executed on the source SQL Server (the older version) to create the required database.

Attention: After executing the script, it is necessary to check the compliance of the database settings from the backup with those from the database created by the script. In my case, the script was missing a setting for COLLATE, which led to failures during data transfer and required complicated workarounds to recreate the database using the augmented script.

Data Transfer

Before transferring data, all constraints on the database must be disabled:

EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

Data transfer is carried out using the data import wizard. Tasks -> Import Data to the SQL Server where the database created by the script is located:

We specify the connection settings to the source (SQL Server 2016 on a virtual machine). I used Data Source SQL Server Native Client and the aforementioned SQL authentication.
We provide connection settings to the destination (SQL Server 2014 on the host machine).
Next, we configure mapping. It is necessary to select all not read-only objects (for example, views do not need to be selected). As additional options, you should select "Allow identity insert", if such are used.
Attention: if when trying to highlight multiple tables and set their property "Allow identity insert" the property was previously set for at least one of the selected tables, the dialog will indicate that the property has already been set for all highlighted tables. This fact can be confusing and lead to transfer errors.
We start the transfer.

We restore constraint checking:

EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'

If any errors occur, we check the settings, delete the erroneous database, recreate it from the script, make corrections, and repeat the data transfer.

Conclusion

This task is quite rare and occurs only due to the above-mentioned constraints. More often, the solution involves upgrading SQL Server or connecting to a remote server if the application's architecture allows it. However, no one is immune from legacy code and poorly executed development. I hope you won't need this guide, but if you do, it will help save a lot of time and nerves. Thank you for your attention!