Technology
›
Telecom, Media & Entertainment
›
Telecom Equipment Sales
Core Network Equipment
Complex platform, content, and network decisions where revenue, rights, and customer experience intersect.
Cisco
Ericsson
Nokia
Juniper
Inside this journey
-
Pre-Discovery
Align the room on outcomes, decision process, and constraints before deeper discovery.
-
Stakeholder Alignment
Confirm decision roles, timeline constraints, and what success looks like for each operational and executive stakeholder.
Alignment Questions
Quick introductions — who’s on this journey with us?
- Who are the people (name, role, and primary responsibility) we should know from your team for decisions, technical validation, and operations?
- Which of the following groups will need formal sign-off for vendor selection and multi-year procurement?
- Which single person on your side do we route urgent commercial questions and executive escalations to?
- Who will own pilot approval and who will be the operational owner if we move to production?
Who really calls the shots (and why that matters)
- If you had to pick one person who ultimately decides the vendor — who is that, and what outcomes move them to ‘yes’?
- When vendors present comparable technical results, what non-technical factors most influence the final decision?
- How frequently do you see decisions stall because of organizational politics or competing priorities? Can you share an example?
- What would make the decision-maker feel we’d be a lower-risk, higher-value choice than the incumbent?
Calendar pressure — is time working for you or against you?
- We often find timeline optimism is the root cause of late projects — where is your target deployment window and how fixed is it?
- What external deadlines or events (e.g., peering contracts, capacity exhaustion, regulatory milestones) are driving that timeline?
- If a critical lab or interoperability test slips by more than two weeks, what happens to the overall timeline or budget?
- How long do stakeholders typically tolerate a pilot before requiring a go/no-go decision?
What would make your executives sleep well at night?
- If your VP of Network Architecture had one slide to justify this project to the board, what three metrics must look great?
- Which of the following executive-focused outcomes matter most for this program?
- How would you quantify acceptable risk for execs around convergence and service disruption (e.g., MTTR targets, allowable dropped sessions)?
- How important is executive visibility during pilot and migration (regular dashboards, topline health checks, crisis calls)?
What success actually looks like for the people who run the network
- For the NOC and field engineering teams, what operational outcomes would make this migration worth the effort?
- Tell us about a recent incident where your current routing platform caused real pain — what happened, who scrambled, and what was the aftermath?
- What level of change to existing runbooks and automation are you willing to accept during a phased migration?
- Which operational metrics do you monitor continually and would want preserved or improved post-migration?
Where the hidden constraints live — dependencies you might not be naming
- What non-technical constraints (budget cycles, vendor exclusivity, internal policy, legacy contracts) could quietly block progress?
- Do you have contractual obligations to an incumbent (support, maintenance, exclusivity) that create migration windows or penalties?
- Are there regulatory, data sovereignty, or security approvals that typically add lead time to deployments in your environment?
- Which internal teams (security, compliance, finance, facilities) must be looped in before you can run lab tests or pilots?
How confident are you — and what would move that confidence needle?
- On a scale from 1–10, how confident are you that a new vendor can meet your forwarding, convergence, and programmability needs?
- What specific lab or pilot results would raise that confidence by at least 3 points? Be granular (e.g., line-rate for X flows, BGP reconvergence < Y ms).
- What would be a deal-breaker result during lab or limited production that would end further evaluation?
- If a pilot exposes intermittent software instability, how would you prefer we handle communication and remediation with your team?
Escalation pathways — when to ring the alarm bell
- Who on your side must be notified immediately for a pilot-affecting failure, and what are their preferred contact methods?
- Which types of incidents automatically trigger executive-level involvement for you?
- How quickly do you expect vendor field engineering to be onsite or available for critical issues?
- Would you prefer a single point of contact for escalations or a role-based escalation matrix?
What success looks like in the first 90 days (and who champions it)
- If we complete a pilot and hand over to operations, what are the top three outcomes you’d want validated within 90 days?
- Who will be the internal champion tracking those 90-day outcomes and ensuring acceptance criteria are met?
- What acceptance criteria (quantitative and qualitative) must be satisfied for you to proceed from pilot to phased migration?
- Would you want contractual gates tied to lab/pilot results before committing to multi-year orders?
Closing the loop — aligning on next steps and ownership
- Based on this conversation, what are the top three actions you expect from us in the next two weeks?
- What do you commit to doing on your side to keep momentum (e.g., provide inventory, approve lab access, name pilot owner)?
- How would you like progress updates delivered (cadence and format)?
- Is there anything we haven’t asked that would make a big difference in aligning expectations and avoiding surprises?
-
Network Current State Mapping
Document topology, router inventory, utilization thresholds, failure modes, and migration constraints.
Current State
A Quick Map of Where You Sit
- In one short sentence, what is the single operational priority driving this evaluation right now?
- How would you describe your backbone topology today?
- Roughly how many core/edge routers are in scope for this initiative (best estimate)?
- Which vendors and network OSes are currently running in your core and edge (pick all that apply)?
- How do you currently track router inventory and topology changes?
- When was the last full inventory/topology audit completed and what gaps remain?
Are You Quietly Perched on a Bottleneck?
- If traffic rose 20% tomorrow, which single link, PoP, or device would you expect to experience service impact first?
- What percentage of your critical backbone links are routinely above your operational threshold?
- Which symptoms tell you you're capacity-constrained (select all that match)?
- Where do you feel your capacity planning process is weakest—forecasting, procurement lead time, testing, or something else?
- How often do capacity alarms produce false positives or noise your team ignores?
- Tell us about a recent moment when capacity limits impacted a customer or service—what happened and how did it feel to your team?
When The Backbone Stutters — What Breaks First?
- Which failure mode keeps you up at night because it can cascade into a multi-hour outage?
- Which of these failure types have you experienced in the last 24 months (select all that apply)?
- On average, how long does it take you to detect a significant backbone failure, and how long to restore service (separate numbers)?
- What automated or manual mitigations do you rely on today to contain these failures?
- How confident are you in your current runbooks for the top two failure modes (and why)?
- Share a brief example of a past incident where the root cause was surprising—what did you learn?
The Hidden Costs of Keeping Two Worlds Running
- How much extra operational effort (headcount or percentage of time) does supporting a non-standard or secondary routing platform add?
- Which tasks effectively double because you support multiple vendors or OS versions (select all that apply)?
- Where does interoperability cause the most friction—control-plane, data-plane, telemetry, or human processes?
- How mature is your automation stack for device lifecycle (provisioning, configuration drift, telemetry ingestion)?
- How long does it typically take to onboard a new device type into production automation and monitoring?
- What emotional cost does this dual-operation model have on your team (burnout, loss of domain expertise, recruitment pain)?
What Would Make This Migration Obviously Worth It?
- Looking ahead 12 months after a successful migration, what single measurable outcome would make you say we made the right decision?
- Which outcome signals are non-negotiable for you (pick up to three)?
- What target numbers matter most—target line-rate throughput per slot, routing table entries, or convergence SLAs? Please state targets.
- How much packet loss or latency increase during a failure window would be considered unacceptable?
- How important is having exactly the same CLI/operational model versus modern APIs and intent-driven tooling?
- Who in your organization will publicly own the statement 'migration met success criteria'?
Constraints You Can't Ignore (and Which Ones You Can)
- What is the single immovable constraint—technical, contractual, or business—that would kill this project if not addressed?
- Which of these constraints apply to your program (select all that are relevant)?
- Are there procurement or budget-cycle dates we must hit for this initiative to proceed this fiscal year?
- Which migration constraints are negotiable versus fixed (describe what you can flex and what you cannot)?
- Do you require specific certifications, interoperability reports, or third-party lab validation before pilot approval?
- Which PoPs or segments are off-limits for initial pilots due to risk, regulation, or customer commitments?
From Lab to Live — How Risky Does It Feel?
- Which single lab test failure would cause you to stop progression to a limited production pilot?
- Which of these lab acceptance criteria do you require for a vendor to pass (select all that apply)?
- How long do you typically run lab validation before allowing a limited production pilot?
- Who must sign off to greenlight a pilot and what are their top concerns?
- Describe how you prefer to validate telemetry and programmability during lab tests (push telemetry, gNMI, streaming, custom scripts, other).
- On a scale from 1–10, how ready does your ops team feel to operate a new routing OS in production after a successful pilot (and why)?
Deciding Today: What's the Easiest First Step?
- What is the smallest, least disruptive action we could take next week that would change your perspective on this project?
- Which of these next steps would you be most comfortable with right away?
- Who needs to be in the room (roles, not names) to approve that next step?
- What deliverables or evidence would make an immediate 'yes' more likely (lab report, whitepaper, pilot plan, TCO model)?
- How quickly can key decision-makers convene for a short technical review (calendar options)?
- Any final concerns or red lines we should know about before proposing a concrete pilot plan?
-
-
Outcome Discovery
Define measurable success signals for capacity, convergence, programmability, and migration risk tolerance.
Discovery Questions
Start: Where This Matters Most
- What event or KPI first made you decide to explore a core routing change now?
- Which services or customer segments would feel the impact first if capacity or convergence degraded?
- Who are the executive and operational decision owners we need to satisfy to make a migration a go/no‑go decision?
- What is your ideal timeline from pilot approval to first production migration (months)?
- How would you describe success for this initiative in one sentence?
What Happens If We Do Nothing?
- If no vendor change happens in the next 12 months, what measurable pain or cost will increase?
- How close are you to SLA breaches today during peak windows (e.g., percent of time or number of incidents in last 90 days)?
- When a high-utilization or convergence incident occurred recently, can you describe what failed and how long recovery took?
- What financial or reputational impact do you assign to a sustained outage or major convergence event (range or example)?
- How do your customers/operators talk about current risk — is it 'manageable', 'worrying', or 'urgent'?
Do Your Monitoring Tools Actually Tell the Truth?
- What telemetry and monitoring stacks are you using today to validate capacity and convergence (select all that apply)?
- Where are the blind spots in your current instrumentation—what do you wish you could measure but can't?
- How granular is your performance data (e.g., 1s, 30s, 5m intervals) and how long is it retained?
- Which KPIs do you treat as non-negotiable for this project (pick top three)?
- How confident are you in the accuracy and end-to-end correlation of those KPIs across lab and production environments?
How Fast Is Fast Enough?
- If a core link or node fails, what is the maximum convergence window you can tolerate before services are materially impacted?
- For BGP failover scenarios, what percentage of prefixes must re-establish without manual intervention to consider it a success?
- Do you differentiate convergence expectations by service class (e.g., transit vs management vs peering)? If so, how?
- How many routes and adjacencies must the platform handle without performance degradation (provide current and projected numbers)?
- What failure scenarios do you consider critical to test in lab (select all that apply)?
Can Programmability Replace Pain Points—or Just Add Complexity?
- If automation could remove one manual, error-prone task today, what would it be and why?
- Which northbound interfaces and tooling must we demonstrate in lab for you to accept the platform (select all that apply)?
- How do you measure automation success—time-to-deploy, change failure rate, mean-time-to-restore, or something else?
- What integrations must be proven (NMS, OSS/BSS, CMDB, orchestration) and what APIs or data models are required?
- How much operator retraining and runbook rework are you willing to accept during pilot without it being considered a failure?
What Would a Lab Win Actually Prove?
- Which specific lab tests are non-negotiable for you to progress to limited production (choose up to four)?
- For throughput validation, what pass criteria do you expect (e.g., percent of line-rate per interface under X packet sizes)?
- How long should long-running stability tests run to give you confidence (hours/days)?
- What documentation and artifacts do you require from lab runs (raw telemetry, test scripts, reproducible steps, metrics dashboards)?
- Who on your team needs hands-on lab access versus read-only reporting to sign off on results?
How Much Migration Risk Can You Live With?
- What level of service impact during pilot would you accept before pausing the migration (e.g., number of minutes, affected flows, or percentage of customers)?
- Do you require contractual penalties or service credits tied to pilot/acceptance metrics?
- What rollback conditions must be automated and how quickly must you be able to revert to the incumbent platform?
- How long can your operations support a dual‑vendor environment before the complexity becomes unsustainable?
- What is the maximum acceptable number of incidents or SEV-level events during pilot before a review is triggered?
Who’s Responsible When Things Get Messy?
- Which teams will own specific success signals (capacity, convergence, programmability, pilot ops)—list role and owner where possible?
- Which executive will sign off on pilot completion and commit to commercial expansion if success signals are met?
- What escalation path and SLA do you expect from a vendor if a pilot-related incident affects customer-facing services?
- Who must be included in daily/weekly pilot syncs, and which stakeholders only need milestone summaries?
- How will success be documented and archived for future migration phases (reports, runbooks, training materials)?
What Does Go/No‑Go Actually Look Like?
- Which measurable gates must be met before you allow a limited-production pilot to proceed (choose all that apply)?
- For each gate you select, what are the numeric thresholds and the acceptable margin of error?
- How long after a failed gate should the vendor have to remediate before the project is paused or re-evaluated?
- Do you require independent validation or third-party testing to accept gate results?
- Who signs the final go/no‑go and what specific artifacts do they require to sign?
If We Partnered, What’s the Easiest Next Step?
- What information or access would you be willing to provide first to enable a focused lab proof-of-concept (e.g., topology diagrams, traffic profiles, telemetry feeds)?
- What budget or commercial constraints should we be aware of when proposing a pilot and lab plan?
- How would you prefer us to demonstrate progress—weekly KPI dashboards, hands-on lab sessions, or milestone reports?
- What would make you feel confident enough to commit to a pilot in the next 30–90 days?
- Is there anything we haven't asked that would change how you define success for capacity, convergence, programmability, or migration risk?
-
Solution Experience
Confirm how the routers and OS will meet lab and limited-production acceptance criteria using the customer’s scenarios.
Experience Meetings
- Solution Experience Alignment Workshop
- Lab Test Plan & Scenario Mapping
- Witness Lab Validation — Live Test Run
- Limited-Production Pilot Planning & Acceptance Gates
- Final Validation & Acceptance Pre-Check (Lab + Pilot)
- Establish rollback procedures, automation, and monitoring to ensure pilot safety.
- Produce objective, timestamped KPIs for each acceptance signal and archive raw logs.
- Validate or invalidate the future-state hypothesis with real measured data tied to the customer's problem.
- Identify and prioritize any residual issues requiring RCA or configuration changes before pilot.
- Obtain customer witness confirmation on whether the observed results meet expectations or require escalation.
- Seller: Deliver a Test Results Package (raw data, KPI plots, annotated logs, and short executive summary) within 48 hours.
- Customer: Provide a validation statement indicating which acceptance signals passed/failed and any operational concerns.
- Seller: For failed items, provide an RCA plan and timeline for remediation and retest.
- Seller & Customer: Agree on which lab results are sufficient to progress to limited-production pilot and which require further lab iteration.
- Pilot Scope & Traffic Selection
- Agree a narrow, measurable pilot scope that exercises the lab-proven capabilities in production-like conditions.
- Define explicit pilot acceptance gates and the exact metrics/observation windows tied to lab results.
- Introductions & Objectives
- Assign owners, escalation contacts, and schedule the pilot run windows.
- Seller: Produce the Pilot Runbook including step-by-step cutover, watchlist KPIs, rollback scripts, and test checklists.
- Customer: Provision access, reserve maintenance windows, and assign on-call owners for pilot execution.
- Seller: Deploy monitoring dashboards and pre-configure alerts for the acceptance signals.
- Seller & Customer: Schedule the pilot start and the post-pilot acceptance review meeting.
- Executive Summary of Evidence
- Customer issues a clear technical acceptance decision tied to the previously defined acceptance signals.
- Document any remediation items with owner and timeline if full acceptance is not granted.
- Agree the artifacts required for the Mutual Commit meeting (validated test evidence, pilot report, risk register).
- Ensure both parties have aligned expectations on the path to commercial finalization and migration planning.
- Seller: Deliver the Final Validation Report consolidating lab and pilot evidence, annotated KPIs, and the risk register.
- Customer: Provide formal written technical acceptance (pass / conditional pass / fail) tied to the acceptance spreadsheet.
- Seller & Customer: If conditional pass, agree remediation milestones and schedule a follow-up verification run.
- Seller: Package all runbooks, automation scripts, and telemetry dashboards for handover to deployment teams.
- Have a single agreed one-sentence current-state that drives the experience.
- Quantify the consequence to operations and business if the problem persists.
- Agree one-sentence future state in operational terms (not features).
- Define explicit, measurable acceptance signals and thresholds for lab and pilot.
- Assign owners and data deliverables to prepare the lab tests.
- Customer: Deliver current topology (router models, interface speeds), utilization reports, inventory, and the canonical list of failure scenarios.
- Customer: Provide traffic profiles (5-tuple distributions), routing table sizes, and any synthetic trace files for traffic generators.
- Seller: Draft a one-page Acceptance Signal Spreadsheet mapping metrics to measurement methods and units.
- Seller: Confirm lab resources, test equipment, and preliminary schedule windows.
- Recap Agreed Acceptance Signals
- Have a complete, prioritized lab test plan that maps every customer scenario to a test case with measurement method.
- Agree on test harness, tooling, and who supplies/owns each component.
- Define the explicit pass/fail rule for each test and the test execution order.
- Establish the pre-work deliverables and timelines required to start tests.
- Seller: Publish the detailed Lab Test Runbook with step-by-step test procedures, traffic generator scripts, and measurement dashboards.
- Customer: Provide sample BGP/route table exports and finalized traffic profiles for deterministic load generation.
- Seller: Provision testbed racks, reserve ports, and load the initial configs for the first witness session.
- Customer: Identify the technical owners who will witness tests and have authority to validate acceptance signals.
- Setup & Test Readiness Check
- Acceptance Gates Linked to Lab Results
- Scenario-to-Test Mapping
- Deep-dive on Any Failed or Marginal Items
- Test 1 — Line-rate Forwarding & Resource Utilization
- Current State Statement (Customer-led)
- Residual Risk Register & Mitigations
- Test 2 — Routing Table Scale & Convergence under Failure
- Test Harness & Tooling
- Consequence Quantification
- Rollback & Safety Controls
- Runbooks, Automation & Monitoring
- Future State Definition
- Test 3 — Programmability & Telemetry Validation
- Acceptance Decision & Next Steps
-
Solution Scope
Define hardware models, software modules, lab test plan, interoperability checklists, pilot scope, and acceptance criteria.
Scope Configuration
- Ship and install chassis, line cards, and power supplies
- Rack, stack, and cable routers at customer sites
- Load and activate NOS image and feature licenses
- Configure core routing: BGP, IS-IS, and OSPF
- Implement segment routing and MPLS traffic engineering
- Provision QoS, buffer, and queuing profiles
- Apply hardware forwarding optimizations and ASIC tuning
- Deploy streaming telemetry pipelines to collectors
- Integrate gNMI/NETCONF/RESTCONF APIs with OSS/NMS
- Migrate BGP adjacencies via phased cutover execution
- Execute limited-production traffic cutover on backbone links
- Provide 24/7 NOC escalation and vendor software support
- Supply and manage on-site spare parts inventory
- Deliver operator training on NOS APIs and automation
Scope Questions
Ship and install chassis, line cards, and power supplies
- Do you require vendor-managed shipment and on-site installation of chassis, line cards, and power supplies?
- How many chassis and line-card populations are required per site? Please list by site.
- What is your delivery and installation target window?
- Do any sites have special access, customs, or security constraints that impact delivery or installation?
- Who will own site power and grounding validation—vendor or customer?
- Are there weight, seismic, or environmental restrictions in any racks/rooms that we must validate before shipment?
Rack, stack, and cable routers at customer sites
- Will vendor perform rack-and-stack and cabling, or will your team handle physically racking with vendor oversight?
- How many rack units (U) per chassis and how many chassis per rack at each site?
- What port types and cable types are required (e.g., single-mode fiber, multi-mode, DAC, QSFP-DD) and do you have fiber-distance constraints?
- Do you require structured cabling, patch panels, and labeling to vendor standard on delivery?
- Is there an existing cable-management policy or rack elevation diagram we must follow?
- Do we need to coordinate on-site access windows, maintenance windows, or change controls with your facilities/operations teams?
Load and activate NOS image and feature licenses
- Which NOS version and image (SKU) do you plan to validate and activate?
- Do you require vendor to stage and load NOS images in lab prior to site activation?
- What licensing model will you use (e.g., perpetual, subscription, feature-based), and do you need license key provisioning support?
- Do you require license entitlement validation and license server integration during activation?
- Do you need image signing, integrity checks, and rollback images staged as part of the activation plan?
- Are there acceptance tests (e.g., boot time, feature verification) you want executed immediately after NOS activation? If so, list them.
Configure core routing: BGP, IS-IS, and OSPF
- Which routing protocols are required on each device/site (select all that apply and specify where)?
- What is the expected routing scale for each protocol (number of prefixes, routes, adjuncts) per device?
- Do you require route-policy conversion or validation against existing policies (export/import filters, communities, route maps)?
- Are there authentication or route-validation requirements (e.g., MD5/TCP-AO, BGP TTL security, RPKI) to configure?
- What convergence targets (e.g., sub-second, 1-5s, 5-30s) do you expect under link or node failures?
- Do you require configuration of route reflectors, confederations, or segmented routing domains as part of the core routing config?
Implement segment routing and MPLS traffic engineering
- Is Segment Routing (SR-MPLS or SRv6) required for the pilot or final deployment?
- Do you have existing MPLS/TE infrastructure that must interoperate with SR policies?
- What TE objectives are required (e.g., bandwidth reservations, latency optimization, least-cost paths)?
- Will a centralized controller/path-computation element (PCE) be used for TE policy calculation?
- Do you require end-to-end SR policy testing in lab with synthetic traffic before pilot cutover?
- Are there interop checklists or neighbor-vendor capabilities we must validate for MPLS/SR?
Provision QoS, buffer, and queuing profiles
- Do you have defined traffic classes and SLAs (e.g., voice, video, bulk) that must be mapped to QoS profiles?
- What shaping, policing, and queuing behaviors are required per class (e.g., strict-priority, WFQ, CBWFQ)?
- Are there per-interface or per-tenant buffer/queue tuning requirements due to latency-sensitive services?
- Do you need QoS verification tests (e.g., microburst tests, latency/jitter measurements) in lab and pilot?
- Should legacy QoS policies from incumbent hardware be translated automatically, or do you prefer manual redefinition?
- Do you require monitoring and telemetry for QoS and buffer occupancy integrated into collectors/dashboards?
Apply hardware forwarding optimizations and ASIC tuning
- Are there specific hardware forwarding features you require (e.g., TCAM partitioning, exact-match acceleration, L2/L3 offloads)?
- What forwarding performance targets must be achieved (e.g., line-rate per port type, per-flow throughput)?
- Do you want vendor-provided ASIC tuning profiles applied by default or tested/tuned per your traffic profile in lab?
- Are there expected maximum route or adjacency counts that require TCAM or hardware resource adjustments?
- Do you accept short maintenance windows for in-field microcode or forwarding profile updates during pilot?
- Please describe any fail-open/fail-safe forwarding behaviors required during code/ASIC updates.
Deploy streaming telemetry pipelines to collectors
- Which telemetry formats and protocols should be enabled (e.g., gNMI, GPB/gRPC, NETCONF, SNMPStreams)?
- What collectors and analytics platforms will ingest streaming telemetry (vendor collector, Prometheus, Influx, Splunk, custom)?
- What sampling rates, frequency, and retention policies are required for interface counters, jitter/latency metrics, and forwarding telemetry?
- Are secure transport and authentication (TLS, client certs) mandatory for telemetry streams?
- Do you require telemetry schema/model mapping (e.g., OpenConfig vs. vendor models) and transformation in the pipeline?
- Should we validate telemetry completeness and alerting during lab and pilot before production roll-out?
Integrate gNMI/NETCONF/RESTCONF APIs with OSS/NMS
- Which OSS/NMS systems must be integrated (list vendors and versions)?
- Which southbound API protocols do you require for integration (gNMI, NETCONF, RESTCONF, SNMP)?
- What authentication and authorization schemes are required (e.g., OAuth2, client certs, username/password, TACACS+/RADIUS)?
- Do you need YANG/model translation, mapping, or custom telemetry-to-OSS adapters developed?
- Will integration be validated in a test/lab environment prior to pilot, and who are the owners for validation?
- What automation use-cases do you want via these APIs (e.g., config push, compliance checks, telemetry-driven remediation)?
Migrate BGP adjacencies via phased cutover execution
- How many BGP adjacencies (peers) are in-scope for the migration and what types (iBGP/eBGP/L2/L3)?
- Do you require an automated phased cutover runbook with rollback steps for each adjacency group?
- What migration window constraints exist (maintenance windows, blackout periods, geo/timezone limits)?
- Will you use traffic-splitting/traffic-mirroring or deterministic cutover (flap peers) for validation during phased migration?
- Do you require pre- and post-cutover routing validation tests (e.g., route-ping, path-trace, convergence timing measurements)?
- Who are the owners and escalation points on both sides (customer/vendor) for adjacency migration activities?
-
Mutual Commit
Finalize commercial terms, pilot Ordering, multi-year pricing, and contractual acceptance gates tied to lab and pilot results.
Agreement Modules
- Commercial Term Sheet
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Pilot Order Form
- Purchase Order / Procurement Submission
- Volume & Multi-Year Pricing Schedule
- Acceptance Gates & Lab-to-Pilot Criteria
- Service Level Agreement (SLA) & Support Matrix
- Software Licensing & Maintenance Agreement
- Change Order & Scope Management
- Payment Schedule & Invoicing Terms
- Termination, Exit & Migration Plan
- Regulatory, Export & Compliance Certifications
- Contract Redlines Log & Approval Tracker
- Financing & Credit Application
-
Deployment
Operationalize rollout with readiness checks, enablement, and outcome validation.
-
Pre-Deployment Readiness
Confirm lab results, access, rollback plans, automation scripts, and owners required for a safe pilot and migration.
Readiness Questions
Getting Comfortable — Where We Start Together
- Who will be our primary technical contact for the pilot (name and role)?
- What is the single primary objective you want this pilot to prove (e.g., line-rate forwarding, convergence SLAs, telemetry fidelity, vendor interoperability)?
- What is your target window to start the pilot (earliest date) and your target completion date?
- Are there blackout dates or maintenance windows we must avoid? If so, list them (timezones and specifics).
- How do you currently expect the pilot to coexist with your production network (dual-homing, out-of-path test links, isolated lab to limited-production segment)?
If This Goes Sideways, Who Feels It Most?
- What would the customer- or revenue-impact look like if the pilot caused a service disruption for 30 minutes?
- Which services or prefixes are non-negotiable to keep stable during the pilot (voice, transit, CDN peering, enterprise customers, etc.)? Please list specifics.
- How fast must we restore normal service to avoid escalations or penalties (target MTTR/RTO)?
- Have prior migrations or pilots exposed failure modes we should explicitly plan to avoid (e.g., control-plane storms, forwarding blackholes, TTL issues)? Describe briefly.
- How does your executive and customer-communications process work when incidents occur (who speaks, what channels, notification cadence)?
Who Holds the Keys — Access, Permissions, and Approvals
- Do we currently have the necessary account access, privilege levels, and on-call approvals to make and validate changes during pilot windows?
- List the systems and networks we must access for the pilot (NMS, OSS/BSS, BGP routers, fabric controllers, out-of-band management, lab chassis):
- What authentication model do you require for temporary escalation (MFA, just-in-time access, jump-hosts, privileged access sessions)?
- Who is authorized to approve emergency configuration changes or rollbacks during the pilot (name/role)?
- Are there change-control processes, tickets, or CAB approvals that will block rapid troubleshooting? If yes, how long do those approvals typically take?
Plan B: Rollbacks, Safety Nets, and Escape Hatches
- Do you have a documented rollback procedure for the pilot changes that can be executed under pressure?
- What is your target rollback RTO (time to revert safely) that we should design to?
- Who is authorized to call a rollback and what is the decision escalation path during an emergency?
- Where are your backup configs, device images, and critical artifacts stored, and are they versioned and accessible during the pilot?
- Can we rehearse the rollback on a non-production mirror or in the lab prior to pilot start? If yes, where and when?
Automation: Scripts, Telemetry, and Who Owns Them
- How confident are you that automation will reduce human error during migration rather than introduce new risks?
- Which automation and orchestration tools are in your stack or preferred for the pilot (Ansible, Salt, Nornir, Netbox, CI/CD runners, in-house scripts)?
- Are your automation scripts stored in a version-controlled repository with branching, PR reviews, and test hooks?
- Who will own the runbooks and automation during the pilot (names/roles) and who will be the tie-breaker if runbook divergence appears?
- What telemetry streams and KPIs must be consumed by automation for go/no-go decisions (e.g., interface counters, CPU, BGP convergence time, packet loss)?
Lab Results — Evidence, Gaps, and What Keeps You Up at Night
- Do the lab outcomes give you confidence to run the pilot as-is, or do they leave open operational questions we must still answer?
- Please summarize the lab tests you ran and the pass/fail outcomes (throughput, convergence, scaling, telemetry):
- Which specific lab results would you like us to reproduce in the pilot environment before a go decision?
- Were there any anomalies in the lab that you suspect might surface only under production traffic patterns? If so, describe.
- What additional acceptance tests or stress scenarios would make your team sleep better at night before broad migration?
Coordination Rhythm — Who Does What, When
- If a critical incident occurs during the pilot, who is on the escalation list and in what order should we engage them?
- What communication channels do you want us to use for routine updates versus urgent escalations?
- Do you have a RACI (or equivalent) defined for pilot tasks (who configures, who validates, who signs off)? If not, who should we coordinate with to build it?
- What are your expectations for on-call coverage during the pilot (hours per day, weekend coverage, dedicated engineer)?
- Who will make the final go/no-go decision at the end of pilot validation (name/role) and what criteria will they require to sign off?
Signatures and Gates — Acceptance Criteria You Won't Bend On
- Which acceptance criteria are absolute deal-breakers for you (list up to 5 non-negotiables)?
- For the criteria you listed, what specific measurable thresholds constitute pass versus fail (e.g., <0.1% packet loss, BGP convergence <500ms)?
- Which acceptance gates are negotiable or raise/no-go conditional issues we can mitigate (for example, tweak config, increase monitoring, extend pilot)?
- Who will record and sign the acceptance results (roles and expected artifacts — test logs, telemetry captures, runbook annotations)?
- If an acceptance gate fails, what is the preferred next step—rollback, extend pilot with remediation, escalate to execs, or other? Please rank or describe.
-
Deployment Enablement
Schedule pilot and migration tasks, assign owners, runbooks, escalation paths, and automation deployment steps.
-
Validation Checklist
Execute acceptance tests (throughput, convergence, telemetry), document results, and confirm go/no-go decisions.
Validation Questions
Starting the Conversation: What Brought You Here?
- What’s the single most important trigger that moved this project from 'maybe' to 'now'?
- How long has this need been on your roadmap before reaching this point?
- Who raised or sponsors this effort internally (team or role)?
- How would you describe the program’s urgency on a practical timeline?
- If this project were delayed by 6 months, what would materially change for the business or operations?
If We Could Break Your Network Right Now, What Would Hurt Most?
- Which production services would cause the most customer and commercial damage if they degraded?
- What failure modes keep you up at night when thinking about a migration?
- Tell us about the last significant incident that influenced your thinking on upgrades—what happened and what was the impact?
- How do monitoring and detection typically surface problems today?
- How quickly do you need automated detection and rollback to operate during a pilot or cutover?
Who Really Owns the Decision—and What They’ll Insist On
- If the leadership team were asked to defend the choice of a new core router, what top-level objection would they raise?
- Which internal roles must explicitly sign off before you can run a pilot?
- For each stakeholder above, what is their primary success criterion (example: throughput, cost, APIs, support responsiveness)?
- Who would likely veto the program if a non-technical concern surfaced, and what sort of concern would trigger that veto?
- How risk-averse are the primary decision-makers when it comes to core routing changes?
What Would Perfectly Working Look and Feel Like After Migration?
- Imagine this migration is judged a clear success one year after completion—what three outcomes would you point to first?
- Which measurable signals are must-haves for you to call the project successful?
- What specific numeric targets should we aim for (throughput Gbps, route count, convergence ms, telemetry events/sec)?
- How should customer experience improvements be quantified (SLA compliance, transit latency, packet loss, customer NPS)?
- What operational habits must improve to call this a success (automation, fewer manual CLI changes, fewer vendor escalations)?
What Are You Willing to Tolerate During Migration?
- How much traffic are you comfortable placing on a pilot/limited-production segment during validation?
- What is an acceptable duration for running a dual-vendor or mixed environment?
- What are your non-negotiable rollback criteria during a pilot or migration window?
- What level of transient customer impact is tolerable during migration planning/execution (e.g., short re-routes, temporary BGP flaps)?
- Which interfaces, protocols, or integrations must remain unchanged or fully compatible throughout the migration?
The Lab Is the Truth: What Would Convince You?
- What single failure in a lab test would cause you to pause the program until addressed?
- Which lab test cases are absolute must-pass items for your team?
- What pass/fail thresholds do you require for convergence and throughput testing (please provide target numbers or ranges)?
- How would you like lab evidence delivered for internal review?
- Who on your team will be the technical authority for lab sign-off, and who will be the executive sponsor for acceptance?
Hidden Constraints: What We Often Miss Until It’s Too Late
- What obscure network behavior, custom script, or one-off integration would derail a migration if we didn’t surface it early?
- Are there regulatory, peering, or contractual constraints that limit how and when we can change paths or handoffs?
- Do you have undocumented extensions, in-house BGP attributes, or custom telemetry consumers we should know about?
- Are there physical or data-center constraints (rack space, power budget, lead time for new gear) that will affect deployment timing?
- Who can approve exceptions when we hit one of these hidden constraints during the project?
Timing, Commercials, and Next Steps — Can We Commit?
- If we delivered validated pilot hardware and software in X weeks, would you be prepared to place a pilot order?
- What is your target date to complete a pilot go/no-go decision?
- Who owns the budget and procurement approvals for pilot and for multi-year volume purchases?
- Which commercial terms are essential for you to proceed (select all that would materially affect your decision)?
- What would be your preferred structure for acceptance gates (lab metrics, pilot duration, service-level proof, customer QoE)?
- What are the next three internal actions you need to take after this discovery to get to a pilot order?
-
-
Success
Confirm outcomes against success signals, capture learnings, and maintain a shared channel for issues and enhancements.
Success Reviews
- Success Executive Review — Outcomes vs Success Signals
- Technical Acceptance & Validation Workshop
- Operational Handover & Runbook Transfer
- Lessons Learned & Continuous Improvement
- Post‑Go‑Live Triage & Ongoing Improvements (Recurring Stand‑up)
Issues & Enhancements
- Archive a short Lessons Learned document in the shared channel for future reference and sales enablement.
- Schedule follow-up validation tests for remediated items and define success criteria for re-test.
- Re-establish Operational Pain Points
- Complete a verified operational handover with runbooks, automation, and monitoring integrated into customer ops processes.
- Identify any missing operational capabilities or training gaps and schedule remediation.
- Ensure clear escalation paths and SLAs are in place and documented in the shared channel.
- Publish final runbooks, automation scripts, and dashboard links to the shared channel and mark completed handover items.
- Schedule hands‑on operator training sessions and certify named operators per the agreed checklist.
- Update the NOC/SOC playbooks with vendor escalation contacts and onboard them to the shared communications channel.
- Timeline Recap & Key Decision Points
- Produce a prioritized improvement backlog derived from concrete lessons learned.
- Assign accountable owners and deadlines for the top 3–5 improvements with measurable acceptance criteria.
- One‑sentence Current State
- Publish the Lessons Learned document and prioritized backlog to the shared channel within 5 business days.
- Create product/engineering tickets for high‑priority items and assign owners with target delivery quarters.
- Schedule the quarterly Continuous Improvement review with customer and internal stakeholders.
- Incident Triage (Top 3)
- Keep critical incidents progressing toward closure within agreed SLAs and maintain transparency with customer stakeholders.
- Identify early telemetry signals requiring proactive mitigation to avoid degradation.
- Ensure enhancement backlog items are progressing and customer feedback is being actioned.
- Create/assign incident cards for any new issues and post updates to the shared channel immediately after the meeting.
- Update telemetry dashboards thresholds or alerts if trends indicate false positives or missed detections.
- Triage new enhancement requests into the prioritized backlog and notify owners of acceptance or deferral.
- Obtain a clear executive decision tied to measured success signals (accept, remediate, or extend).
- Ensure the business consequence that justified the project is acknowledged and addressed by the decision.
- Assign accountable owners and deadlines for any remediation or handover activities.
- Confirm persistent shared communication channel and stakeholder distribution list for post‑go‑live issues.
- Produce and distribute the Executive Success Report (metrics, pass/fail, decision, owners) within 24 hours.
- If remediation required, create remediation plan with milestones and owner within 3 business days.
- Create or verify the shared channel (Slack/Teams) and add all named stakeholders; publish escalation matrix.
- Confirm Current Operational Problem Statement
- Demonstrate test artifacts that prove each technical success signal (Diagnosis -> Proof -> Validation).
- Obtain explicit technical acceptance or prioritized remediation list with owners and timelines.
- Ensure every proof is tied to a stated customer problem and elicit explicit confirmation from customer engineers.
- Capture remaining interoperability or migration risks and rank them by operational impact.
- Deliver a packaged evidence bundle (test logs, configs, charts, scripts) to customer engineering within 48 hours.
- Open remediation tickets for any failed signals with owner, severity, and target resolution date.
- Root Cause Analysis of Major Issues
- Telemetry Trends & Early Warnings
- Consequence Recap
- Test Evidence Walkthrough — Throughput & Capacity
- Runbook & Automation Walkthrough
- Enhancement Requests & Backlog Status
- Success Signals Dashboard
- Monitoring, Alerting, and Telemetry Integration
- Test Evidence Walkthrough — Convergence & Failure Modes
- What Worked — Playbook Items to Repeat
- Programmability & Telemetry Proof
- Enhancement Backlog & Prioritization
- Customer Feedback & Satisfaction Check
- Gaps, Risks, and Impact
- Incident Escalation Paths & On‑call Support
- Interoperability & Migration Risk Assessment
- Training, Knowledge Transfer, and Handover Checklist
- Executive Decision & Next Steps
- Assign Owners and Review Cadence
- Action Review & Next Steps
- Validation Vote & Acceptance Criteria Check
- Wrap-up and Communication Plan