Why vendor lock-in still dominates procurement.
Most enterprise network teams do not set out to achieve full vendor lock-in.
It accumulates through years of individually reasonable purchasing decisions. You buy the best switch for this data center, the best SD-WAN appliance for that branch, and a cloud networking product that ships with its own controller.
Before long, your operations team manages four separate orchestration tools, none of which talk to each other, without custom integration work.
Vendor-agnostic orchestration platforms exist to solve this directly: a single control plane that manages physical hardware, virtual functions, SDN overlays, and cloud-native workloads through standardized interfaces.
Enterprise SONiC helps this effort as well. A Linux-based, community-driven NoS, now deployed by organizations like Alibaba or Verizon, growing at 20% year-over-year, across 520+ contributing organizations.
But adopting open networking without the right orchestration layer trades one problem for another. You escape proprietary lock-in, only to drown in manual, error-prone CLI configuration.
This guide aimes to give infrastructure and network operations a framework for comparing platforms, before committing.
[First of all] Scope of Fabric Control
The first question is straightforward:
Does the platform actually manage the devices you already own, and does it do so across their full operational lifecycle rather than just initial provisioning?
Day 0 configuration is obvious. Evaluate what the platform does on Day 2 and beyond: VXLAN segment management, switchport VLAN mappings, MC-LAG device pair configuration, VRF and DHCP relay management, and global fabric settings like RADIUS, SNMP, and NTP pushed uniformly across the entire fabric. A platform that covers only initial setup forces your team back to CLI for routine operations.
SandWork addresses this as a core design principle. Its Day 2+ fabric configuration covers VXLAN network segments, switchport mappings, MC-LAG pairs, PortChannel and LoopBack settings, port breakout and MTU, all orchestrated from a single interface across multi-vendor white-box hardware from Edgecore, Dell, Celestica, Micas, and Broadcom.
The full checklist is:
- Full Day 2+ configuration scope (segmentation, port settings, global fabric parameters)
- Multi-vendor hardware validation (not just theoretical support)
- MC-LAG and device-pair management
- VXLAN/EVPN overlay orchestration
[Step 2] Intent vs. State
Configuration drift is one of the most persistent sources of outages in enterprise data centers.
Devices get manually adjusted during incident response, OS upgrades introduce state changes. Within weeks, the actual network state diverges from what your orchestration layer believes is deployed.
Evaluate whether the platform models intent separately from state and continuously reconciles the two. A platform that only pushes configurations without tracking whether they persist, provides false confidence.
You want automated detection of deviations, clear notification of discrepancies, and guided remediation, whether that is a configuration push, override, or documented exception, not a manual audit process.
SandWork's intent remediation compares intended configuration against real-time operational state via gNMI telemetry. When it detects drift, it surfaces the discrepancy and prompts corrective action.
Integrity verification runs across the entire fabric, not device-by-device. Snapshots, on-demand or scheduled, capture operational state for comparison and rollback reference.
Verify if the orchestrator does this:
- Separate modeling of intended vs. actual state
- Automated drift detection with notification
- Guided remediation workflow (push/override/ignore)
- On-demand and scheduled configuration snapshots
- gNMI or equivalent real-time telemetry collection
[Step 3] Brownfield Integration & Legacy Infrastructure
A platform that only works cleanly on freshly staged devices is a greenfield tool sold into a brownfield world.
Most enterprise environments have existing data center deployments that cannot be reprovisioned from scratch.
Evaluate specifically how the platform imports and manages current infrastructure.
Can it discover an existing deployment's topology and pull it into the orchestration model without manual re-entry?
Can it validate that the imported design matches what is actually deployed?
For teams running mixed environments, the adapter layer for legacy devices matters as much as the core orchestrator.
SandWork's brownfield capability imports a data center's existing design topology and configuration directly into its management layer. The verification engine then validates that the deployed architecture matches the imported intent before the platform takes any remediation action.
Topology export allows teams to derive templated topologies from existing deployments, which can then serve as blueprints for new sites or expansions, removing the need to design from scratch each time.
Do not forget to check if these are present:
- Automated import of existing topology and configuration
- Post-import verification against actual deployment
- Topology export and templating for replication
- Greenfield and brownfield support from the same platform
[Step 4] Device Lifecycle Management
Network operations teams spend an ungodly amount of time on device onboarding, OS upgrades, and hardware replacement - tasks, that are largely manual in environments without proper orchestration.
At scale, this becomes the primary operational bottleneck.
Evaluate, whether the platform covers the full device lifecycle: onboarding via Zero Touch Provisioning, staged OS upgrades with rollback capability, device swap without manual reconfiguration, and formal decommissioning workflows.
Staged upgrades are particularly important. A platform that can only upgrade all devices simultaneously, is an operational liability in production environments.
SandWork's lifecycle management covers the complete arc. The staging process handles onboarding and decommissioning with validation at each step.
OS upgrades are staged across defined device groups, support multiple SONiC versions, and include warm boot capability to maintain configuration persistence across the upgrade boundary.
Device swap facilitates seamless hardware replacement without manual reconfiguration of the replacement unit. This is the operational layer that determines whether SONiC adoption remains cost-effective at scale.
The hardware savings of white-box networking disappear quickly when specialized CLI engineers are needed, to manage every device individually.
Checklist:
- Zero Touch Provisioning (ZTP) for new devices
- Staged, tailorable OS upgrade process with rollback
- Warm boot support for configuration persistence
- Formal device staging and decommissioning workflows
- Device swap/replacement without manual reconfiguration
[Step 5] Observability & Assurance
Automation amplifies both correct decisions and incorrect ones.
A platform that can push a misconfiguration across 500 devices in a single transaction is a risk multiplier - without proper guardrails.
Evaluate the full assurance layer:
- pre-commit validation
- network-wide transaction management with rollback
- post-change state verification
- continuous health monitoring
- cable and LLDP verification
- validating physical topology against intent,
All of these can catch cabling errors that old-school configuration management misses. Audit logs matter for compliance and for post-incident analysis.
SandWork's network-wide transactions orchestrate configuration distribution across all required devices with validation and the option to commit or roll back as a single operation.
The cable and LLDP check discovers and validates physical topology against intent. Health checks verify connectivity for both new deployments and existing ones, with error notifications for diagnosis.
Topology change alerting surfaces connectivity loss, device failures, and failover conditions in real time. All operations generate an activity audit log.
Checklist:
- Network-wide transaction management with commit/rollback
- Pre-commit validation
- Cable and LLDP topology verification
- Real-time topology change alerting
- Health checks for new and existing deployments
- Activity and transaction audit log
[Step 6] Security
Orchestration platforms sit at the control plane of your entire fabric.
The security model is not a secondary consideration.
Evaluate, whether the platform implements Zero Trust throughout, not just at the perimeter. Role-based access control (RBAC) should be granular enough to model organizational roles, not just admin vs. read-only.
Device authentication should require client certificates before a device is promoted to operational status. API verification should be bidirectional. Integration with enterprise AAA infrastructure (RADIUS) should be native, not bolted on.
SandWork implements Zero Trust as a foundational principle. Every individual and virtual role interacting with the system requires authentication, and API verification is like-for-like.
RBAC enables granular permission assignment with RADIUS/AAA integration. Client authentication certificates gate device promotion to operational status.
Integrity verification continuously confirms that all devices operate under verified, policy-compliant configurations.
Checklist:
- Zero Trust framework across all access boundaries
- Granular RBAC with organizational role modeling
- RADIUS/AAA integration
- Client certificate-based device authentication
- Continuous integrity verification across the fabric
[Step 7] Integration Surface and Scalability
A platform that creates lock-in through proprietary APIs or closed data models simply moves the problem. Evaluate northbound API coverage, OpenAPI compliance, and existing integrations with IPAM, OSS/BSS, and CI/CD toolchains. Verify that the platform is architecturally capable of managing your target scale before a contract is signed.
SandWork exposes programmatic access through an OpenAPI framework for integration with third-party tools and systems, including VMware NSX for hybrid environments.
The platform is production-proven at scale: it currently manages over 6,000 mission-critical devices across multiple data centers.
Capacity planning continuously updates physical and virtual inventories across the fabric, providing current visibility into resource availability, as the environment grows.
Checklist:
- OpenAPI / REST northbound interface
- gNMI subscription-based telemetry
- OSS/BSS integration capability
- VMware NSX support (for hybrid environments)
- Documented production scale reference (device count, topology complexity)
- Capacity planning and inventory management
[Putting It Together] A Scoring Framework
Run each candidate platform through these six criteria. Score each checklist item as fully met (2), partially met (1), or not met (0). Weight criteria by your specific environment: if brownfield integration is the primary constraint, it carries more weight than greenfield lifecycle management. The numerical score matters less than making the tradeoffs visible before a contract is signed.
Bring both your network architects and your operations engineers into the evaluation. Architects focus on topology models and protocol coverage. Operations engineers care about Day 2 workflows, rollback behavior, and how the platform behaves during a P1 incident at 2 a.m. Both perspectives surface deficiencies the other misses.
Furthermore
PANTHEON.tech built SandWork specifically to address the operational gap in SONiC enterprise data center deployments, providing the orchestration and management layer that makes open networking viable at production scale. If you are evaluating enterprise network automation tools and want to discuss architecture specifics or run a proof of concept, contact our team.
