Hello!
The operation you want to do and the way you want to do it will require a lot of downtime and involve changes through postgre sql and many other changes in the settings xmls, probably also the certificates, especially since you want to change who will be the new central node.
I suggest an alternative that involves less downtime and fewer operations to perform, that you add the new node that you want to be central as a failover and then set it as a central node. in this way, you will have covered the situation in which the central node may have problems and drops, and you can also use it for activities such as reloads or consumption for the end-user.
my plan would be:
1. August 2023 installation on new nodes:
a. I add the node that I want to be central to the architecture as failover
b. I add the node that I want to be dev to the architecture as a normal node
2. proxies configuration, load balancing and what other configurations you have set in your architecture for the newly added nodes.
3. upgrade version August 2023 on old nodes.
4. stop services on the current central node so that the new failover node becomes central
5. start services on the old central node that has now become failover.
From point 2 on down, it will involve downtime for end-users.
Obviously, I expect that along the way you will encounter other atypical situations depending on the configurations you have in your architecture: load balancing, custom properties... etc.
The approximate duration of the operation is 8 hours, depending on the specifications of the new servers.
Have fun!
