Having recently completed the onboarding process for a Versa Networks SASE deployment, I wanted to document the procedural flow and technical expectations for other architects embarking on this path. The period between signing the contract and achieving a fully operational, policy-enforced state involves several distinct phases, each with its own lead times and configuration complexities. My experience was with a multi-region deployment targeting approximately 500 branch endpoints.
The initial phase is provisioning, which is largely a vendor-led exercise. Expect a 2-3 week lead time before you receive your tenant portal credentials. This period is used by Versa to spin up the necessary controller instances (Director, Analytics, etc.) in their cloud or your chosen data center region. You will receive several URLs and a set of initial admin credentials. **Immediately** change these and configure SAML/SSO integration if your organization requires it; the identity provider configuration is a prerequisite for scaling user access.
Upon first login, you will be confronted with the core hierarchy, which is critical to understand:
* **Organization:** The top-level container.
* **Tenant:** Typically maps to a business unit or a major geographic division.
* **Location Group:** A logical grouping of physical sites (e.g., "EMEA-Branches").
* **Location:** The individual branch or data center entity.
A common pitfall is mis-modeling this hierarchy, which later impedes template application. I recommend scripting this structure creation via their REST API if you have more than a trivial number of locations. Below is a simplified example of the JSON payload for creating a location via their API.
```json
{
"location": {
"name": "branch-nyc-01",
"location-group": "US-Branches",
"address": "123 Main St, NYC",
"contact": "[email protected]"
}
}
```
The next stage involves **device onboarding**. This is where the Versa Operating System (VOS) images are deployed on your physical appliances or as virtual machines. The key artifact is the `bootstrap.xml` file. This file must be meticulously crafted for each device or device group, containing the initial configuration to locate the Versa controllers. An error here will prevent the device from establishing its control plane. You will need to:
1. Generate a unique certificate/serial number for each device from the portal.
2. Embed the controller FQDNs, ports, and this serial number into the `bootstrap.xml`.
3. Host this file on a local HTTP/S server accessible by the device at boot.
Once devices bootstrap and appear in the Director UI as "Connected," the real configuration work begins. You will be applying service templates (for SD-WAN, Security, Routing) and CLI templates from the Director to these locations. Expect to spend significant time in a staging tenant, validating policy inheritance and application order. The path-matching and policy application logic follows a specific order of precedence, which is not always intuitive. Thorough testing of failover scenarios (e.g., WAN link down, controller connectivity loss) is mandatory before production cut-over.
Finally, be prepared for the operational shift. The Versa Analytics portal is powerful but has a steep learning curve. Building custom dashboards to monitor application performance, tunnel health, and threat metrics requires a solid understanding of their data model. Allow for a 4-6 week period of iterative configuration tuning post-initial deployment to stabilize policies and fully integrate with your existing monitoring and ITSM workflows.
Good point about changing the default credentials right away. I'd add that you should get your SAML integration sorted *before* you start inviting other team members. We learned the hard way that having local accounts mixed with SSO logins creates a mess for permission auditing later.
Your timeline is spot on, but the 2-3 week wait can sometimes be used productively. I'd recommend finalizing your IP address plans and sketching out that site hierarchy during that downtime. It saved us a ton of time once portal access came through.
Data doesn't lie, but dashboards sometimes do.
Good point about changing the default credentials right away. I'd add that you should get your SAML integration sorted *before* you start inviting other team members. We learned the hard way that having local accounts mixed with SSO logins creates a mess for permission auditing later.
Your timeline is spot on, but the 2-3 week wait can sometimes be used productively. I'd recommend finalizing your IP address plans and sketching out that site hierarchy during that downtime. It saved us a ton of time once portal access came through.
Five nines? Prove it.
Absolutely right about the planning phase during the waiting period. We often suggest teams use that window to map out not just the IP plan and hierarchy, but also their initial template structure for device configurations. It forces a good conversation about standardization before anyone is clicking in the live portal.
Your SAML point is critical for operational hygiene. One caveat we've seen: if your identity provider takes a long time to configure, sometimes you'll need to create a temporary, highly restricted local admin account just to kick off the SAML setup itself. It's a bit of a chicken-and-egg situation, but it's better than having a bunch of permanent local accounts floating around.
—HR
That 2-3 week provisioning window is the make-or-break period. A lot of teams waste it. If you haven't already, use it to nail down your SD-WAN prefix allocations and, crucially, a *naming convention* for everything. You'll regret trying to design that on the fly when you're staring at a blank portal with 500 sites to define.
Also, brace yourself for the interface. It's... dense. The hierarchy is logical once you get it, but the sheer number of policy knobs you can turn from day one is overwhelming. I'd suggest ignoring 70% of it at first and just focusing on getting connectivity templates and a single basic security policy built. Over-complicating the initial config is a sure way to double that onboarding timeline.
YMMV
You're absolutely right about the provisioning wait time, but calling it "vendor-led" is a bit generous. It's more like a black box that happens *to* you. The real trick is getting a solid contact on their side for your deployment coordinator. If you don't, that 2-3 weeks can easily turn into a "we're waiting on internal resources" silence.
Also, brace for the first login to the portal. The hierarchy makes sense on paper, but the UI doesn't guide you through populating it. You'll spend the first hour just trying to figure out which sub-menu holds the button to create your first actual tenant under that pristine Organization they built for you. The sheer number of empty policy buckets staring at you is its own form of paralysis.
Data over dogma.
You've really nailed a key point about the human element. Getting that assigned deployment coordinator's direct line is often the single biggest factor in whether the provisioning window feels like a smooth handoff or a black hole. Sometimes you have to be proactive and ask your sales engineer for an introduction before the paperwork is even dry.
Your note about "policy paralysis" on first login is so accurate. The interface presents you with the full, final state of capability from minute one. I think it helps to remember that you're not meant to fill every bucket on day one. The initial goal is just to get one branch online. Everything else can stay empty until you need it.
—daniel
You've identified the exact friction point in their operational model. That "deployment coordinator" role is often ambiguously defined in the SOW, leading to the black box effect. From a procurement perspective, I've learned to explicitly require the coordinator's name, backup, and a shared project plan as a condition precedent to the initial payment. It forces a tangible handoff.
The policy paralysis is a direct consequence of their "kitchen sink" UI philosophy. A useful tactic is to ask your sales engineer for a single, pre-built demo tenant with a single configured site. Logging into that *populated* state first, even if it's just dummy data, teaches you the navigation flow far better than any blank canvas ever could.
Good to see a clear structure for the initial setup. Your emphasis on the hierarchy is crucial, but I'd add a caution about the **Tenant** level itself. It's often misunderstood as a business unit, but in Versa's model, it's more of a policy and administrative boundary. Teams sometimes create too many tenants early on, thinking they need one per region or division, which creates policy replication work later.
One other practical tip for that first login: ignore the "Getting Started" wizard if it pops up. It tends to jump ahead to creating sites before the foundational templates are built. Go straight to the template section first.
Keep it constructive.
Spot on about the "black box" feeling. The deployment coordinator role is basically a single point of failure. In our rollout, we insisted on a kickoff call with them *and* their backup before we even submitted the order. It made a huge difference in keeping things moving.
And yeah, that policy paralysis is real. My early mistake was trying to define every security policy upfront. It's better to just build a single "allow everything" policy for the first site template, just to get something online. You can lock it down incrementally once you have connectivity verified.
Data > opinions
Absolutely second the "allow everything" first policy. That was the only way I got my first test site up before I lost momentum. The key is to set a calendar reminder to come back and lock it down within a week or so, otherwise it'll stay permissive forever.
Also, getting the deployment coordinator *and* their backup on a call is brilliant. We asked for a shared Slack channel too, which cut down the email lag significantly.
measure twice, ship once
The Tenant point is so important! I've seen teams create one per environment (Prod, Dev, Test) and then spend weeks trying to sync policies between them. It's better to use tags or site groups within a single tenant for that kind of separation.
And yes, 100% on skipping the wizard. It's well-meaning but it puts the cart before the horse. I go straight to the Template Library and build my first device and service template before I even think about defining a site. That way, when the wizard (or my own process) prompts for a site template, I have the building blocks ready.
null
The "black box that happens to you" is the perfect description. It's essentially a queue you're placed in. In my experience, this is where providing your optimal site list and prefix details *before* the SOW is signed can actually shorten the real clock. It gives their provisioning team a head start, making the silent period feel less opaque.
On the policy paralysis, I'd suggest a different initial target than finding the button to create a tenant. Instead, locate the template library first. If you can import a basic starter template from their exchange or a previous project, you'll have a reference structure that makes populating that blank hierarchy much less daunting. The empty buckets look less intimidating when you can see the shape of what should fill them.
Your bill is too high.
3 weeks they say? I hope you factored in a buffer for their "automated" provisioning to fail the first time and get stuck in a manual queue.
And that hierarchy chart they love to show? It's neat until you realize you can't move a site between tenants. Pick wrong and you're rebuilding from scratch. That's the real first test.
Trust but verify.
The provisioning buffer is a non-negotiable part of planning. Their automation is reliable for standard deployments, but any non-standard element, like a non-standard ISP or a complex BGP configuration, will trigger a manual review and introduce unpredictable delay.
You've identified the critical, irreversible decision: tenant placement. It's not just sites; it's the entire policy and template inheritance chain. A common but costly mistake is creating a tenant per geographical region, only to later need a global security policy that now requires replication across multiple, disconnected administrative domains. The functional boundary for a tenant should be a complete administrative and policy boundary you are willing to manage separately forever.
—BJ