Sign in Get started

Panorama to Strata Cloud Manager Migration

Moving policy from Panorama to Strata Cloud Manager (SCM)? NetConverter serializes your configuration into SCM REST API objects in correct dependency order, maps device-groups to folders, and validates the output before it reaches the cloud.

Start Free Migration Contact Us

Why Panorama → SCM Is a Model Shift, Not a Copy

Strata Cloud Manager is not "Panorama in the cloud." Panorama organizes policy with device-groups and templates and is configured as an XML candidate config you commit and push. Strata Cloud Manager is a cloud-delivered control plane configured entirely through a REST API, where objects live in a folder/snippet hierarchy and every object is folder-scoped — there is no implicit "current location." A straight XML export will not load into SCM, which is why migration here means re-shaping the configuration, not copying it.

NetConverter handles that re-shaping through its vendor-neutral intermediate representation. The Panorama config is parsed once into a normalized model, then the SCM serializer emits a JSON array where each element is {"type", "name", "data"} targeting the api.strata.paloaltonetworks.com endpoints. Device-group intent is mapped onto SCM folders so shared-vs-local scoping survives the move, and objects are emitted in strict dependency order so the push never fails on a missing reference.

The Strata Cloud Manager Challenge

Folder-Scoped Objects

Every SCM object must declare a folder (Shared, All, or custom). Panorama's device-group inheritance has to be re-expressed as folder placement.

Strict Object Rules

Address objects allow only one type each (ip_netmask, ip_range, or fqdn), and host addresses require /32 CIDR — not a bare IP.

Dependency Ordering

Group members and referenced objects must exist before the things that reference them, or the API push fails mid-stream.

How NetConverter Solves It

SCM-Native Object Output

Output is a JSON array of SCM REST API objects — addresses, services, groups, zones, security rules, and NAT rules — ready to push, not a generic dump.

Device-Group → Folder Mapping

Panorama device-group and shared scoping is mapped onto the SCM folder hierarchy so policy intent and reuse are preserved.

Dependency-Ordered Push

Objects are emitted tags → addresses → services → groups → zones → security rules → NAT rules, so every reference resolves on first push.

OAuth 2.0 Service Auth

Pushes authenticate with SCM client-credentials (client_id, client_secret, TSG ID) using short-lived tokens that auto-refresh during the run.

4-Tier Validation + SCM Rulepack

An SCM-specific validation rulepack plus syntax, semantic, best-practice, and AI-assisted review run before anything reaches your tenant.

Reviewable in a Folder

Objects land in the folder you specify, so you inspect the migrated policy in SCM before committing and pushing to firewalls.

See the SCM Object Output

A Panorama security rule and its objects, re-shaped into the Strata Cloud Manager REST API objects NetConverter pushes — note the /32 host CIDR and the explicit folder on every object.

Panorama (Source XML)
<address> <entry name="web-srv-01"> <ip-netmask>10.20.1.10</ip-netmask> </entry> </address> <service> <entry name="tcp-8443"> <protocol><tcp> <port>8443</port> </tcp></protocol> </entry> </service> <!-- device-group: DG-DMZ --> <security><rules> <entry name="allow-web"> <from><member>untrust</member></from> <to><member>dmz</member></to> <source><member>any</member></source> <destination> <member>web-srv-01</member> </destination> <service><member>tcp-8443</member></service> <action>allow</action> </entry> </rules></security>
Strata Cloud Manager (Target API objects)Start Free Migration
[ { "type": "address", "name": "web-srv-01", "data": { "name": "web-srv-01", "ip_netmask": "10.20.1.10/32", "folder": "DG-DMZ" }}, { "type": "service", "name": "tcp-8443", "data": { "name": "tcp-8443", "protocol": { "tcp": { "port": "8443" } }, "folder": "DG-DMZ" }}, { "type": "security-rule", "name": "allow-web", "data": { "name": "allow-web", "from": ["untrust"], "to": ["dmz"], "source": ["any"], "destination": ["web-srv-01"], "service": ["tcp-8443"], "action": "allow", "folder": "DG-DMZ" }} ]

What Transfers — and What's Manual

Transfers automatically

Address/service objects and groups, zones, security rules, and NAT rules — re-shaped to SCM schema with /32 host normalization and combined TCP+UDP services split per protocol.

Mapped with review

Device-group hierarchy → SCM folders, and any naming that exceeds SCM limits (for example, zone names over 31 characters) is flagged for a quick decision.

Manual steps

Template-level settings (interfaces, routing, HA) and security profiles/decryption that have no 1:1 SCM object are listed as explicit manual steps rather than guessed at.

Migration Results

REST
Native SCM API objects
4-tier
Validation + SCM rulepack
<2min
Per Config
$0
For Most

Need Custom Development or Complex Migration Support?

For large multi-tenant SCM rollouts, custom folder strategies, or dedicated engineering support, our team is here to help.

Contact Engineering Start Free Migration

Ready to Migrate to Strata Cloud Manager?

Convert your Panorama policy into reviewable SCM API objects in minutes. No credit card required.

Start Free Migration

Frequently Asked Questions

How does NetConverter migrate Panorama to Strata Cloud Manager?
NetConverter parses the Panorama configuration into a vendor-neutral model, then its SCM serializer emits a JSON array of Strata Cloud Manager REST API objects — each shaped as {type, name, data}. Objects are produced in dependency-push order (tags, addresses, services, address-groups, service-groups, zones, security rules, NAT rules) and pushed into a target SCM folder over the api.strata.paloaltonetworks.com REST API.
How do Panorama device-groups map to SCM folders?
Strata Cloud Manager replaces Panorama's device-group hierarchy with a folder/snippet tree. NetConverter maps device-group intent onto SCM folders so shared-vs-local scoping is preserved. Every emitted object carries an explicit folder (for example, "Migrated" or a custom folder you choose), because the SCM API is folder-scoped — there is no implicit location.
What authentication does the SCM push use?
SCM uses OAuth 2.0 client-credentials. You supply a service-account client_id, a client_secret, and your Tenant Service Group (TSG) ID. NetConverter obtains a short-lived bearer token (~15 minutes) and refreshes it before expiry while pushing objects to the config/objects, config/security, and config/network API endpoints.
What are the common gotchas migrating to Strata Cloud Manager?
SCM address objects must hold only one type each — ip_netmask, ip_range, or fqdn — and host addresses must use /32 CIDR (10.0.0.1/32, not a bare IP). Combined TCP+UDP service objects (common from Cisco ASA) must be split into one SCM service object per protocol. Group members must exist before the group is created, which is why NetConverter emits objects in strict dependency order.
Can NetConverter migrate Cisco ASA or FortiGate directly to Strata Cloud Manager?
Yes. Because the SCM output is driven from the same vendor-neutral model as every other path, Cisco ASA, FortiGate/FortiOS, and Palo Alto PAN-OS or Panorama sources can all target Strata Cloud Manager. A dedicated ASA-to-SCM mapping handles ASA-specific constructs such as splitting combined TCP/UDP services. See also Cisco ASA → Palo Alto and Strata Cloud Manager optimization.
Is the migration validated before it reaches SCM?
Yes. The SCM output passes an SCM-specific validation rulepack plus NetConverter's 4-tier validation (syntax, semantic, best-practice, AI-assisted review) before push. Because objects land in the folder you specify, the result is reviewable in Strata Cloud Manager before you commit and push to firewalls.