An alternative is after you get the config imported to the new hardware and adjusted as needed for the different interfaces, rack the new firewalls physically adjacent to the old (so all cables which have been labeled will reach) then in a maintenance window quickly swap them from the old to the new.
You'll have a brief hard outage, but it's a quicker process.
You can't have no-downtime as you're switching out chassis. You can do a couple of things to minimize downtime but you will still need a maintenance window. Some things you won't be able to get past is your VPN connections. Unless you can gently reroute those to the new firewall before the cutover, all connections will need to be re-established the moment you do the cutover.
Preventing as much downtime a possible, you can start by transplanting the configuration over to the new firewall and making sure it is fully set up and attached to all peripherals before getting started: launch it in a lab environment to ensure functionality, then move it into production with the switch interfaces set to shut mode
The short term scenario is as follows:
Once you are ready to do the cutover, temporarily disable TCP checks :
# set deviceconfig setting tcp asymmetric-path bypass
# set deviceconfig setting session tcp-reject-non-syn no
These will make the firewall accept existing sessions even without a missing tcp handshake or with packets arriving out of order, due to the cutover.
Then, disable all interfaces on the old firewall and enable them on the new firewall and wait for a few minutes before setting the above configuration options back to their normal setting
The long term scenario is as follows:
Transplant the configuration over to the new firewall cluster, but start using different IP addresses on the interfaces. ie. where the old firewall was x.x.x.1, switch the new firewall to x.x.x.2 or x.x.x.254. then gradually move internal networks to the new IP as gateway and introduce the new ip as gateway in the GlobalProtect config. once all internal networks are moved, shut down the old firewall and move the original external IP to the new firewall (as a loopback or by changing the external interface's IP) so that the ipsec tunnels can be reestablished.
Along the way you will need to take NAT and individual subnet routing into account because you will have a network with 2 ingress/egress points. The one-off impact will be much lower, but it will take much longer to implement
I've recently joined this community Just in regards to your original post of FW hardware migration it would be much appreciated if you please share your detail migration activity if completed and if you're comfortable ? similar sort of activity going to take place soon in my organisation as well
An alternative is after you get the config imported to the new hardware and adjusted as needed for the different interfaces, rack the new firewalls physically adjacent to the old (so all cables which have been labeled will reach) then in a maintenance window quickly swap them from the old to the new.
You'll have a brief hard outage, but it's a quicker process.
You can't have no-downtime as you're switching out chassis. You can do a couple of things to minimize downtime but you will still need a maintenance window. Some things you won't be able to get past is your VPN connections. Unless you can gently reroute those to the new firewall before the cutover, all connections will need to be re-established the moment you do the cutover.
Preventing as much downtime a possible, you can start by transplanting the configuration over to the new firewall and making sure it is fully set up and attached to all peripherals before getting started: launch it in a lab environment to ensure functionality, then move it into production with the switch interfaces set to shut mode
The short term scenario is as follows:
Once you are ready to do the cutover, temporarily disable TCP checks :
# set deviceconfig setting tcp asymmetric-path bypass
# set deviceconfig setting session tcp-reject-non-syn no
These will make the firewall accept existing sessions even without a missing tcp handshake or with packets arriving out of order, due to the cutover.
Then, disable all interfaces on the old firewall and enable them on the new firewall and wait for a few minutes before setting the above configuration options back to their normal setting
The long term scenario is as follows:
Transplant the configuration over to the new firewall cluster, but start using different IP addresses on the interfaces. ie. where the old firewall was x.x.x.1, switch the new firewall to x.x.x.2 or x.x.x.254. then gradually move internal networks to the new IP as gateway and introduce the new ip as gateway in the GlobalProtect config. once all internal networks are moved, shut down the old firewall and move the original external IP to the new firewall (as a loopback or by changing the external interface's IP) so that the ipsec tunnels can be reestablished.
Along the way you will need to take NAT and individual subnet routing into account because you will have a network with 2 ingress/egress points. The one-off impact will be much lower, but it will take much longer to implement
hope this helps