Skip to content
← /work
CASE 06 · HISTORICAL

Expedition

Early adopter of Palo Alto Networks' firewall migration tool, and a member of the customer group that helped frame key requirements during its early development. Historical.

FRONTMATTER
---
title: "Expedition"
summary: "Early adopter of Palo Alto Networks' firewall migration tool, and a memb…"
stack: ["Migration tooling", "Config parsing", "Firewall migration"]
relevance: "Where the validate-both-ends migration methodology came from."
featured: false
section: work
---
STACK
Migration toolingConfig parsingFirewall migration
Where the validate-both-ends migration methodology came from.

Before the tool

Firewall migrations were hand work. A conversion meant reading vendor XML directly, or stitching together ad-hoc Python snippets that handled one customer's object naming and nothing else. I was doing those conversions at production scale — enough of them, and large enough, that every shortcut in the process eventually showed up as an outage window that ran long.

The customer group

I adopted Expedition at v1 and was part of the Palo Alto Networks customer group that helped frame key requirements early in its development — the working sessions where people running real migrations described what the tool had to account for before it could be trusted with a production ruleset.

What carried forward

Expedition is now end-of-life. The methodology it pushed me toward did not retire with it: validate both ends. Capture the behavior of the source platform, convert, then prove the target reproduces that behavior before the change window opens — rather than diffing configuration text and hoping the semantics survived the translation.

That premise is the direct ancestor of the pre/post behavioral validation in the PAN-OS fleet automation work.

Figure 6.1  Placeholder — architecture diagram.