Quick network snapshot to get started

• Tell me about the last time your team planned a backbone capacity upgrade, what triggered it and when did planning begin?
• How many backbone PoPs and interconnect sites does your production network contain today? Options: 1–5, 6–15, 16–50, 51–150, More than 150
• Which traffic drivers are pushing capacity (select all that apply)? Options: Peering growth, Hyperscaler DCI, Mobile/5G transport, OTT streaming, Enterprise cloud onramps, Other
• On a typical day, what percent of core link capacity do you see on the busiest 95th percentile? Options: <60%, 60–75%, 76–80%, 81–90%, 91–95%, >95%
• Who on your leadership team is the single decision owner for core routing platform selection and migration? Options: VP Network Architecture, Director IP Engineering, CTO, Head of Operations, Cross-functional committee, Other

Where current design causes real pain

• If your busiest links sustained 95 percent utilization for a sustained week, what immediate customer or operational impact would force you to accelerate a hardware refresh?
• Describe the topology constraints that limit capacity growth today, for example power, cooling, fiber availability, or rack density issues.
• Which services or customer classes would be most exposed during an over-utilization event? Options: Transit customers, Peering sessions, Enterprise VPNs, Mobile backhaul, Cloud onramps, Other
• How often have you had to defer new peering or cross-connect requests because of backbone capacity limits in the past 12 months? Options: Never, Once, 2–5 times, 6–12 times, More than 12
• Which single constraint, if resolved quickly, would give you the most breathing room operationally? Options: More forwarding capacity, Faster convergence, Better automation, More rack space or power, Improved telemetry

Failure modes that keep you up at night

• Which single failure scenario in the last 12 months exposed the biggest weakness in your routing platform and why?
• When that failure happened, how long did it take for routing tables to converge to acceptable levels and how did traffic engineering respond? Options: Seconds, Tens of seconds, Minutes, More than 15 minutes, Unknown
• What routing table size and route churn levels do you need the new platform to sustain without service degradation? Options: <250k prefixes, 250k–500k, 500k–1M, 1M–2M, >2M
• How do you currently validate line-rate forwarding and where have you seen shortfalls in lab versus production?
• If a software bug emerged only under production load and caused intermittent forwarding loss, what is the threshold of customer impact that would make you pause a migration? Options: Any customer packet loss, Sustained loss for key customers, Service-affecting outages >5 minutes, Multiple sessions flapping, Depends on affected segment

What interoperability truly needs to deliver

• What would have to be true about a new router's interoperability for you to accept it running alongside your incumbent vendor in production?
• Which control-plane and data-plane features must be supported out of the box (select all that apply)? Options: BGP large scale, EVPN-VXLAN, Segment routing, MPLS TE, BFD at scale, SRv6, Other
• Who owns the automation and integration work internally, and do they have bandwidth for a multi-vendor pilot? Options: Netops team, Platform engineering, SRE, Third-party integrator, Unassigned
• Which telemetry and API endpoints must the new system expose to replace your current telemetry pipelines? Options: gNMI/streaming telemetry, REST/RESTCONF/YANG, SNMP v2/v3, Custom streaming, Syslog/PDUs, Other
• Would the inability to run model-driven config and your existing automation simultaneously force you to postpone adoption? Options: Yes, Possibly, No

Alternatives on the table and what would keep you with them

• Which of the following options are you actively evaluating or have recently evaluated? Options: Remain with incumbent vendor, Internal whitebox/disaggregated build, Another full-stack vendor, Incremental upgrades to current hardware, Hybrid multi-vendor approach, Not actively evaluating yet
• What specific outcome or metric would need to be proven for you to stay with your current approach instead of switching?
• Has any internal team proposed solving the issue without an external vendor, and if so, which teams and what timeline did they suggest? Options: Yes, network engineering, Yes, platform engineering, Yes, research team, No internal proposal, Other
• If you decided to keep the incumbent, what contractual or operational change would make that decision stick for the next 3 years?

Operational readiness and gating constraints

• Which integration dependencies must be in place before a pilot can start, for example OSS systems, orchestration APIs, or inventory databases? Options: Provisioning API access, Inventory sync, Monitoring/telemetry integration, Configuration management, None are required
• Who owns the necessary API credentials and who can approve access within your organizations? Options: Netops lead, Platform engineering, Security team, Procurement, Third-party integrator
• Describe the minimum physical prerequisites at a pilot site, for example port density, power, cross-connects, and are those available now?
• How many full-time engineering staff can be committed to lab and pilot activities over a 3–6 month evaluation window? Options: None dedicated, 1–2 engineers, 3–5 engineers, 6–10 engineers, More than 10
• Are there regulatory, security, or vendor-contract approvals that typically add more than four weeks to project timelines? Options: Yes, regularly, Sometimes, Rarely, No

Acceptance criteria that will decide the deal

• If the pilot proves X, what exact result would let you sign a multi-year commitment that same week?
• Choose the measurable lab and pilot gates that matter most to you (select up to three) Options: Sustained line-rate forwarding per port, Routing table capacity, Sub-second convergence on spine failure, Control-plane stability under churn, Streaming telemetry throughput, Power efficiency
• What numeric targets do you require for those gates, for example forwarding throughput in Gbps per port or convergence in seconds?
• Who must provide formal signoff on pilot acceptance, list roles and whether names are confirmed? Options: VP Network Architecture, Director IP Engineering, SRE lead, Procurement, Legal
• If the pilot meets the targets but you still delay signing, what unresolved issue would be the most likely reason? Options: Commercial terms, Long-term support concerns, Operational readiness, Integration gaps, Other

Governance, timeline, and resource cadence

• Who must approve the final migration plan for it to proceed within your targeted window, and what approval lead times do they require?
• When do you want a pilot to start to keep the full migration on track for your desired go-live window? Options: Immediately, In 1–2 months, In 3–6 months, In 6–12 months, Undecided
• How many maintenance windows per month are acceptable for phased migration activities in high-traffic segments? Options: None, 1–2, 3–4, More than 4
• Describe the escalation path and on-call coverage you require during pilot and migration activities.

Risks you cannot absorb and rollback requirements

• Which single operational risk during migration would make you stop the program immediately?
• What rollback criteria and timeframe do you require for a segment migration to be reverted safely? Options: Immediate within maintenance window, Rollback within 2 hours, Rollback within 6 hours, Rollback within 24 hours, No rollback allowed
• What testing or staged validations must pass before you allow traffic shift to new hardware in production? Options: Line-rate tests, BGP scale and convergence, Interoperability smoke tests, Telemetry validation, All of the above
• Who is authorized to call a migration pause and who must be notified immediately when that happens?

Pilot footprint and minimal success plan

• If you committed to a pilot next quarter, what is the smallest production footprint you would accept to validate the critical gates? Options: Single site, non-critical, Two sites with diversity, Single high-traffic link, A full PoP with limited customers, Edge aggregation only
• Which specific interfaces, peering sessions, or customer circuits must be included in the pilot to make results meaningful?
• How long should the pilot run under production traffic to be confident in stability? Options: 1–2 weeks, 3–4 weeks, 6–8 weeks, 3 months, Longer than 3 months
• What monitoring and reporting cadence do you require during the pilot for you to sign off (select all that apply)? Options: Daily summary, Real-time dashboards, Weekly executive review, Postmortem reports, Ad-hoc deep dives
• If the pilot meets agreed KPIs but uncovers a minor interoperability bug, what level of remediation commitment would keep you moving forward? Options: Code patch within 2 weeks, Config workaround acceptable, Delay for next release, Require full fix before go-live

Final alignment and next steps

• Assuming acceptance gates are defined and resources are available, what is the earliest your organization could approve a signed pilot statement of work? Options: Immediately, Within 2 weeks, Within 1 month, 2–3 months, Need internal planning
• Who should be included in an initial scoping workshop from your side, list roles and preferred attendees?
• Which artifacts would you expect from the seller before a pilot starts, for example lab test plans, configuration templates, and acceptance checklists? Options: Lab test plan, Pilot runbook, Config templates, Telemetry mapping, Rollback plan, All of the above
• What single outcome from an initial 6–8 week lab run would increase your confidence in committing to a pilot?
• Would you like us to propose a tailored acceptance gate matrix and pilot footprint for review in the scoping workshop? Options: Yes, please propose, We will propose, We prefer joint proposal, Not at this time

• Architecture Walkthrough

• Confirm the current state and its cost
• You confirm the target architecture maps to your forwarding and convergence requirements and removes the outage risk you described.
• Provide full BGP routing table snapshots, peak traffic profiles, and a list of current adjacent vendor equipment models for the proposed pilot segment.
• You agree on specific, measurable lab acceptance criteria and a pilot footprint to validate the architecture.
• Present the target architecture and design rationale
• Deliver a detailed target architecture diagram and a lab test plan with acceptance criteria and test scripts within five business days after this session.
• Forwarding throughput scenarios and lab test plan
• Run a baseline forwarding and convergence test in the seller lab against one representative routing table and share the test results and logs before the pilot kickoff.
• You confirm the telemetry and API integration approach meets your automation needs for post-migration operations.
• Confirm the proposed pilot segment and identify the internal stakeholders who will sign the pilot acceptance gate.
• Convergence and failure-mode walkthrough
• You commit to providing the routing and traffic artifacts needed to execute the lab plan within the agreed timeframe.
• Programmability and telemetry integration proof
• Interoperability scenarios with your existing equipment
• Validate match to your needs
• Agree acceptance criteria and next evidence steps

• Architecture Walkthrough
• Architecture Walkthrough Deck
• Architecture Solution Brief

• meeting
• slides
• document

• Deliver and install routing chassis and linecards
• Load and activate network OS image
• Activate software licenses and maintenance entitlements
• Provision forwarding plane and hardware QoS
• Configure BGP, IGP and MPLS routing policies
• Migrate routing adjacencies and session cutovers
• Implement segment routing and traffic engineering
• Enable streaming telemetry and model-driven APIs
• Integrate with peering, IX and DCI links
• Perform factory acceptance and interoperability testing
• Commission non-critical production pilot cutover
• Deploy rack power, cooling and cable infrastructure
• Provide spare parts kit and logistics support
• Train operations team and deliver runbooks

Deliver and install routing chassis and linecards

• Do you have site single-line diagrams (SLD) and rack elevation drawings for every target location? Options: Yes, No
• How many chassis and which linecard port speeds (for example 100GE, 400GE) are required per rack? Options: 1 chassis, 2 chassis, Multiple chassis across racks
• Specify required power feed type and capacity per rack (for example single A/B feed, 60A, 200A).
• Provide preferred delivery receiving windows and any site access constraints (for example fenced POP, data center white space, appointment-only docks). Options: Business hours, After hours, Appointment-only
• List physical constraints that affect installation such as elevator dimensions, door clearances, or floor loading (kN/m2).
• Identify the onsite contact who will sign equipment acceptance and verify inventory at handover (name, role, contact).

Load and activate network OS image

• Confirm the required network OS image version and build number you want preloaded on each chassis.
• Indicate whether image validation must include checksum verification and secure boot validation during staging. Options: Checksum only, Checksum and secure boot, No validation required
• Specify any platform-specific install scripts or golden config snippets that must be applied during first boot (for example base ACLs, mgmt VLAN, NTP settings).
• Which out-of-band management method will you use for image activation and console access (for example serial console, out-of-band Ethernet, IPMI)? Options: Serial console, Out-of-band Ethernet, IPMI, Other
• Provide the acceptance threshold for a successful image activation (for example boot to operational state within X minutes, CLI/API reachable).
• Will you require a backup image and automated rollback on boot failure, and if so what rollback window do you mandate? Options: No rollback required, Auto-rollback within 10 minutes, Auto-rollback within 30 minutes, Manual rollback only

Activate software licenses and maintenance entitlements

• Which software feature licenses must be activated per chassis (for example full forwarding, MPLS, segment routing, telemetry collector)?
• Provide the account or contract IDs required to bind maintenance entitlements and software licenses for each serial number.
• Estimate whether license activation will be done online during staging or needs offline air-gapped procedures. Options: Online activation, Offline process required
• Indicate required RMA and support SLA level for maintenance entitlements (for example 4-hour onsite, 24x7 remote), per site. Options: Standard business hours, 24x7 remote, 4-hour onsite
• Describe any internal procurement or approval steps that block license binding (for example PO hold, legal review, audit requirement).
• Who is the authorized license administrator that will approve license assignment and receive entitlement confirmations?

Provision forwarding plane and hardware QoS

• Which forwarding profiles do you require per interface type (for example L2 switching, routed 100GE, L3VPN)?
• Specify QoS hardware profiles and queue counts needed to support voice, video, and best-effort classes (for example 8 queues, strict-priority for EF).
• Indicate target line-rate forwarding test conditions to include in acceptance (for example 64-byte frames at full port count, mixed 40/60/80/100% load).
• Provide expected maximum forwarding table size and route types you will load during tests (for example 1,000,000 IPv4 prefixes, 200,000 IPv6 prefixes).
• Identify any hardware offload features that must be enabled (for example ACL offload, SRv6 HW encap, TCAM partitioning).
• Which telemetry counters and hardware PMIs (performance measurement indicators) do you require exposed for capacity monitoring (for example per-queue drop, per-port throughput)?

Configure BGP, IGP and MPLS routing policies

• Which IGP and BGP protocol versions and extensions will be in use (for example OSPFv2, OSPFv3, IS-IS, BGP+Add-Paths)? Options: OSPFv2, OSPFv3, IS-IS, BGP Add-Paths
• Specify required BGP policy actions and route filters per peer group (for example AS-path prepend, community tagging, ORF filters).
• Indicate MPLS features to enable (for example LDP, RSVP-TE, RSVP for RSVP-TE, MPLS L3VPN) and any interoperability constraints with existing peers. Options: LDP, RSVP-TE, L3VPN, Other
• Identify expected maximum number of BGP adjacencies and route refresh rates for convergence testing (for example 5k peers, X updates/sec).
• Who within your operations team will own routing policy sign-off and policy change control during migration?
• Detail any required route distributions or automation artifacts (for example route-policy YANG models, policy-export templates) that must be delivered with the config.

Migrate routing adjacencies and session cutovers

• Which backbone segments and peer ASNs are in scope for the initial adjacency migrations (list PoPs and ASN pairs)?
• Provide the allowed maintenance windows and blackout periods for adjacency cutovers per PoP.
• Identify required cutover method for each adjacency (for example graceful BGP session handover, cold swap, ECMP phased shift). Options: Graceful handover, Cold swap, Phased ECMP shift
• Estimate the expected fail-over and convergence thresholds you will accept during cutover tests (for example sub-second for X prefixes, no traffic loss >Y seconds).
• Who will coordinate cross-team escalations during adjacency migration (operations, NOC, peering ops) and provide 24x7 contact details?
• Are there specific prefixes or customer circuits that must be excluded from adjacency migration until final cutover? Options: Yes, list them, No

Implement segment routing and traffic engineering

• Which segment routing flavor will you adopt and require in scope (for example MPLS-SR, SRv6)? Options: MPLS-SR, SRv6, Not using SR
• Specify TE objective functions and constraints to enforce (for example bandwidth reservation, latency, affinity constraints).
• Indicate the headroom and bandwidth reservations per TE tunnel for critical services (for example 20% reserved on core links).
• Identify the controller or path computation element (PCE) integration points you will require (for example PCE IP, gRPC interface, REST API).
• Which SR-TE policy templates and telemetry KPIs must be delivered for verification (for example per-policy throughput, path adherence)?
• Do you have existing SR or TE policies that must be migrated from your current platform and mapped to new identifiers? Options: Yes, No

Enable streaming telemetry and model-driven APIs

• Which streaming telemetry transports and encodings must be supported (for example gNMI/gRPC with protobuf, gNMI over TLS, NETCONF/YANG)? Options: gNMI/gRPC, NETCONF/YANG, RESTCONF, Other
• Provide collector endpoints, IPs, ports, and credentials or certificate authorities that will ingest telemetry streams.
• Specify the sampling or subscription cadence and data sets required (for example interface counters per 30s, BGP RIB every 5m).
• Identify required model-driven config interfaces to integrate with your automation (for example YANG models for BGP, interfaces, QoS).
• Which operational workflows will consume telemetry for alerts and do you require demo playbooks showing alert-to-runbook mapping? Options: Yes, need playbooks, No
• How will you validate API stability during evaluation (for example run synthetic API load for X requests/sec, test schema compatibility)?

Integrate with peering, IX and DCI links

• List peering and IX locations in scope and the corresponding port speeds and VLAN tags for each peering port.
• Which DCI circuits and metro links must be provisioned and tested end-to-end (list circuit IDs and carriers)?
• Indicate required BGP multihop and TTL settings, MD5 requirements, or maximum-prefix limits for each peer or IX session.
• Identify whether peering ports require specific MAC learning, L2 VPLS, or QinQ configurations for interoperability.
• Who will coordinate with IX operators and carrier NOCs for circuit turn-up and testing, and what are their contact windows?
• Do any IX or peering links require jitter/latency SLAs to be validated during the pilot, and if so what thresholds apply? Options: Yes, specify thresholds, No

Perform factory acceptance and interoperability testing

• Specify the factory acceptance tests and measurable pass criteria you require for hardware and software interoperability (for example 100GE line-rate at 64-byte, RIB scale >= 1,000,000 prefixes, control-plane convergence <500 ms).
• Indicate which interoperability partners and legacy platforms must be covered in multi-vendor test matrices (for example existing core router platform types, IX switches).
• Describe lab test scenarios you require such as sustained full-port line-rate, route churn at X updates/sec, and optical impairment tolerance.
• Provide acceptable defect classification and remediation SLAs discovered during FAT (for example severity 1 fix required before ship, severity 2 acceptable with workaround).
• Who will be the named technical approver for FAT results and what evidence artifacts do they require (for example PCAP traces, system logs, telemetry exports)?
• Will you require witnessed interoperability tests onsite or are recorded test runs and results acceptable? Options: Witnessed onsite, Recorded results acceptable, Remote live witness

• desired_state
• current_state
• stakeholders
• gaps
• success_criteria
• decision_readiness
• desired_state
• decision_readiness
• current_state
• success_criteria
• gaps
• stakeholders
• desired_state
• success_criteria
• stakeholders
• gaps
• current_state
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Purchase Agreement
• Order Confirmation & Delivery Schedule
• Software Licensing Agreement
• Maintenance & Support Agreement (M&S)
• Service Level Agreement (SLA) Annex
• Acceptance Certificate & Gate Confirmation
• Volume Pricing & Multi‑Year Migration Commitment Annex
• Change Order Agreement
• Data Processing Agreement (DPA) — conditional
• Termination & Exit Assistance Agreement

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Operational Handover and Remediation Closeout (around day 90)
• Knowledge Transfer and Runbook Lockdown
• Ongoing Quarterly Operational Review
• Monthly Issue Triage and Enhancement Coordination

• Confirm packet loss percentage and MTTR remain within agreed operational tolerances.
• Operational handover package and ongoing review cadence are agreed and published.
• Confirm archive and retention of legacy system data and publish the decommissioning record.
• Close or schedule resolution for any remaining P1/P2 items with committed due dates.
• Publish the final handover package including runbooks, configuration snapshots, telemetry mappings, and the shared support channel.
• Review and finalize runbooks and escalation paths
• Runbooks, escalation procedures, and simulation scripts are finalized and published.
• Production configuration values and inventory snapshot are locked and stored in the shared repository.
• Training and shadowing plan is scheduled and initial sessions are completed.
• Deliver the final runbook package, simulation scripts, and configuration snapshots to the shared channel.
• Schedule three live shadowing sessions for the operations team within the next 30 days.
• Validate API credentials and telemetry endpoint connectivity from the buyer's monitoring stack.
• Metrics dashboard review
• Confirm deployment completion and open tasks
• All critical incidents have documented RCAs and closure or mitigation plans.
• Enhancement backlog is prioritized with owners and target delivery windows.
• Deliver RCA documents for each P1/P2 event within seven calendar days.
• Prioritize the top three enhancement requests and publish implementation timelines.
• Update telemetry thresholds and alerting rules based on observed production patterns.
• Triage active incidents and blockers
• All active P1/P2 incidents have assigned remediation steps and target close dates.
• Routing table utilization is monitored and capacity plans are updated for the next 90 days.
• Telemetry delivery issues are resolved or scheduled with clear owners and dates.
• Assign remediation tasks for active incidents with committed due dates.
• Publish a capacity forecast for routing table utilization covering the next quarter.
• Schedule a 14-day follow-up to validate telemetry fixes in the production collectors.
• All critical deployment tasks are completed or have assigned remediation with target dates.
• Telemetry and monitoring streams are validated and delivering baseline data into the agreed collectors.
• Open blockers are logged with owners and target resolution dates.
• Publish the deployment completion checklist and the open-blocker register to the shared channel.
• Enable streaming telemetry to the agreed collector and confirm the retention window and schemas.
• Provide the data sources and export schedule required for the first measurement review.
• Present measured line-rate forwarding and routing convergence time vs targets
• Determine whether line-rate forwarding and routing convergence metrics are on track relative to targets recorded in Lab & Pilot Evaluation.
• Identify root cause for each metric gap and agree remediation tasks with target dates.
• Confirm a clear timeline to remediate outstanding items and reach stable operations.
• Deliver packet-level captures and control-plane logs supporting measured shortfalls within three business days.
• Execute agreed remediation tasks and provide weekly status updates until closure.
• Update operational runbooks with observed fixes and temporary workarounds.
• Restate remediation list and closure criteria
• All high-priority remediation items are closed or have an approved extension with dates.
• Incumbent platform is either decommissioned or formally retained-read-only with archive and contract actions completed.
• Reconfirm owners and acceptance criteria recorded in Lab & Pilot Evaluation
• Root-cause analysis for metric gaps
• Routing table capacity and growth forecast
• Incident and RCA review
• Lock configuration values and inventory snapshot
• Present final outcome data against Lab & Pilot Evaluation targets
• Incumbent decommissioning status
• Training sessions and shadowing schedule
• Deployment validation
• Review telemetry delivery success rate and routing table capacity utilization
• Telemetry delivery health
• Enhancement request backlog and prioritization
• Handover of access, API credentials, and telemetry endpoints
• Enhancement request status and next actions
• Agree corrective actions and remediation timeline
• Early operational signals
• Open operational issues and remediation progress
• Remaining operational risks and contingency plans