Juniper SD-WAN + Mist Rollout Checklist: 9 Steps I Use After $40K in Mistakes

Who this Juniper SD-WAN, Mist, and EX3300 checklist is for

If you're rolling out Juniper SD-WAN, onboarding sites into Mist, or replacing aging Juniper EX3300 switches, this checklist is for you. It's written for network engineers, VARs, and IT leads who need a repeatable cutover process. I've handled enterprise network orders and deployments for 9 years. I've personally made—and documented—11 significant mistakes, totaling roughly $40,000 in wasted budget, licensing, and after-hours rework. Now I keep this list pinned in our team workspace.

Nine steps. No theory. If you're doing a single closet, you can skip a few. For 10+ sites, don't.

5 minutes of verification beats 5 days of correction.

Step 1: Verify hardware lifecycle before you schedule anything

Start with the boring stuff. If Juniper EX3300 switches are in the plan, confirm their end-of-life and end-of-support status on Juniper's official site. According to Juniper's EX3300 end-of-life notices (juniper.net), that platform is past its supported lifecycle; verify current dates and service availability before you promise a firmware upgrade or repair path.

In my first year, I made the classic assumption error: I treated EX3300 as 'just another access switch' and scheduled a Junos upgrade during a maintenance window. It wasn't supported. We lost $1,200 in overtime and had to overnight a replacement. Now I check EOL before I check port counts.

Step 2: Build the underlay before the Juniper SD-WAN overlay

Juniper SD-WAN will not fix a bad underlay. Before you touch overlay tunnels or policy, validate circuits, MTU, NAT behavior, firewall exemptions, and DNS. If you are using Mist WAN Assurance, make sure the WAN edge devices are adopted and reporting before you cut production traffic.

I once enabled SD-WAN policies before the underlay was stable. Tunnels flapped, the business policy misclassified VoIP, and we spent two nights troubleshooting something that was really a circuit issue. To be fair, the CLI-only approach can be faster for a single lab device. But for branch rollouts, underlay first is non-negotiable.

Step 3: Create a configuration group or site group before production changes

Here's the group step most people skip. In Junos, use configuration groups and commit confirmed for rollback safety. In Mist, use site groups, templates, and variables so you are not hand-editing every device. These are not the same kind of group—Junos groups are configuration inheritance; Mist site groups are management boundaries. Mixing them up causes confusion.

Define naming conventions early: site code, role, floor, switch number. It takes 10 minutes. It saves hours when someone asks, 'Which EX3300 did we replace?'

Step 4: Stage devices in Mist before claiming them into production

Do not claim every AP or switch directly into the production Mist org. Use a staging site group. Verify claim codes, serial numbers, and subscription assignments there first. According to Juniper's Mist documentation (juniper.net/documentation), Mist AI relies on accurate inventory and telemetry, so bad inventory data creates bad automation.

We once claimed 40 access points into the wrong site group. The dashboard looked fine until we pushed a template. That error cost about $2,100 in licensing reassignment and after-hours cleanup. Now our checklist has a claim-code photo step.

Step 5: Match licenses to devices before cutover night

Mist subscriptions, SD-WAN licenses, support contracts, and feature licenses all need to line up. A device can be physically perfect and still fail to adopt because the subscription is missing or assigned to another site. Check the Mist dashboard and your Juniper account before the maintenance window.

We had 37 licenses for 40 devices once. It was probably an ordering typo—maybe 37, maybe 38, I'd have to check the old PO. The result was the same: three devices sat unadopted while everyone waited.

Step 6: Use templates and variables instead of manual CLI edits

Everything I'd read about branch networking said some manual configuration was needed for flexibility. In practice, with 60+ sites, templates and variables beat manual edits almost every time. Standardize VLANs, DNS, NTP, syslog, and SNMP. Then allow a small variable set for site-specific IPs and circuit details.

Manual edits create drift. Drift creates outages. I learned this after a typo in an NTP server address caused certificate errors across a site. That was a $600 lesson in copy-paste discipline.

Step 7: Test SD-WAN policies and failover before the window

Configure application policies, SLA probes, and failover in a lab or pilot site. Test VoIP, Teams/Zoom, and business-critical SaaS. Verify what happens when the primary circuit drops. Juniper SD-WAN is powerful, but it follows your policy—including the bad ones.

It took me 3 years and about 150 device rollouts to understand that cutover night is not the time to test policy. The conventional wisdom is to 'validate in production.' My experience suggests validating in a pilot rack first.

Step 8: Pack the field kit—including the weird stuff

Your field kit should have console cables, USB adapters, Ethernet testers, labels, power strips, and a charged LTE hotspot. If the site still uses an old emergency phone, add it to the list. I know this sounds off-topic, but a dead flip phone can block a site contact number during cutover.

Here is how to turn on flip phone basics for your field kit: plug it into a charger for a few minutes, press and hold the End/Power button for 2–3 seconds, and release when the screen lights. If nothing happens after 30 seconds, try a different charger or battery. Do not spend 20 minutes discovering the battery is in backwards.

That was a real delay on a site where the only fallback contact number was on a flip phone. Not a Juniper problem, but still a rollout problem.

Step 9: Cut over with rollback and hypercare

Have a rollback config ready, use commit confirmed where applicable, and keep the old path documented. After cutover, monitor Mist AI alarms, SD-WAN SLA metrics, and switch port errors for at least 24 hours. Assign one person to watch the dashboard and one to handle calls.

Granted, hypercare requires more upfront staffing. But it saves the 'everything looked fine at 2 a.m.' surprise at 9 a.m.

Common mistakes to check before you start

• Assuming EX3300 can run current Junos. Verify EOL and supported releases on juniper.net.
• Treating Junos configuration groups and Mist site groups as interchangeable.
• Claiming devices into production before staging in Mist.
• Skipping license reconciliation because 'it worked in the lab.'
• Forgetting physical access details: rack keys, badge access, console access, and yes, that flip phone.
• No rollback plan because the change window 'should be quick.'

The 9-step checklist I created after my third major mistake has saved us an estimated $8,000 in potential rework. I don't think it's perfect. It is just cheaper than another 2 a.m. rollback.