A branch cutover should finish with proven application paths, not just an online SD-WAN appliance. This Prisma SD-WAN migration checklist gives you a circuit worksheet, staged change procedure, acceptance matrix and rollback decision tree to adapt before moving production cables.
Scope: an original planning template for an existing branch moving to Prisma SD-WAN ION devices. The example is hypothetical, not a tested deployment or a universal configuration. Match every platform-specific step to your ION model, software release and approved topology. Keep actual circuit identifiers, addresses and configuration exports in your private change record.
The problem: what must survive the branch migration?
Start with the search question that matters: “How do I move a branch to Prisma SD-WAN without losing private applications, SaaS access or the rollback path?” Do not combine that change with a firewall replacement, addressing redesign and authentication migration unless the dependencies genuinely require it.
For this proposed workflow, nominate an application owner, a network implementer, a remote-hands contact and a rollback authority. Agree the last safe rollback decision time before the maintenance window starts. Define success in terms of an actual business transaction: authentication followed by a read-only application operation, not just a ping.
Use the following gates as a reusable change asset. Blank evidence cells mean the gate is not ready; they do not mean “assumed working.”
Gate 1: complete the circuit and policy worksheet
| Item | Record privately before cutover | Required evidence |
|---|---|---|
| Hardware and topology | ION model, release, single device or HA, approved cabling diagram | Model-specific design reviewed |
| Internet circuit | Handoff type, VLAN, addressing method, gateway, permitted public source | Existing path and provider handoff verified |
| Private WAN | Transit addressing, routing method, allowed prefixes, return-path owner | Routes documented in both directions |
| LAN | VLANs, gateway ownership, DHCP and DNS dependencies | Representative client lease and resolver test |
| Application policy | Critical app, preferred path, approved alternate, forbidden path | Owner signs off normal and failure behavior |
| Security boundary | Firewall, NAT, inspection and remote-access owner on each path | No path bypasses required controls |
| Operations | Controller reachability, time/DNS dependencies, independent support access | Recovery contact and access tested |
| Rollback | Cable map, configuration restore, route ownership, decision deadline | Named person can restore the old path |
Treat the worksheet as a reconciliation exercise. For every critical application, write down where traffic exits, where translation occurs if applicable, which security control inspects it and how replies return. A migration plan should explicitly forbid an alternate path that violates an application’s security requirements.
For deployments retaining a private MPLS underlay, Palo Alto’s Gen-2 HA example requires routing exchange between the ION and provider-edge router; the presence of an overlay is not a replacement for that configuration.[4] In your change record, specify which routes should remain on the private underlay and which should use the overlay, then test both directions rather than relying on tunnel status.
Gate 2: choose bypass and cabling deliberately
Palo Alto distinguishes hardware bypass pairs, backed by a hardware relay and restricted port pairings, from virtual bypass pairs without those hardware capabilities.[2] Do not infer power-loss behavior from the word “bypass” alone; require a model-specific cabling review and an approved test for the selected design.
The bypass configuration procedure requires both component ports to be administratively up when creating the pair.[3] Its “Propagate LAN State?” setting controls whether LAN link state is propagated to the corresponding WAN port.[3] Record the selected behavior before the window so a link-state consequence is not mistaken for a carrier fault.
The parent interface for a bypass subinterface depends on usage: the WAN port for Internet or Private WAN, and the LAN port for LAN usage.[3] Include the parent, VLAN and addressing fields in the private worksheet rather than recording only the logical interface name.
HA design warning: the documented Gen-2 topology for ION 3200, 5200 and 9200 requires the HA connection through a southbound switch rather than a direct HA connection between the devices.[4] This is not a universal prohibition on all inter-device cables: the same reference includes circuit cross-connections between the appliances.[4] Review the exact function of each cable instead of copying a diagram from a different platform family.
For the HA interface in that reference design, Palo Alto calls for external reachability, directly or through the overlay, and DNS capable of resolving public addresses.[4] Add this as a specific precheck where that topology applies; do not treat “LAN interface responds” as proof that management dependencies are satisfied.
Gate 3: stage the change without losing the old path
The following is a recommended workflow, not a vendor command sequence.
- Freeze and capture. Save approved configuration exports, routing state, interface status and normal application observations. Record the original cable endpoints privately.
- Confirm independent recovery. Validate console or independent management access. Confirm remote hands can identify the restoration cables without access to the affected WAN.
- Stage the intended configuration. Review interface usage, circuit labels, LAN networks, routing and policy against the worksheet. Avoid enabling competing production gateways during staging.
- Select a pilot. Choose an approved test client or subnet with representative applications. If the topology cannot isolate a pilot, explicitly approve a full-branch maintenance outage instead of improvising.
- Move the pilot or perform the approved cutover. Record the time and the exact physical/logical transition. Compare observed routes and path choice with the expected state before expanding traffic.
- Run the acceptance matrix. Capture application results, selected path and relevant security observations together. Do not accept a green dashboard as a substitute for the matrix.
- Expand only after sign-off. Keep the old configuration and restoration map intact until the agreed observation period ends.
Gate 4: use an application acceptance matrix
Fill in the “expected result” column before the change. Recovery time and permitted session interruption are business-specific acceptance criteria, not universal SD-WAN guarantees.
| Test | Expected result to define | Evidence to collect | Stop condition |
|---|---|---|---|
| Client addressing and DNS | Correct lease, gateway and internal/public resolution | Client state and resolver answers | Wrong scope, resolver or gateway |
| Private business app | Approved path and successful read-only transaction | App result plus forward/return routing | Route leak or broken return path |
| SaaS sign-in and transaction | Approved egress and required inspection | App result, egress identity, security log | Unapproved inspection bypass |
| Voice or interactive app | Owner-defined quality on normal path | Test-call notes and available telemetry | Unacceptable user experience |
| Primary circuit unavailable | Approved alternate or intentional failure-closed | Application result and selected path | Traffic uses forbidden path |
| Primary restored | Documented recovery behavior without repeated disruption | Path history and app observations | Persistent oscillation or regressions |
| Device failure, if HA | Approved platform-specific recovery behavior | HA state and application observations | Split behavior or incomplete restoration |
| Rollback rehearsal or validation | Old service can be restored as documented | Restoration sequence and owner confirmation | No viable recovery path |
Perform one fault at a time in an authorized maintenance window. For an Internet-link failure test, check both new transactions and a pre-existing session; record the difference rather than calling all traffic “working.” Never unplug both carriers merely to prove that the appliance alarms.
Example client-side checks — unexecuted templates: replace the reserved example hostname with an approved test endpoint. Run these from the designated test client, not indiscriminately from every device.
# Confirm name resolution using the client's configured resolver.
nslookup app.example.com
# Record HTTP status and timings without disabling certificate validation.
# Use a read-only health URL agreed with the application owner.
curl --connect-timeout 5 --max-time 20 --output /dev/null --silent --show-error \
--write-out 'http=%{http_code} connect=%{time_connect} total=%{time_total}\n' \
https://app.example.com/health
Treat these as evidence helpers only. A successful health URL does not prove interactive login, business authorization or every backend dependency. Do not place passwords, session cookies or access tokens in a public runbook or command history.
Troubleshooting decision tree: fix forward or roll back?
Client cannot reach its gateway: stop expansion; inspect the approved LAN/VLAN and gateway handoff. Compare the client state with the baseline before changing WAN policy.
Gateway works, names fail: compare the configured resolver and the route to it. Do not use public DNS as an automatic workaround for an internal application.
Names resolve, only private apps fail: compare expected private prefixes, route advertisements, return-path ownership and the security boundary. If the plan cannot explain both directions, restore the last known-good path rather than adding broad routes under pressure.
Apps work normally but fail on the alternate circuit: compare the observed path with the application’s allowed-path entry. Check the alternate path’s security/NAT dependencies with their owners. An intentionally forbidden alternate should remain forbidden, not be enabled to make the test green.
Controller visibility fails while clients still work: use the independent management path, then examine the documented management dependencies. Avoid a blind restart that destroys a currently usable data path.
Rollback deadline arrives with a failed mandatory test: the recommended decision is rollback, not indefinite troubleshooting. Record the evidence and schedule a corrected attempt.
Rollback checklist and operational handover
- Announce rollback and freeze further changes; keep a single implementer coordinating the sequence.
- Restore cable endpoints and gateway/routing ownership according to the approved old topology. Prevent simultaneous competing production paths.
- Restore the approved old configuration only where the change altered it; follow the platform’s supported restoration procedure.
- Re-run client DNS, private-app and SaaS transaction checks on the restored path.
- Confirm security controls, monitoring and support access with their owners before declaring restoration complete.
- Preserve timestamps and sanitized observations for the next change review. Keep raw logs and identifiers private.
At handover, assign an owner for circuit alarms, application exceptions, route changes and recurring path transitions. Set an observation period appropriate to the branch’s business hours so a quiet maintenance window is not the only validation.
Practical takeaways
Use the worksheet to make dependencies explicit, the matrix to define acceptance before disruption and the rollback deadline to prevent an open-ended outage. Review ION-specific bypass and HA details rather than treating every branch appliance as interchangeable. The result is a repeatable migration asset—not a claim that any particular deployment has passed these tests.
Continue with the Start Here networking index and the networking resources page for related design and troubleshooting material.
Sources
- [2] https://docs.paloaltonetworks.com/prisma-sd-wan/administration/prisma-sd-wan-sites-and-devices/prisma-sd-wan-ports-and-interfaces/bypass-pair
- [3] https://docs.paloaltonetworks.com/prisma-sd-wan/administration/prisma-sd-wan-sites-and-devices/prisma-sd-wan-ports-and-interfaces/bypass-pair/configure-a-bypass-pair
- [4] https://docs.paloaltonetworks.com/prisma-sd-wan/administration/prisma-sd-wan-branch-high-availability/branch-ha-topologies-platforms/configure-branch-ha-gen2-platforms
Post a Comment