SASE Migration Planning Workbook

A thorough pre-migration assessment forms the foundation for a successful SASE deployment. The assessment must inventory every security and networking component that iboss will replace, augment, or integrate with. Begin with a comprehensive catalog of current security infrastructure: firewall appliances at each building (vendor, model, firmware version, throughput capacity, current utilization), web content filtering systems (on-premises appliances or cloud subscriptions), VPN concentrators and remote access solutions, standalone proxy servers, intrusion detection/prevention systems, and any existing CASB or DLP deployments.

Bandwidth analysis per building is critical for sizing the iboss deployment and setting performance baselines. Collect current internet circuit capacity (speed and provider) for each building, peak and average bandwidth utilization, and the percentage of traffic that is currently SSL-encrypted. Understanding the ratio of encrypted to unencrypted traffic is important because iboss will inspect all encrypted traffic, which may represent workload that current firewall appliances are not handling due to SSL inspection being disabled. Document any bandwidth shaping or QoS policies currently in place that will need to be replicated in the iboss configuration.

The user count and device inventory should capture the total number of users by role (students, teachers, staff, administrators), the device types and operating systems in use (Windows, macOS, Chrome OS, iOS, Android), the mobile device management platform in use and its enrollment coverage, and the number of personally owned devices that access district resources. The application catalog should document all SaaS applications, cloud-hosted resources, and on-premises applications that users access, noting any applications that require special proxy handling, certificate pinning exceptions, or unique authentication flows.

• Firewall inventory: vendor, model, firmware, throughput, utilization per building
• Web filter and proxy infrastructure: current solutions, policy rule counts, custom categories
• VPN and remote access: concentrator locations, concurrent session capacity, client types
• Bandwidth per building: circuit capacity, peak/average utilization, encryption percentage
• User and device inventory: counts by role, OS type, MDM enrollment status
• Application catalog: SaaS apps, cloud resources, on-premises apps, special handling needs
• Current policy documentation: filtering rules, access policies, exception lists

The migration strategy should align with the district's risk tolerance, operational calendar, and available project resources. Three primary strategies are available, each with distinct trade-offs in terms of speed, risk, and operational complexity.

The pilot school approach is the lowest-risk strategy and is recommended for most districts. A single building is selected for the initial iboss deployment, typically chosen for its manageable size, cooperative building administration, and proximity to the district IT team. The pilot school operates on iboss while all other buildings remain on legacy infrastructure. This approach allows the team to validate policies, train help desk staff, and identify application compatibility issues in a controlled environment before broader deployment. The primary drawback is timeline: a pilot school approach adds 2-4 weeks to the overall migration.

The phased rollout deploys iboss to multiple buildings in defined waves, typically grouping buildings by size, type (elementary, middle, high), or geographic proximity. Each wave benefits from the lessons learned in previous waves, and the deployment team becomes progressively more efficient. This approach balances speed with risk management and is appropriate for medium to large districts.

The big-bang approach deploys iboss to all buildings simultaneously. This strategy is only recommended for small districts with fewer than 5 buildings, where the complexity is manageable and the operational benefit of a single cutover outweighs the risk of simultaneous deployment. Regardless of strategy, all approaches should include a parallel operation period where legacy systems remain available as fallback, and all should be scheduled to avoid standardized testing windows, the first two weeks of school, and other high-sensitivity periods.

Pilot school selection should prioritize a building that is representative of the broader district environment while being operationally manageable. An ideal pilot school has 200-500 devices, a mix of device types representative of the district (Windows, Chromebooks, or both), a cooperative building principal and technology coordinator, and physical proximity to the district IT team for rapid onsite support during the pilot period. Avoid selecting the largest or most complex building for the pilot, as initial deployment challenges will be easier to resolve at smaller scale.

Define explicit success criteria before the pilot begins. Quantitative metrics should include: 100% of managed devices routing traffic through iboss, web filtering policy parity with existing solution (measured by testing a defined set of URLs against expected allow/block outcomes), SSL inspection operational on at least 95% of HTTPS traffic, latency not exceeding current baseline by more than 5ms for educational applications, and zero unresolved help desk escalations related to iboss blocking legitimate educational resources.

The pilot timeline should span approximately two weeks. During the first week, the iboss tenant is configured with the pilot school's policies, agents or PAC files are deployed to the pilot school's devices, and the deployment team monitors for policy gaps and application compatibility issues. The second week focuses on operational validation: help desk staff handle real support requests, teachers use the classroom management interface, and the team collects structured feedback from educators and students. A daily standup meeting during the pilot ensures that issues are identified and resolved quickly, and a formal pilot review at the end of week two determines readiness to proceed to broader deployment.

Following a successful pilot, the controlled rollout phase extends iboss deployment to additional buildings in defined waves. Wave composition should be determined by the migration strategy selected during planning. In a typical phased approach, wave one includes 2-3 buildings similar in profile to the pilot school, wave two expands to 4-6 buildings including more complex environments, and subsequent waves cover the remaining buildings.

Policy refinement from pilot learnings is a critical activity before each wave. The pilot will inevitably reveal URLs, applications, or workflows that require policy adjustments. These refinements, whether adding SSL inspection bypass rules for specific educational applications, adjusting content category overrides, or modifying bandwidth management policies, should be implemented and tested before the next wave begins. Maintain a living document of policy exceptions and their justifications to ensure institutional knowledge and facilitate future audits.

Help desk preparation scales with each wave. Before wave one, all tier-one help desk staff should complete iboss troubleshooting training covering the most common user-facing issues: certificate warnings, blocked site requests, agent reinstallation, and PAC file verification. A troubleshooting runbook with step-by-step resolution procedures for the top 10 anticipated issues should be distributed before each wave. Monitoring dashboards should be configured to give help desk supervisors real-time visibility into iboss-related support tickets, agent health across buildings, and policy violation trends that might indicate misconfiguration.

The final deployment phase covers the remaining buildings and transitions the district to iboss as the sole security platform. This phase should not begin until the controlled rollout has validated that policies are stable, help desk processes are mature, and no unresolved compatibility issues exist. The remaining buildings cutover can proceed at an accelerated pace because the deployment playbook is proven and the team is experienced.

Legacy system decommission should follow a defined schedule with appropriate holdback periods. After all buildings are operational on iboss, legacy firewall appliances should remain powered on and configured but no longer carrying production traffic for a minimum of 30 days. This standby period provides a safety net for rollback if unforeseen issues emerge. After the standby period, legacy systems are formally decommissioned: configurations are archived, appliances are powered down, and the district initiates hardware asset disposition according to its surplus equipment policies.

Contract termination for legacy security products should be coordinated with the migration timeline. Review all existing security product contracts for termination terms, early termination penalties, and renewal dates. Ideally, the migration should complete before the next contract renewal date to avoid paying for overlapping coverage. If contracts have multi-year terms with early termination fees, calculate whether the fee is less than the remaining contract value and factor this into the migration business case. Provide vendors with written notice of non-renewal as required by contract terms, and ensure that any data stored by cloud-based legacy services (logs, reports, configurations) is exported before contract termination.

Rollback procedures must be documented, tested, and immediately executable at every phase of the migration. A rollback is warranted when iboss deployment causes unacceptable disruption to instructional activities, when a critical application is incompatible with iboss and no workaround is available before the application is needed, or when security policy enforcement does not meet compliance requirements.

The rollback trigger criteria should be defined quantitatively before the migration begins. Recommended triggers include: more than 5% of devices unable to access required educational resources through iboss, latency exceeding baseline by more than 20ms for tier-one applications (SIS, LMS, assessment platforms), SSL inspection causing failures on more than 3 critical applications with no available bypass, or help desk ticket volume exceeding 200% of normal baseline for iboss-related issues persisting beyond 48 hours.

The step-by-step rollback process varies by deployment model. For agent-based deployments, the iboss agent is uninstalled via the MDM platform, and the device automatically reverts to direct internet access through the legacy firewall. For PAC file deployments, the Chrome Enterprise policy is reverted to remove the iboss PAC file URL, and Chromebooks resume direct browsing through the existing network path. In both cases, the legacy firewall appliances must remain operational and carrying the default route for internet traffic until the migration standby period has elapsed. Data preservation during rollback is essential: all iboss logs, policy configurations, and deployment documentation should be archived before any rollback to support root cause analysis and re-deployment planning.

• Trigger: >5% of devices unable to access required educational resources
• Trigger: Latency exceeding baseline by >20ms on tier-one applications
• Trigger: SSL inspection failures on >3 critical applications without available bypass
• Trigger: Help desk volume >200% of baseline for iboss issues persisting >48 hours
• Agent rollback: MDM-initiated uninstall, automatic reversion to legacy path
• PAC rollback: Chrome policy reversion, immediate direct browsing restoration
• Legacy systems must remain operational in standby throughout migration

The first 30 days after full deployment provide the data needed to optimize iboss policies and configurations for the district's specific environment. During this period, the iboss analytics dashboard reveals actual usage patterns, policy hit rates, and performance metrics that inform targeted optimization.

Policy tuning should focus on three areas. First, identify over-blocked categories and URLs by reviewing the most frequently blocked request logs and validating that each block is intentional. Teachers and librarians are valuable resources for identifying legitimate educational sites that are incorrectly categorized. Second, identify under-protected areas by reviewing allowed traffic for categories or applications that should be restricted. Third, optimize SSL inspection bypass rules: the goal is to minimize bypasses while maintaining application compatibility. Each bypass should have a documented justification and should be reviewed quarterly.

Performance benchmarking should compare post-migration metrics against the pre-migration baselines captured during the assessment phase. Key metrics include page load time for the district's most-used web applications, latency to educational SaaS platforms (Google Workspace, Microsoft 365, LMS, SIS), and throughput during peak usage periods. If performance regression is identified for specific applications, iboss traffic routing rules and optimization policies can be adjusted. User satisfaction should be measured through structured surveys distributed to teachers, building technology coordinators, and a representative sample of students, with results compared against any satisfaction data collected before the migration.

Effective migration project management requires a defined governance structure and standardized communication cadences. The RACI matrix should identify roles for the project sponsor (typically the CTO or Director of Technology), the project manager (Calbrate engagement lead or district IT manager), the technical implementation team (Calbrate engineers and district network administrators), the building technology coordinators (responsible for building-level coordination), and the help desk team (first responders for user issues). Each migration task should have a clearly assigned responsible party, with accountability for milestone completion resting with the project manager.

The Gantt chart should define milestones for each phase: pre-migration assessment completion, pilot school go-live, each rollout wave go-live, legacy system decommission, and post-migration optimization review. Critical path items include identity provider integration (which must be complete before any user deployment), MDM agent packaging and testing (which must be validated before agent rollout), and SSL inspection certificate distribution (which must propagate to all devices before SSL inspection is enabled). Dependencies between milestones should be explicitly mapped to prevent scheduling conflicts.

The risk register should be maintained as a living document throughout the migration, with risks assessed for probability and impact on a standard scale. Common migration risks include: application compatibility issues discovered after pilot (medium probability, high impact), help desk overwhelm during large wave deployments (high probability, medium impact), identity provider integration delays (low probability, high impact), and stakeholder resistance from teachers unfamiliar with new filtering behavior (medium probability, medium impact). Each risk should have a defined mitigation strategy and a contingency plan. The communication plan should define weekly status reports to the project sponsor, daily standby notifications during active deployment waves, and pre-deployment communications to building administrators and teachers explaining what to expect.

• RACI matrix: sponsor, project manager, technical team, building coordinators, help desk
• Gantt chart: milestones for assessment, pilot, each rollout wave, decommission, optimization
• Risk register: probability/impact assessment, mitigation strategies, contingency plans
• Communication plan: weekly sponsor updates, daily deployment notifications, user communications
• Status report template: completed milestones, active risks, upcoming tasks, decisions needed