- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
This guide provides a comprehensive walkthrough for IT and security teams to seamlessly transition their NGFW management infrastructure from Panorama to Strata Cloud Manager, ensuring minimal disruption and maintaining robust security posture throughout the migration process.
In the first phase of this feature, the Migration Tool will help you migrate the configuration from a single panorama to Strata Cloud Manager per run. In this migration process, the Panorama Configuration will be fetched to SCM Folder and Snippet Structure, where Device Group will be migrated to Folders and Templates and Template stacks will be migrated to Snippets.
Detailed concept of Mapping:
|
Panorama |
SCM |
|
Device Groups (DG) |
Folders |
|
Templates / Template Stack |
Snippets |
|
Shared DG Rules and Objects |
Snippet in All Firewall Folder |
|
Shared Objects |
Snippet in Global Folder |
|
Policies in DG |
Policies under mapped Folder(s) |
|
Objects (addresses, EDLs, etc.) |
Objects under mapped Folder(s) |
A Single migration process doesn't necessarily migrate all the Configurations from Panorama to Strata Cloud Manager. During the migration, users can choose which Device Group and template to migrate where it can be per site/DG based. This feature is designed to perform phase migrations
This Migration does not need the Panorama to lively connect to Strata Cloud Manager. The only requirement for this configuration migration is the running configuration from the Panorama.
AD needs to integrate with CIE for the user/group fetching with SCM.
User-id Redistribution needs to be configured on SCM with the CIE Segment manually if used. (not covered in the migration)
Links to setup CIE: https://docs.paloaltonetworks.com/cloud-identity/cloud-identity-engine-getting-started/get-started-w...
When Exporting, make sure your FW is in sync with panorama and export the running config from panorama without specifying any DGs. Export the entire panorama config, you can choose which DG to migrate in the workflow
Go to Configuration -> Onboarding -> NGFW Panorama and Click on Start Migration
Click on “Next: Upload Panorama Configuration”
In this step, Upload the Panorama Running configuration xml file. If the Panorama is configured with a custom master key, change the option to “Input your Master key” and enter the master Key. Then Click on “Next: Review Configuration Compatibility”
After SCM loads the Panorama configuration, SCM will analyze the unsupported/partially Supported Features that present on your panorama configuration. And user has the option to export the Compatibility Summary report in JSON format
Unsupported Features:
These Features are not supported/compatible in this migration and these Feature configurations will be trimmed during the migration process.
Partially Supported Features:
These Features are Partially Supported in this migration, the unsupported part will be trimmed during the migration process.
The Parity output can be exported as a JSON Format for in depth analysis. For example finding the Xpath of an unsupported feature
Note: There are features that will be implemented differently in SCM and will not be supported. Please check the list down below for more details
|
Name |
Description |
|
Group By Tag (Authentication) |
Authentication Policies (Alternate Feature Available - Use Tags or snippets to group rules) |
|
Group Mapping |
Group Mapping Settings in User Identification (Cloud Identity Engine is used to get the group mapping information) |
|
Autofocus |
Autofocus (Autofocus is end of sale) |
|
Group by Tag |
Policies (Alternate Feature Available - Use Tags or snippets to group rules) |
|
Schedule Config Export |
Schedule Config Export (Strata Cloud Manager is a SaaS based service with redundancy and resiliency built in) |
|
Custom Reports |
Custom Reports (This configuration is not relevant to Strata Cloud Manager) |
|
Access Domains |
Access Domains (Alternate Feature Available - Use Scope Management) |
|
User ID Master Device |
User ID Master Device option (Alternate Feature Available - Use Cloud Identity Engine) |
|
Cloud Identity Engine |
Cloud Identity Engine option(Strata Cloud Manager automatically generates configuration for all the directories configured in Cloud Identity engine) |
|
PDF Summary Report |
PDF Summary Report (This configuration is not relevant to Strata Cloud Manager) |
Click on check box “Acknowledge unsupported features. The unsupported configuration will be trimmed” and click on “Next: Select Device Groups to Migrate”
In this step, we can choose the scope of the migration. Choose the Device group that you would like to migrate in the process, the Device Group will show up on the right hand side which presents how the device group will be placed post migration. (when you click on a DG, the sub DGs and devices in the DGs will be migrated) In this example, the San Jose Branch DG in NAM DG will be migrated.
Note: Config Drifts - currently this migration feature will not handle config drifts. If there are different configurations in the folder that has already been migrated. Those config drifts will be ignored. These config need to be manually configured in SCM
Note: Conflict on Folder Name - if there is a DG in the panorama config with the same name in SCM folder structure, the migration tool will treat the folder with the same name as a migrated folder. Make sure the DG names do not appear in the folder structure in your first migration.
Manual Template Mapping: Manually attach each template and template Stacks
If this step is chosen, here is how you can perform a manual template association.
The detailed explanation of the column header as below:
On the left hand side hierarchy we can click and change the scope, the right hand side red box will show how the templates and template stacks are used in this scope.
We can see that in this panorama, we have 5 FWs in total, only 1 FW is using this Template / Stack. And in the selected San Jose scope, we have 1 FW in total, and 1 FW is using the Template / Stack. This means the only FW using this template resides in this folder. So we can safely assign this template in this folder
We can see that in this panorama, we have 5 FWs in total, 3 FW is using this Template / Stack. And in the selected San Jose scope, we have 1 FW in total, and 1 FW is using the Template / Stack. It means that also other FWs are using this template. In this case, we can go to a level above to see if we can associate this template to an upper level to optimize the configuration.
We can see that in the NAM Hierarchy, All 3 FWs use this Template / Stack. So in order to optimize the configuration, we should attach the Template / Stack in this Level.
Note : if we see not all the firewalls using the template in the selected scope, we should not attach the snippet to the level we selected. The Template / Stack should attach back to the sub level.
To attach the snippet to the selected level, Click on the pencil button, choose the preferred level and click on save. Re-do this for all the templates and template stack in the list.
We can also change the order of the snippet.
Tenant mapping preview will show you in one page how the snippet will be associated with the Folder hierarchy.
Note: Make sure your template Stacks is over your template in the scope so the respective config can be overwritten. (if there are objects have configured in different values in the same name, the snippet on the top will keep the source of truth)
Click on “Load Configuration to Strata Cloud Manager”
Click on the Load Result and Validation Result. Fix the error and make sure both results are successful before moving on to the next step.
If there is no errors, click on “Review Config Diff”
This is the final check before we finish the config migration. Click on the Firewall in the left hand side hierarchy, upload the TSF file for the device and click on next.
SCM will mock push the config to the firewall using the TSF file and provide you the configuration diff comparison.
Note: if you seeing the Mock Push failed, please go to Configurations -> Operations -> Job Status. the Mock Push will trigger a job and you can go to job status to check the reason of the mock push failure.
All the config/object changes will show up in the list. Click to view the xml format on the bottom. The configuration diff can also be exported as a JSON format.
Click on Next and Finish and Confirm the migration to finish and exit the migration process.
Please follow this link below from Step 7.3 to Step 12 to associate the Device to Strata Cloud Manager:
Once the onboarding process has been completed, perform a push to the device. For more detail on how to push to the device please follow the link below (for Prod FWs it is recommended to cutover in a maintenance window):
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| Subject | Likes |
|---|---|
| 3 Likes | |
| 3 Likes | |
| 3 Likes | |
| 2 Likes | |
| 2 Likes |
| User | Likes Count |
|---|---|
| 6 | |
| 5 | |
| 4 | |
| 2 | |
| 2 |


