GlobalProtect
Upgrade and Migration
Table of Contents
Upgrade and Migration
This section provides information on upgrade or migration of PAN-OS with HCS
feature.
For successful HIP redistribution upgrades, the standard order is to upgrade Panorama
first, followed by the gateway firewalls and finally the non-gateway firewalls. This
principle applies across various topologies, in both simple and multi-tier
(GWs→collector FWs→ edge FWs) deployments, the sequence remains gateways
before edge firewalls, with collector firewall upgrades being optional.
You must follow the upgrade of the components sequentially as laid out in the table:
| Category | Upgrade Sequence |
|---|---|
|
Large Enterprise with NGFW
|
|
|
Small Businesses
|
|
Post-Upgrade Steps for Redistribution Configuration:
Regardless of the deployment model, it is a best practice to preserve all existing
redistribution agent configurations after an upgrade. This is required to support a
potential future downgrade to a version that relies on the HIP redistribution logic.
Retaining the configuration simplifies the downgrade process, eliminates the need for
manual reconfiguration, and prevents service interruptions related to HIP reporting.
After the upgrade, the system automatically updates the existing HIP Objects
into new HCOs and HCPs. These new objects are for reference only and can be identified
by the original HIP Object name in their description field. Your original HIP
configuration is not impacted. You must review these examples to learn the new
framework, then manually create your own HCOs and HCPs. Once your new configuration is
in place, you should delete the auto-generated reference objects.
During an upgrade the system automatically:
- Creates New Objects: Each of your existing HIP Objects is automatically converted into one or more new HCOs.
- Adds a Reference: For easy traceability, the original HIP Object's name is added to the description field of every new HCO created from it.
- Groups the Objects: All HCOs generated from a single HIP Object are then grouped together with an AND condition inside a new, corresponding HCP.
- Preserves Original Configuration: This conversion process has no impact on your original HIP Objects and HIP Profiles. They are left untouched and continue to function until you decide to change them.
You must manually create a new configuration and then remove the auto-generated reference
objects. Follow these steps
- Review the automatically generated HCOs and HCPs. Analyze how the new HCS framework represents the logic from your old HIP Objects.
- Manually create your own HCOs and HCPs based on your organization's security requirements.
- Once you implement the new HCS configuration,you should delete the automatically generated HCOs and HCPs by the system to avoid confusion.
Migration Behavior of HIP Objects by Location
During the migration, existing HIP Objects are converted into new HCOs and HCPs. Their
location and the naming convention of the new objects depend on their original
scope:
- Device Groups: HIP Objects configured within a specific
Device Group will be migrated as new objects within that same Device Group. The
names of these new objects will be prefixed with DG-.
![]()
- Shared Scope: HIP Objects from the 'Shared' scope will be
migrated into the 'Shared' scope. The names of these new objects will be prefixed
with CMS-.
![]()
- Specific Vsys: HIP Objects configured for a specific virtual
system (vsys) will be migrated within that same vsys. The names will be prefixed
with vsysX-, where X is the vsys ID (e.g., vsys1-).
![]()
- Local Firewall/Vsys: HIP Objects configured directly on a
local firewall (not inherited from Panorama) will be migrated within their
respective vsys. The names of these new objects will be prefixed with Local-.
![]()
The newly created HCPs will be placed in the same location (e.g., Device Group, Shared,
or vsys) as the HCOs they contain.