Migrate from Fortinet to Palo Alto Networks
Parallel-cut migration with zero downtime. Senior engineers, fixed-scope SOW, defined cutover window.
What triggers a Fortinet to Palo Alto move.
Fortinet FortiGate is a competent NGFW. The migration decision is rarely about Fortinet failing; it is usually about Palo Alto fitting better with a broader strategy (SOC, SASE, cloud security). CWS will not run a migration just because a customer asks for one. The first conversation is whether the migration delivers genuine value.
- License or refresh-cycle pressure makes a vendor evaluation rational at this point
- Threat-prevention depth requirement has grown beyond the existing platform's capability
- SOC modernization roadmap targets Cortex XDR or XSIAM and unified telemetry
- Operations team is consolidating around fewer security vendors
- A specific compliance or regulator requirement (ITSG-33, ISR) is easier to satisfy with Palo Alto's reporting
Five phases. Parallel-cut. Defined cutover window.
CWS runs a parallel-cut migration: build the new PA-Series + Panorama estate alongside the live FortiGate estate, validate, then cut over inside an approved change window with documented rollback. The phases below define ownership and deliverables for each.
- 01
Phase 1 — Discovery and Assessment
1 to 2 weeks- Current-state Fortinet inventory: firewall count, firmware versions, throughput, HA pairs
- Policy export and analysis: rule count, complexity, dead rules, shadowed rules
- Application identification: which apps are inspected, which are excluded
- Identity integration: how user-to-IP mapping is currently done
- Logging and SIEM: where logs go today, what changes for Palo Alto
Owner: CWS senior engineer + customer network lead - 02
Phase 2 — Design and Translation
2 to 3 weeks- Palo Alto target architecture document
- Policy translation: Fortinet to Palo Alto App-ID rules, with senior engineer review on every rule that Expedition cannot translate cleanly
- Identity mapping plan (User-ID source, agent or agentless)
- Decryption strategy and exception list
- Logging and SIEM ingestion plan
- Cutover runbook with rollback steps
Owner: CWS senior engineer - 03
Phase 3 — Build and Validate
2 to 4 weeks- Palo Alto NGFWs racked, configured, and licensed
- Panorama (or Strata Cloud Manager) configured with translated policies
- Test traffic validated against representative application set
- User acceptance test cycle with named app owners
- Final cutover runbook approved by customer change board
Owner: CWS engineer pair + customer change advisor - 04
Phase 4 — Cutover
1 weekend- Cutover during pre-approved change window
- Live traffic flip with validated rollback plan
- Post-cutover monitoring during the next business day
- Hot fixes for any policy gaps surfaced in the first 24 hours
Owner: CWS engineer pair on-site or remote per engagement - 05
Phase 5 — Stabilization and Optimization
4 weeks- Daily review for first 5 business days, then weekly
- Policy tuning based on observed traffic
- Decommission plan for the legacy Fortinet platform
- Handover to customer team or to CWS managed services if continuing
Owner: CWS lead engineer
Policy translation: FortiGate to Palo Alto syntax.
CWS uses Palo Alto Expedition for the bulk of automated policy translation. Expedition translates roughly 60 to 80 percent of Fortinet rules cleanly. The remaining rules require senior engineer review: shadowed rules, complex NAT, application-specific rules where FortiGate's app control does not map directly to App-ID. Every translated rule is documented with its Fortinet source and the rationale for any deviation. CWS will not run a migration where the customer's policy hygiene makes safe translation impossible; in those cases, the engagement starts with a policy-cleanup phase before translation.
Translation accuracy is what protects the migration from running long. CWS senior engineers review every Expedition output against the source policy in three passes: structural correctness, security equivalence, and operational fit. Any rule that cannot be translated cleanly is annotated and queued for the customer's network owner to clarify intent before cutover. This is the single most important quality gate in the engagement and the one that decouples migration risk from policy complexity.
Change management, language, and regulator alignment.
- Change management aligned with CCCS and ITSG-33 requirements
- French-language change documentation produced for executive and audit audiences when required
- Coordination with Canadian MSSPs and SIs already involved in the customer estate
- Cutover scheduling that respects Canadian weekend (Saturday-Sunday post-2022 alignment)
CWS coordinates with UAE customer change boards, MSSPs, and SIs operating in adjacent layers of the stack. Bilingual artifacts in English plus Arabic, French, or Hindi are produced where audit and audience require them. Telemetry and configuration backups stay inside UAE infrastructure where regulators expect sovereignty.
Fixed-scope, per-firewall pricing.
Per-firewall fixed-scope pricing. Typical Canadian engagement for 4 to 10 firewalls, 1,000 to 5,000 users, runs 6 to 10 weeks at a fixed AED price band that CWS provides during scoping. Larger estates priced per phase.
What's not included
- Hardware procurement (CWS will recommend; customer purchases through preferred channel)
- Third-party integrations beyond the agreed scope (additional integrations are change-controlled)
- Steady-state operations (handover to customer team or to CWS managed services as a separate engagement)
- Training (offered as a separate engagement)
Want a fixed-fee quote for your estate? Talk to a CWS engineer for a discovery call and a written quote within five business days.
Frequently asked: Fortinet to Palo Alto migration
How long does a Fortinet to Palo Alto migration take in Canada?
Typical Canadian enterprise migrations of 4 to 10 firewalls run 6 to 10 weeks end-to-end including 1 weekend cutover. Smaller branch-only migrations can complete in 4 weeks. Larger estates (20+ firewalls) split into phases and run 12 to 20 weeks.
What is the cutover risk?
Risk is contained to the agreed cutover window. CWS runs the migration parallel-cut: the new Palo Alto platform is built and validated before any traffic moves. Cutover is a configurable change with documented rollback. Any rule gaps surface during the validation phase, not during cutover.
Can CWS translate complex Fortinet policies?
Yes. Palo Alto Expedition handles the bulk; CWS senior engineers review and translate the rest. Complex NAT, custom services, and Fortinet-specific application controls are documented and translated explicitly. CWS will flag policies that should be cleaned up rather than translated.
Will my SIEM keep working through the migration?
Yes. CWS configures Palo Alto log forwarding to your existing SIEM as part of the build phase. Log format differences between Fortinet and Palo Alto are normalized in the SIEM ingestion layer. Any custom dashboards built on Fortinet-specific fields are flagged for rework.
What about identity and User-ID?
Fortinet user-to-IP mapping (FSSO or similar) translates to Palo Alto User-ID. CWS evaluates whether the existing source (AD, NPS, captive portal, SSO) needs new agents or whether agentless syslog parsing covers the requirement. The decision is made in Phase 1.
Do I need new hardware?
Almost always yes. Migration assumes new Palo Alto NGFWs. Sizing is a Phase 1 deliverable, mapped to current FortiGate throughput plus headroom. CWS provides the sizing recommendation; customer procures hardware through their preferred channel.
Can CWS run the migration without on-site presence?
Most phases are remote. Cutover is typically on-site for one weekend. For Canadian customers, on-site presence is included in the fixed-scope price.
Ready to scope a Fortinet to Palo Alto migration?
Book a 30-minute call. Get a fixed-scope migration quote in 5 business days.