GlobalProtect (GP) is an endpoint security agent. Enterprise customers had spent years configuring GlobalProtect to manage authentication, traffic forwarding, tunnels, endpoint behavior, and access policies.

Migrating to Prisma Access Agent wasn't as simple as copying those settings. Some configurations needed to be transformed, others had no direct equivalent, and mistakes could put working infrastructure at risk.

The challenge: How might we help admins migrate years of security configuration without putting existing endpoints at risk?

Feedback from four enterprise customers revealed different migration requirements, but a common priority: admins needed to understand what would change and remain in control of the migration.

These requirements pointed toward a shared principle: Make migration observable, interruptible, and admin-controlled.

Preparing the new configuration should never automatically mean deploying it to employees. Configuration migration and endpoint rollout needed to remain separate decisions.

The project began with a PRD, but the requirements were still evolving. With product, engineering, and leadership regularly revisiting the scope, designing polished screens too early would have meant reworking them repeatedly.

Instead, I used Figma Make to turn the initial requirements into an interactive prototype. During weekly reviews with product and engineering, we walked through the migration, questioned assumptions, and adjusted the information architecture as the requirements became clearer.

Simplifying the journey from five steps to four

The initial prototype had five steps, including separate initiation and readiness checks. As we reviewed the experience, the team aligned around a common goal: make migration as simple and automated as possible without removing the checks and control administrators needed.

We combined the first two steps into one, simplifying the workflow into four broader stages.

Once the workflow was aligned with engineering, I moved into detailed screens using Palo Alto Networks' design system.

I initially assumed that completing the migration would mean deploying Prisma Access Agent to employees and replacing their existing GlobalProtect setup.

Through discussions with engineering, I learned that the migration wizard only translated and copied configurations into Prisma Access Agent. Employees would continue using GlobalProtect until admins separately decided to roll out the new agent.

This changed how I approached the experience.

The goal wasn't to get admins through a wizard as quickly as possible. It was to help them prepare, validate, and migrate configurations with confidence, while keeping endpoint deployment under their control.

Before migration could begin, admins needed to configure their destination environment in Prisma Access Agent.

I made the required setup explicit and prevented admins from progressing until the necessary information was provided.

GlobalProtect and Prisma Access Agent didn't share a one-to-one configuration model. Some settings could move directly, others needed transformation, and some were unsupported or blocked migration.

Rather than hiding these differences behind automation, I designed a mapping view that showed admins exactly how their existing configurations would be handled.

Direct - The configuration carries over with essentially the same meaning.

Transformed - The intent is supported, but Prisma Access Agent represents it differently.

Blocker - The issue must be resolved before migration can safely continue.

No Equivalent - The GlobalProtect capability simply does not exist in Prisma Access Agent.

Successfully translating a configuration didn't mean it was ready for migration. I structured the validation experience around three decisions:

1. Understand readiness: A pass / pending / fail summary gave admins an immediate view of whether the migrated configuration was ready to proceed.

2. See the evidence: Admins could inspect the individual validation tests rather than relying on a single “migration ready” status

3. Make an explicity decision: The configuration was only migrated after the admin reviewed the results and explicitly chose to continue.

Pass / pending / fail summary. Gives admins an immediate view of migration readiness.

Tests run to validate how older GP configurations will run in a PAA environment once the migration has taken place

Final consent from the admin before migrating the configurations .

Option to abort the migration right before the final step. Additionally users can click on cancel to exit the migration flow without saving it.

Option to save the progress and return later.

Option to download the configuration in CSV to review later.

Option to download the configuration in PDF report to review later.

This was important because successful translation did not automatically mean a safe configuration.

Completing the migration confirmed that configurations had been copied into Prisma Access Agent. It did not deploy the new agent to employees.

The final screen confirmed the outcome and guided admins toward the next steps in PAA Setup, leaving the decision of when to roll out the new agent entirely in their hands.

Confirms that configurations has been copied successfully to Prisma Access Agent and that GlobalProtect runs normally

Provided the admin next steps in the journey to migrate to Prisma Access Agent

The final experience brought the migration into a guided four-stage workflow, giving admins visibility into configuration changes, a way to validate readiness, and control over when to proceed.

The workflow was refined through weekly reviews with product and engineering before I developed the final screens using Palo Alto Networks' design system.

The goal was to make migration more accessible to enterprise admins without requiring extensive engineering assistance or putting existing endpoints at risk.

The Phase 1 rollout plan identified approximately 800 eligible enterprise tenants, representing 1.5 million endpoints.

Engineering estimated that the guided configuration migration could take approximately 30 minutes, compared with days for the existing manual or assisted process.

These figures represent the planned rollout scale and pre-launch estimates. I left the project before implementation, so I couldn't measure actual customer adoption or migration completion times.

With requirements changing almost every week, Figma Make gave product and engineering something tangible to react to. Instead of spending time polishing screens that might change, I could quickly update the workflow and clarify assumptions with the team.

Understanding the system was just as important as designing the interface.

I initially misunderstood what completing a migration meant. That experience reminded me how important it is to clarify technical boundaries early, especially when designing products where mistakes can have serious consequences.

What I'd do differently

I'd document the reasoning behind major design changes more consistently. We iterated quickly, but keeping a clearer record of the decisions, trade-offs, and previous versions would have made it easier to explain how the experience evolved.