How to transfer a site to 1C-Bitrix with minimal inaccessibility and loss of information?

Question

1C-Bitrix

There is a site on 1C-Bitrix hosted on VPS. Site with attendance of about 45t. users per day. Someone registers, adds certain information. The site size is about 15GB. The time has come to transfer the site to another VPS to another provider, because. he is already suffocating, and the tariffs of the old provider are very biting. It is important to avoid the loss of information as much as possible and make the inaccessibility of the site minimal.
I assume the following transfer scheme:
1. In the DNS settings of the domain, change the TTL for the A-records of the domain to a minimum value of 5-10 minutes.
2. Install and configure BitrixEnv on a new VPS with the same hostname and PTR record.
3. Create a new certificate or transfer the old one (here it is questionable whether it will be possible to do all this, because Lets Encrypt is used, will there be a conflict? No experience.).
4. Make a backup copy of the site and database.
5. Restoring a site from a backup on a new server.
6. Locally on the computer through hosts, register the IP of the new server for the domain in order to check the operation of the site.
7. On the old server, change the database connection settings, specify the IP address of the new database server (previously open mysql to the world).
8. Change the DNS settings with a new IP address.
9. Run rsync on the site files to get the most up-to-date set of files.
10. Delete the old VPS.
Can you please tell me if this plan is correct? Maybe there is another solution that can correctly transfer data with minimal site downtime and loss of information. Maybe someone has experience and can share their transfer scheme?
update
When creating a new certificate for a domain, the error is:

# INFO: Using main config file /home/bitrix/dehydrated/config
Processing ***.ru
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for ***.ru...
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for ***.ru authorization...
 + Cleaning challenge tokens...
 + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Invalid response from https://***.ru/.well-known/acme-challenge/Ii3_VJ_4azFC6NskIf7hS1Q5NfDC1riIfEw8WIyaSVY [***.253.231.***]: \"\u003c!DOCTYPE html\u003e\\n\u003chtml lang=\\\"ru\\\"\u003e\\n\u003chead\u003e\\n\\t\u003cmeta http-equiv=\\\"X-UA-Compatible\\\" content=\\\"IE=edge\\\"\u003e\\n\\t\u003cmeta name=\\\"viewport\\\" content=\\\"w\"",
    "status": 403
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/IN3t5CY_bQ_McL2QNGs5wUalGOgPaomspM6qKuAmU5Q/18512196207",
  "token": "Ii3_VJ_4azFC6NskIf7hS1Q5NfDC1riIfEw8WIyaSVY",
  "validationRecord": [
    {
      "url": "http://***.ru/.well-known/acme-challenge/Ii3_VJ_4azFC6NskIf7hS1Q5NfDC1riIfEw8WIyaSVY",
      "hostname": "***.ru",
      "port": "80",
      "addressesResolved": [
        "***.253.231.***"
      ],
      "addressUsed": "***.253.231.***"
    },
    {
      "url": "https://***.ru/.well-known/acme-challenge/Ii3_VJ_4azFC6NskIf7hS1Q5NfDC1riIfEw8WIyaSVY",
      "hostname": "***.ru",
      "port": "443",
      "addressesResolved": [
        "***.253.231.***"
      ],
      "addressUsed": "***.253.231.***"
    }
  ]
})

***.253.231.*** - IP of the old server.
As I understand it, it connects to the old site and cannot pass validation.

Answer 1

Here you need to choose 1 out of 2: either minimal inaccessibility, or minimal loss of information.
I usually prefer the second one:
1) We make a backup of the database and site files without the upload folder
2) We deploy the backup on the new server
3) We download the upload folder to the new server via rsync - this does not happen quickly
4) We check that everything works on the new one
5) We are waiting nights from Friday to Saturday
6) Turn off synchronization with MySklad, 1C or something else from where the site pulls data.
7) If users can upload their files to the site, disable this feature for them
8) Repeat steps 1-4
9) Close the public of the old site
10) Make a backup of the database
11) Roll the database to the new site
12) We check that everything works, open the public on the new one and turn on the ability to upload your files back on the new one, on the old one the public should remain closed
13) Redirect the domain
14) Turn on back synchronization
Inaccessibility from point 9 to domain redelegation, no data loss
The certificate must be old take off. But before the redelegation of the domain, he will swear on the new one.
In general, this new provider of yours is bad if he himself does not take the client to himself for free. When moving to a normal provider, the scheme is reduced to 2 points: sign an agreement and provide access to the old server.

Answer 2

Do you need to move abruptly (just 1-2 days)? Or can be stretched for 1-2 months?
If possible, I would do this:
1) I bought a server from a cheaper but reliable host. You need to buy not the same server with great characteristics, but look only at the database.
Moved the database there. The old site has switched to the new base location.
Thus, we transferred a significant part of the site, unloaded the old server.
2) I bought a server purely for the web (ie without a database).
Further you know - rsync, dns, etc.
Thus, you have 2 new servers (if you did everything correctly, then the price did not increase much), but there was also a reserve where to grow further