Plan the Transition to Panorama Management

• Decide which firewalls to migrate.
• Plan a maintenance window and ensure there are no pending configuration changes on Panorama or the firewalls.
• If you are migrating the firewall from one Panorama to another, localize the Panorama pushed configuration on the firewall.
• Preserve your known working Panorama and firewall configurations prior to migration.
  • Export the device state of your firewalls.
  • Export a named Panorama configuration shapshot of the running Panorama configuration.
• Determine the Panorama and firewall software and content versions, and how you will manage licenses and software upgrades. For important details, see Panorama, Log Collector, Firewall, and WildFire Version Compatibility.
• Plan how to manage shared settings.
  Plan the Device Group Hierarchy, Templates and Template Stacks in a way that will reduce redundancy and streamline the management of settings that are shared among all firewalls or within firewall sets. During the migration, you can select whether to import objects from the Shared location on the firewall into Shared on Panorama, with the following exceptions:
  • If a shared firewall object has the same name and value as an existing shared Panorama object, the import excludes that firewall object.
  • If the name or value of the shared firewall object differs from an existing shared Panorama object, Panorama imports the firewall object into each new device group that is created for the import.
  • If a configuration imported into a template references a shared firewall object, or if a shared firewall object references a configuration imported into a template, Panorama imports the object as a shared object regardless of whether you select the Import devices' shared objects into Panorama's shared context check box.
• Determine if the firewall has configuration elements (policies, objects, and other settings) that you don’t want to import, either because Panorama already contains similar elements or because those elements are firewall-specific (for example, timezone settings) and you won’t use Panorama to manage them. You can perform a global find to determine if similar elements exist on Panorama.
• Decide the common zones for each device group. This includes a zone-naming strategy for the firewalls and virtual systems in each device group. For example, if you have zones called Branch LAN and WAN, Panorama can push policy rules that reference those zones without being aware of the variations in port or media type, model, or logical addressing schema.
• Create a post-migration test plan.
  You will use the test plan to verify that the firewalls work as efficiently after the migration as they did before. The plan might include tasks such as:
  • Monitor the firewalls for at least 24 hours after the migration.
  • Monitor Panorama and firewall logs for anomalies.
  • Check administrator logins on Panorama.
  • Test various types of traffic from multiple sources. For example, check bandwidth graphs, session counts, and deny-rule traffic log entries (see Use Panorama for Visibility). The testing should cover a representative sample of policy configurations.
  • Check with your network operations center (NOC) and security operations center (SOC) for any user-reported issues.
  • Include any other test criteria that will help verify firewall functionality.