Two weeks of senior FortiGate work, scoped before anything ships.

Fixed-scope. Two weeks. The change you need — hardening, SD-WAN, SAML to Entra, FortiOS upgrade, or migration — picked on the assessment call. Pre-audit, lab rehearsal, execution, and one week of post-engagement support. Runbook and config templates included.

2-week sprint
FortiOS 7.4 / 7.6 production
Bilingual runbooks · EN or ES

Free 30-min assessment →

Most FortiGate shops sit on the same shape of problem: a single device or HA cluster that has accumulated five years of policy drift, three half-finished projects, and one open ticket that the team is waiting to close before they can start the next one. They don’t need a different vendor; they need someone senior on the keyboard for two weeks who can decide what stays, what goes, and what the rollback looks like.

This is that engagement. Two weeks, fixed-scope, scoped on the assessment call against your actual environment.

What you get

Pre-engagement audit · current config exported, version + hardware confirmed, dependencies mapped. The audit lands end of Week 1 even if the change window slides to Week 2.
Change design · written design covering whichever scope you picked. Same template across engagement types — context, decisions, alternatives we rejected, what we'll touch and what we won't.
Lab rehearsal · changes applied to a representative test setup before they touch production. Pre-checks, the change itself, post-validation — all rehearsed.
Execution window · we're on the bridge during the change. Your engineers run the commands; we're there to catch what rehearsal didn't surface. After-hours window if cutover is involved.
One week of post-engagement support · weekday business hours, Slack or email. Edge cases, follow-up questions, monitoring noise that needs interpretation.
Runbook + config templates · written so a Tier 2 engineer can re-run the same change on the next site without re-engaging us. The runbook is part of the deliverable, not an afterthought.

Common engagement shapes

You pick one on the assessment call. The 2-week shape stays the same; the content fills in:

Hardening pass · config review against FortiOS 7.4 / 7.6 best-practice baselines. Admin access posture, logging, FortiGuard tier coverage, policy hygiene, SSL VPN posture if still enabled. Top fixes implemented during the engagement.
SD-WAN bring-up · single-WAN to multi-WAN with sane health checks, traffic steering rules, application identification, and a failover behavior you can describe to your CFO.
SAML + Entra ID integration · SSO for FortiGate admin access, VPN auth, or both. Conditional Access policies on the Entra side aligned with the FortiGate posture.
FortiOS upgrade · across a major-version boundary (7.2 → 7.4, 7.4 → 7.6). Breaking-change review, pre-checks, upgrade window, post-upgrade validation, rollback plan.
FortiSwitch / FortiAP integration · adding FortiLink-managed switches or APs to an existing FortiGate. VLAN design, PoE budget, RADIUS / SAML integration as needed.
VPN modernization · SSL VPN to IKEv2 IPsec ahead of the Fortinet deprecation, IPsec site-to-site cleanup, or moving from PSK to certificate auth. The SSL VPN migration checklist is the public version of this playbook.

Multi-firewall, multi-site, or projects that legitimately need more than two weeks are different shapes — flag them on the assessment call.

Scope

One FortiGate (single device or HA cluster) · hardware that supports FortiOS 7.4 / 7.6 — most 60F / 100F / 200F families and newer.
One change picked from the shapes above. If your environment needs two of these at once, we can talk about combining on the assessment call — sometimes it's a clean extend, sometimes it's two engagements.
Auth shape stays where it is unless the engagement is explicitly the SAML / Entra integration. Auth-backend migrations alongside another change reshape the engagement.

Timeline — two weeks, end to end

Mon (Week 1) · kickoff. Access confirmed, current config pulled, version + hardware confirmed.
Tue–Wed (Week 1) · audit + scope lock. Current state mapped, dependencies surfaced, the change design committed in writing.
Thu (Week 1) · runbook draft. Step-by-step CLI / GUI sequence, pre-checks, validation checklist, rollback path. Runbook circulated for review.
Fri (Week 1) · lab rehearsal. Changes applied to a representative test setup; pre-checks, the change itself, post-validation rehearsed. Runbook updated based on what rehearsal surfaced.
Execution window (Week 2). Saturday night if cutover is involved (VPN modernization, FortiOS upgrade); weekday business hours if it isn't (hardening pass, FortiSwitch integration). We're on the bridge. Typical window: 2–4 hours including post-change validation.
Mon–Fri (Week 2 remainder) · post-engagement support. Weekday business hours. Edge cases, follow-up questions, monitoring noise.

If rehearsal surfaces something material — a discovered hardware incompatibility, a load-bearing dependency nobody knew about — we flag it, re-scope honestly, and either continue or pause. Better to extend than to ship a half-tested change.

When this is the right fit

Production FortiGate (single device or HA cluster) that needs a defined change with senior eyes.
FortiOS 7.4 / 7.6 (or 7.2 with a viable upgrade path inside the engagement).
Mid-market environment where the team is the right team to operate the box long-term, but a specific change has been on the backlog long enough that someone external should do it.
LATAM SMB where the network team is one or two people and an extra senior pair of hands for two weeks unblocks a quarter of planning.

When this isn’t the right fit

Dozens of FortiGates across many sites where the change needs to scale — that’s a multi-engagement program (talk to us about it).
Cisco, Palo Alto, SonicWall — we don’t pretend to do those at production grade.
Brand-new FortiGate deployment from zero — possible, but the shape is closer to a project than a sprint. The consulting page covers that flow.
Pure-design or pure-strategy engagements where nothing actually changes in production. The audit (security architecture review) is the better starting point for that.

Frequently asked

How do we pick the scope?

On the 30-min assessment call. We walk through your current environment, what's been on the list, what's blocking the team, what the deadline pressure looks like. The scope locks in writing after the call. If the scope changes mid-engagement, we re-scope in writing too — no surprise drift.
Can we combine scopes — say, hardening pass plus SAML integration?

Sometimes. Lightweight combinations work (e.g. hardening pass that includes the SAML config rewrite). Heavier combinations (SD-WAN + FortiOS upgrade) are realistically two engagements back-to-back. Honest assessment on the call.
Do you upgrade FortiOS if needed?

Yes. If the change you picked depends on a feature that landed in 7.4 or 7.6 and you're on an older version, the upgrade is part of the engagement — pre-checks, upgrade window, post-validation. We don't do that work invisibly — you'll see it in the audit document and the runbook.
What's the rollback plan?

Written in the runbook, rehearsed in the lab, and on the bridge call during the change window. Old configs don't get deleted during execution — they get disabled or replaced with versioned templates. If something material breaks post-change, we restore service first and re-scope the next attempt. Restore + retry beats ship-anyway.

Ready to scope it? Free 30-min assessment ↑ or email cflores@packetloss.tech directly.