How to run a managed service and a self-serve platform simultaneously without breaking either. Resource allocation, customer migration sequence, and sunset criteria. Specific timelines populate once L3 GA date is confirmed.
Ch 12 of Shrink-Wrap It identifies the transition period as the highest-risk phase for boundary violations: "Before agreeing to any feature involving new data flows, new integrations, or new data types, consult your ISSO or compliance team. What seems like a simple enhancement may constitute a boundary change." During the L2-to-L3 transition, NorthAI is running two product modes simultaneously. A boundary change in one mode can cascade to the other if the architecture is not cleanly separated.
This plan treats L2 and L3 as distinct authorization boundary states during the transition period. L2 customers remain on the original SSP. L3 customers are on the updated SSP that includes the self-serve control plane. These are two different system boundaries until the last L2 customer migrates.
| Dimension | L2 track (existing customers) | L3 track (new customers + migrated L2) |
|---|---|---|
| Provisioning | Manual runbook; NorthAI ops staff; 1-2 week SLA | Self-serve portal; API-driven; 24-hour SLA |
| Authorization boundary | Original SSP; 3PAO assessed; existing ATO covers L2 customers | Updated SSP includes control plane API; 3PAO assessed; separate ATO or ATO modification required |
| ConMon | Original ConMon scope; existing scanning and POA&M procedures | Expanded ConMon scope covers control plane; additional scanning targets; larger POA&M surface |
| Customer success | NorthAI CS actively manages all L2 customers; manual touchpoints per nps-outcome-cadence-v0 | Reduced CS involvement for L3; product-led support; escalation path still maintained |
| Incident response | L2 incident affects only L2 customers; L3 unaffected (separate infrastructure) | L3 incident affects only L3 customers; L2 unaffected |
| Engineering support | Maintenance mode after L3 launch; bug fixes only; no new features | Active development; new features, optional modules, marketplace integrations |
The mixed-fleet period creates a resource split that must be planned explicitly. The default allocation below shifts over the transition period. Engineering head count numbers are placeholders.
| Period | L2 allocation | L3 allocation | Rationale |
|---|---|---|---|
| Pre-L3 launch (through Q8) | 80% engineering; 100% ops; 100% CS | 20% engineering (control plane build); 0% ops; 0% CS | L2 is the revenue engine; L3 build is background investment. Do not starve L2 ops. |
| L3 launch through 50% migration | 50% engineering; 60% ops; 60% CS | 50% engineering; 40% ops; 40% CS | Parallel operation; new customers on L3; L2 customers still need full support during migration planning |
| 50% migration through final migration | 20% engineering; 30% ops; 30% CS | 80% engineering; 70% ops; 70% CS | L2 is winding down; investment shifts to L3; L2 ops maintained until last customer migrates |
| Post-migration (L3 only) | 0% (L2 sunset) | 100% engineering; 100% ops; 100% CS | Full investment in L3; no mixed-fleet overhead; ConMon scope simplified |
The migration sequence is not first-in, first-out. It is risk-ordered: migrate customers whose migration poses the least authorization risk and disruption first, then work toward the most complex migrations.
| Migration priority | Customer profile | Why this priority |
|---|---|---|
| Priority 1 | Customers with the fewest Zone 3 (optional module) customizations; lowest integration complexity; smallest user counts | Lowest migration risk; fastest to validate L3 migration process; builds confidence before complex customers |
| Priority 2 | New customers onboarded after L3 launch; they never had L2 infrastructure; no migration needed, just L3 from start | Zero migration cost; these customers validate L3 natively; track separately from migration metrics |
| Priority 3 | Customers with medium complexity: 1-2 Zone 3 modules, moderate user counts, standard ICAM integration | Migration process is validated from Priority 1; apply lessons learned; allow 2-3 week migration window per customer |
| Priority 4 | Customers with highest complexity: custom ICAM integrations, multiple Zone 3 modules, large user counts, or specific ATO constraints | Migrate last; most stakeholder management required; may require a dedicated migration sprint per customer |
| Step | Activity | Timeline | Owner |
|---|---|---|---|
| 1 | Migration briefing: explain L3 benefits, migration process, and the absence of service disruption to agency PM and ISSO | Week 1 | Customer Success |
| 2 | L3 tenant provisioning: stand up new L3 tenant in parallel; do not decommission L2 environment yet | Week 1-2 | Platform Architect |
| 3 | Data migration: copy existing configuration, audit logs, and user roster from L2 to L3 tenant; validate completeness | Week 2-3 | Platform Architect |
| 4 | Parallel running: L3 tenant is live but L2 is still primary; agency runs both for 5-7 business days; no disruption to production | Week 3-4 | Platform Architect + Customer Success |
| 5 | Cutover: agency ISSO confirms L3 readiness; cutover switch thrown; L2 decommissioning scheduled | End of Week 4 | Authorization Architect + Agency ISSO |
| 6 | L2 decommission: after 30-day post-cutover monitoring period with no issues; L2 environment removed from inventory | Week 8 (30 days post-cutover) | Platform Architect |
L2 is fully sunset when all of the following are true:
The L2 decommission process is itself a boundary change event. Every L2 environment removed from the authorization boundary must be documented in the SSP as a scope reduction. The 3PAO must confirm the reduction does not inadvertently remove a control that was shared between L2 and L3. Treat sunset as a mini-assessment, not a cleanup task.