Longer answer: You have quite a few changes here, you may want to spend some planning time to review all the changes both at OS level and Vault level ( PKI had a big transition at vault 1.11 ), and if you stay with Consul, they have changes as well.
Doing all of this in one step will have significant risk.
Hi @alain Thank you for your response, is it possible to install new rocky9 server for vault and Consul and migrate the secrets from old environment to new.
If you are using OSS Vault - what you are doing is setting up a second vault cluster then reading and writing data to the a new cluster. None of this is in the scope of the Vault or Consul processes, you just move stuff. Then its a hard cutover for the clients ( new auth/token required).
If you have Enterprise vault, you can do a “Failover upgrade” - we used this when moving from 1.4 + Consul to 1.10 + Integrated, and continued to use that moving forward. The main reason for the Failover upgrade, was to give us a simpler back out plan. For those who do Have enterprise, you can use the disaster recovery feature to do a near seamless updgrade.
Initial setup:
Starting with Cluster A
Create Cluster B
Link B as DR to A - wait for data to be fully in sync
Upgrade actions:
Stop traffic to A
Promote B to primary - validate
Allow traffic to B
If validation of B has issues:
Stop cluster B
Restart traffic to A
We found this a better flow, since its one operational process for failover or upgrade ( instead of 2 ), we had a valid way to back out - start a known vault vs restore !!
Why we stopped traffic was to stop split brain from happening ( 2 DR Primary ) and to limit dataloss in case of rollback ( anything written to cluster B would be “lost” ) - this dataloss is much less than a snapshot restore.
Also, you can DR to a higher release, but not to a lower release.