What do you think is the correct transfer of the 1C SQL database from the old server 2014 to the new 2017?

Question

1C

guys, such a question, we are transferring the 1C application server and SQL database to a new site., everything has already been configured and tested as far as possible, it looks like it will take off rather than not. I restored the database on the new server from a daily differential backup created on the old one. and now the hour H comes and the decision was made to move to a new site, a slight jitters appeared))) and a few questions, so I ask for advice rather than an answer, I collect, so to speak, opinions in order to dispel doubts on how to correctly transfer the database itself:
1. please tell me your opinion about the way to move the database to a new server, which of the options you think is more correct, and maybe. offer some new option)) I personally know 3 options:
a.creation of a complete RC, restoration on a new site from the RC, arrangement of rights (I think this is more correct, and the test site was raised repeatedly in this way)
b. simple disconnection of the database from the server, copying the file with data and log to a new server, there is a simple connection, again, setting rights and into battle (this was done several years ago, it seemed to work successfully then)
c. uploading to .dt, loading from .dt, in fact, transfer using the configurator, but this is the longest process, and it was not possible to unload such a large database the first time, then there is not enough space somewhere, then memory, etc.
2.there is always a chance that something will go wrong, in connection with this, my unfinished plan B was to raise the old site and somehow transfer the docks clicked by users from the new DB to the old DB. Why is plan B incomplete? because I can’t imagine if there is any tool for implementing such an idea, maybe. processing batch transfer of docks from such and such a date and time, or some kind of comparison of registers and a mirror copy from the contents, or some other options
3. TII, is it worth doing on the old site before uploading, or after uploading to a new site , the process is long, resource-intensive, I'm afraid the old one will not pull, and there is not much time. And in general, is it worth bothering with him in your opinion?
4.I'm worried about the DB options Compatibility level of this database - SQL Server 2008 (100), in the drop-down list the levels are optional up to SQL Server 2017 (140) what does it generally affect, this compatibility level initial data - database recovery mode - Simple old SQL server - Microsoft SQL Server 2014 - 12.0.2000.8 (X64) Feb 20 2014 20:04:26 new SQL Server - Microsoft SQL Server 2017 (RTM-CU15-GDR) (KB4505225) - 14.0.3192.2 (X64) Jun 15 2019 00: 45:05 DB size - 375 GB, log - 16 GB 1C platform works in 8.2 compatibility mode old platform - 8.3.8.2137 (x86) new platform - 8.3.13.1690 (x64)

Answer 1

c. uploading to .dt, loading from .dt, in fact, transfer using the configurator, but this is the longest process, and it was not possible to unload such a large database the first time, then there is not enough space somewhere, then memory, etc.

if it is possible to unload, iron-concrete way.
with your size , the size of the database is 375 GB, the upload will be about 1.5-2 gigabytes. I recently uploaded a 250GB scull base of the PSU here, wait 10 minutes for the upload, 20 minutes for the upload.
It's also possible, but although I'm not a big Microsoft SQL specialist, it should support databases of previous versions.
optionally, on boot, some of these functions will run.
you can not carry, especially not needed.
ps
Unloading in dt is better done.

Answer 2

strange, I received a notification in the mail that someone answered here, moreover, even the text of the answer is complete, but I don’t see it here at all in order to comment on it

Answer 3

Definitely through uploading to .dt and uploading to a new server, however, it can be quite long - but it depends on the hardware configurations. The second option is faster - make a full backup on the old server and deploy on the new one - old to new works fine.