A quick map of your control footprint

• Tell me briefly where your controllers are deployed across the site, by area and machine type. Options: Packaging/line equipment, Process units (reactors, columns), Utilities (boiler, chiller), Pumps/compressors, OEM machines and cells, Water/wastewater systems, Other
• Approximately how many discrete controller nodes (PLCs/DCS controllers/edge controllers) are actively controlling production today? Options: 1-10, 11-50, 51-200, 201-500, 501+
• When was the last time you replaced a controller or completed a major controller firmware revision on a production line? Options: Within 6 months, 6-18 months ago, 18-36 months ago, More than 3 years ago, Not tracked
• Describe the oldest controller model still in production and its approximate age.
• Who on your team owns controller lifecycle, spare strategy, and obsolescence decisions? Options: Controls engineering manager, Maintenance/operations manager, IT/OT manager, Procurement, Site director, Shared responsibility
• Which single controller failure scenario would stop production for more than one shift?

How failures actually translate into business impact

• If a critical controller failed during your busiest shift, what immediate safety, quality, or production impact would require an emergency response?
• How often have controller-related unplanned shutdowns occurred in the past 12 months? Options: None, 1-2, 3-6, 7-12, Monthly or more
• Which machines or process steps are most sensitive to I/O loss, latency, or jitter? Options: High-speed packaging, Batch sequencing, PID control loops, Safety interlocks, Analytical feedback loops, Other
• How do you currently detect failing controllers before they cause downtime (diagnostics, predictive alerts, operator rounds)? Options: Built-in controller diagnostics, 3rd-party monitoring, Operator observations, Maintenance schedule only, No early detection
• What proportion of repair time is driven by spare-part lead time versus on-site labor or configuration? Options: Mostly spare lead time, Split fairly evenly, Mostly labor/configuration, Unknown
• Which unresolved reliability issue would make you walk away from a proposed solution?

Migration barriers and hidden integration costs

• Tell me about a migration task from your last upgrade that surprised you with time or cost overruns.
• List the third-party systems that must be reconnected during migration and who owns each interface (SCADA, MES, historian, drives, safety PLCs).
• Are there legacy fieldbus networks or proprietary I/O modules in your cells that lack published APIs or vendor support? Options: Yes, several, Yes, a few, No, Unsure
• How much of your controller logic is undocumented or maintained by a single engineer approaching retirement? Options: >50%, 25-50%, 10-25%, <10%, None/fully documented
• If migration required staged coexistence, how long could you tolerate running two control platforms side by side before cutover? Options: <1 week, 1-4 weeks, 1-3 months, 3-6 months, Longer than 6 months
• Name the integration dependency that would stop the project until it is resolved.

The other options on your table

• List the alternatives you are actively considering besides the seller's platform. Options: Stay with incumbent vendor, Switch to different commercial control platform, Internal migration/rewrites, System integrator-led retrofit, OEM-provided control package, Delay or defer decision, Other
• For each alternative, what would have to be true about it for you to pick it over changing platforms?
• Has anyone on your team proposed solving this migration internally, without outside vendor or integrator help? Options: Yes, fully internal, Yes, internal with contractor support, No, external partner required, Undecided
• Who currently supplies your main control platform and what is the current support or contract term length?
• If you stayed with your current approach, what single change would need to happen to keep you from switching?

What success truly must deliver for you

• If the project only met the base technical requirements, what operational gap would still make the program unacceptable?
• List the KPIs you will use to judge success in the first 12 months and who owns each KPI. Options: Unplanned downtime hours, Mean time between failures, Mean time to repair, Control loop stability (variance), Engineering hours per change, Number of cybersecurity incidents, Other
• Are there numeric targets for those KPIs you can share now (example, reduce unplanned downtime to X hours per month)? Options: Yes, specific targets provided, Targets exist but not finalized, No numeric targets yet, Prefer to discuss in workshop
• Who signs off on acceptance tests and who approves go/no-go for cutover? Options: Site operations manager, Controls engineering manager, Plant director, IT/OT security lead, Procurement, Other
• If the pilot achieves the stated KPIs, would your team be authorized to approve a full rollout within 30 days? Options: Yes, No, Maybe, pending procurement, Only with executive sign-off

Practical gates we must clear before we start

• Which single logistical or approval constraint could delay on-site work past your target start date?
• Select which site access and readiness items are already arranged for deployment. Options: Site access approvals, OT network segmentation plan, Named OT point-of-contact, Named IT point-of-contact, Spare parts logistics, Local integrator contract, Safety orientations scheduled
• Are network diagrams, VLAN plans, and IP addressing available for the areas to be upgraded? Options: Complete and current, Partial and needs update, Not available, Held by third party
• Do you have a dedicated controls engineer available during migration weeks and how many FTE-weeks can they commit? Options: <1 FTE-week, 1-2 FTE-weeks, 3-4 FTE-weeks, 5+ FTE-weeks, No dedicated resource
• Are there regulatory, safety, or compliance approvals that must be secured before deployment can begin? Options: Yes, safety approvals, Yes, regulatory permits, Yes, IT/security clearance, No major approvals, Unsure
• If required field work needs additional vendor access or permits, can those be obtained within your timeline? Options: Yes, No, Depends on permit, Unsure

Who must buy in and who can stop this

• Who in your organization would veto the project if they have unresolved concerns? Options: Plant director/site lead, Head of maintenance, IT/OT security lead, Procurement, Finance/CFO, Other
• List the stakeholder groups who will review the final recommendation and each group's primary concern (reliability, cost, security, uptime).
• Which role prioritizes long spare parts availability and lifecycle length over initial purchase price? Options: Maintenance manager, Controls engineering, Procurement, Operations manager, Site director, Not prioritized
• Who will be the technical owner during deployment and who will own long-term support and spare management? Options: Controls engineering, Maintenance, Third-party service partner, Combined team, Other
• If the project faces a 15% budget overrun, who has authority to approve additional spend? Options: Plant director, Site finance/procurement, Regional operations, Corporate finance, No authority defined

Timeline, budget and acceptable risk

• If the project slips three months, what business consequence would make it untenable?
• What budget range has been allocated or is expected for the base deployment? Options: <$50k, $50k-$200k, $200k-$500k, $500k-$1M, >$1M, Undisclosed/not finalized
• How much contingency are you comfortable allocating to migration unknowns as a percentage of the base budget? Options: 0-5%, 5-10%, 10-20%, 20%+, Undecided
• Select the risks you consider unacceptable under any contract terms. Options: Extended production downtime >1 shift, Data loss during cutover, Failed cutover with rollback risk, New cybersecurity exposure, Loss of proprietary logic, Other
• Which minimum spare parts availability would cause you to reject a solution if unmet? Options: 5 years, 10 years, 15 years, 20 years, No minimum required

Designing a pilot that proves value fast

• If a 6-week pilot could prove the core KPI, what must be included to make the results credible to your executives?
• Which pilot scope would demonstrate value fastest for you? Options: Single machine/cell, Entire production line, Critical utility system, Redundancy/high-availability test, Integration with SCADA and historian
• What data and measurements must the pilot deliver to validate migration risk and performance? Options: Downtime reduction, Control loop variance, I/O error rate, Configuration/rebuild time, Cybersecurity posture checks, Other
• Who will provide access, test points, and on-site coordination during the pilot? Options: Controls engineer, Maintenance lead, Operations supervisor, IT/OT security contact, Third-party integrator
• If pilot metrics match targets, could procurement sign a statement of work within 7 business days? Options: Yes, No, Maybe, pending legal review, Depends on contract terms
• Finally, what immediate next step would most accelerate progress from discovery to a scoped pilot? Options: On-site scoping visit, Technical workshop with sample logic, Network and asset documentation handoff, Fast-track pilot statement of work, Other

• Solution Experience — Control Platform Fit

• Confirm the current state and quantify the cost
• You confirm the demonstrated scenario meets your worst-case processing cycle time and has acceptable engineering headroom.
• Provide the representative logic sequence, I/O list, and one typical HMI screen for the scenario to test during the lab run.
• You agree that the proposed migration pathway limits downtime to acceptable windows and includes clear rollback triggers.
• Walk a representative production scenario end-to-end
• Provide your list of acceptable cutover windows, required acceptance tests, and maximum allowable downtime per asset.
• You accept that the shown cybersecurity controls meet your OT/IT policy or identify specific gaps to close before Mutual Commit.
• Demonstrate cybersecurity posture against your policy
• Run the customer's scenario on a lab system and deliver measured processing performance, I/O mapping validation, and a proposed migration sequence before the follow-up session.
• Show migration pathway and rollback plan for your scenarios
• Deliver a migration risk matrix and rollback plan addressing the specific failure modes discussed during the session.
• Validate fit with a direct confirmation

• Solution Experience — Control Platform Fit
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Supply modular PLC rack
• Install redundant controller pair
• Port control logic to the new platform
• Configure HMI screens and tag database
• Deploy SCADA server and historian
• Install managed industrial switches and VLANs
• Configure cybersecurity appliance and firewall rules
• Program field I/O mapping and wiring
• Install IP67 on‑machine I/O modules
• Commission control system with FAT and SAT
• Deliver operator and engineer training
• Provide spare parts kit and firmware images

Supply modular PLC rack

• Do you require a specific rack form factor (for example 3U panel, 6U panel, or 19-inch rack) for the PLC enclosure? Options: 3U panel, 6U panel, 19-inch rack, Custom — describe
• How many controller and I/O card slots must the rack support at initial install and after planned expansion in 5 years? Options: Initial only (specify), Initial + 20% expansion, Initial + 50% expansion, Custom expansion plan
• Which environmental protection rating is required for the rack in your control room or field cabinet (for example IP20, NEMA 12)? Options: IP20 / Indoor, IP54 / Dust and splash, NEMA 12, Other — specify
• Specify required compliance standards for the rack and mounting hardware (for example IEC 61131-2, UL 508A, local seismic anchoring).
• List preferred cable entry and grounding arrangements you need pre-provisioned in the rack (top/bottom side entries, number of gland plates, single point earth).
• Identify any mechanical or timeline constraints for rack delivery and on-site staging (lead time in weeks, pre-assembly required, factory acceptance needed).

Install redundant controller pair

• Which controller models or CPU classes must be included in the redundant pair (specify CPU performance class or scan time target)?
• How will you set required redundancy mode: cold standby, warm standby, or hot-active redundant execution for PLC logic? Options: Cold standby, Warm standby, Hot-active redundancy, Undecided — need recommendation
• What mean time between failure (MTBF) or availability target must the redundant controller pair meet for your process (for example 99.9% uptime, or <1 hour/year downtime)? Options: 99.0%, 99.9%, 99.99%, Custom target — specify
• Are there specific I/O switchover or synchronization windows the redundant pair must support during cutover to avoid process interruption (specify milliseconds or seconds)?
• Who is the named on-site responsible engineer for redundant controller failover tests during commission and what authorization level will they have?
• Identify required spare controller hardware you want included with the redundant pair (hot spare CPU, spare power supply, spare communication module). Options: No spares needed, Hot spare CPU, Extra power supply, Extra comms module, Custom list

Port control logic to the new platform

• Which existing controller family and program artifact types are we migrating from (for example ladder logic rungs, function block diagrams, structured text files, and their file extensions)?
• How many function blocks, motion axes, and total tag count does the existing control application contain (provide approximate counts)
• Which logic elements require manual remediation when porting (proprietary instructions, vendor-specific PID blocks, or custom libraries)? Options: Vendor-proprietary instructions, Custom libraries, PID loops, Motion profiles, None / minimal
• What migration completeness threshold do you require to accept the ported control logic (for example 100% functional parity, or 95% with documented exceptions)? Options: 100% parity, 95% parity + documented exceptions, Phased parity — critical loops first
• Describe the preferred strategy for preserving historic control behavior during porting (retain tag names, preserve scan ordering, or maintain original numeric addresses).
• Which test artifacts do you require with the ported logic delivery (unit test scripts, simulation snapshots, annotated code diff)? Options: Unit test scripts, Simulation snapshots, Annotated code diff, All of the above, Other

Configure HMI screens and tag database

• How many HMI screens and unique graphics objects must be delivered in the initial scope and after the first phase update? Options: Less than 50 screens, 50-200 screens, 200-500 screens, More than 500 screens
• Which runtime visualization elements are required (alarm list, trends, recipe editor, operator prompts) and which must be editable by site engineers after handover? Options: Alarm list, Trends, Recipe editor, Operator prompts, All editable
• What tag naming convention and tag database structure do you require to be preserved or established (for example hierarchical area:line:device:point)?
• Which integration endpoints must the HMI connect to at runtime (controller IPs, OPC UA endpoint URLs, historian ingest endpoint)?
• What acceptance evidence will validate HMI scope delivery (for example sign-off on an operator walkthrough with scripted scenarios)? Options: Operator walkthrough sign-off, Documented screen-by-screen checklist, Simulated run with acceptance script
• Are there language, font, or accessibility requirements for operator screens (multiple languages, large-font mode, color-blind palettes)? Options: Single language, Bilingual, Multi-language, Accessibility mode required

Deploy SCADA server and historian

• Which SCADA server sizing parameters do you require (concurrent clients, tag count, alarms per hour, historian write rate in writes per second)?
• What historian retention policy and archival cadence do you need (for example raw data retention 1 year, aggregated 10 years, rollups daily)? Options: Raw 1 year / aggregated 5 years, Raw 1 year / aggregated 10 years, Custom — specify retention days
• Which backup and restore procedures must be provided for SCADA and historian servers (full weekly backups, transaction log backup frequency)?
• Which database interfaces or export formats are required for analytics or integration (CSV export, ODBC, REST API, OPC HDA)? Options: CSV export, ODBC, REST API, OPC HDA, Other
• When do you require the SCADA and historian servers to be replicated for disaster recovery and what RTO/RPO targets do you set?
• Are there existing operational data models or tag taxonomy documents we must align with when creating historian schemas (provide document or say none)? Options: Provide existing taxonomy, No existing taxonomy — need design

Install managed industrial switches and VLANs

• How many switch ports and PoE requirements are needed at each cabinet or network zone (specify port counts per location)?
• Which VLAN segmentation and IP addressing scheme must be implemented (for example separate VLANs for OT control, engineering, and SCADA with /24 subnets)?
• Which industrial protocols must be supported on switches with Layer 2/3 features (PROFINET, EtherNet/IP, Modbus TCP, or other)? Options: PROFINET, EtherNet/IP, Modbus TCP, Other — specify
• What spanning tree or redundancy protocol behavior do you require for network convergence times (for example Rapid Spanning Tree Protocol targets in ms)?
• Who will provide the network zone diagrams and IP address plan for the VLAN implementation, and do you require we produce an updated single-line network diagram (SLD)? Options: You provide diagrams, We produce updated SLD, Joint update
• Identify physical delivery and staging constraints for switch installation (rack mount vs DIN rail, ambient temperature, site access windows).

Configure cybersecurity appliance and firewall rules

• Which network zones and integration endpoints must be protected by the cybersecurity appliance (OT control VLAN, DMZ, SCADA network)?
• What firewall rule policy model do you require (deny-by-default with explicit allow list, or allow-by-default with logging)? Options: Deny-by-default, Allow-by-default with logging, Need recommendation
• What intrusion detection or network monitoring signatures must be applied for your industry (for example OT-specific anomaly detection, OPC UA session monitoring)?
• What patch and firmware management cadence do you require for the appliance and what change control approvals are needed before updates? Options: Quarterly, Monthly, As-needed with approval, Specify cadence
• Which authentication method must be enforced for device and engineer access through the appliance (Active Directory integration, local accounts, multifactor)? Options: Active Directory / LDAP, Local accounts, Multifactor required, Other
• What cybersecurity acceptance evidence will confirm rules are correct (for example penetration test report, rule walkthrough, or signed policy document)? Options: Penetration test report, Rule walkthrough sign-off, Signed policy document

Program field I/O mapping and wiring

• How many field points (digital inputs, digital outputs, analog inputs, analog outputs) must be mapped and wired in the initial scope? Options: Less than 100 points, 100-500 points, 500-2,000 points, More than 2,000 points
• Which field device connection types are present on-site (4-20 mA analog, RTD/thermocouple, discrete voltage, HART, IO-Link)? Options: 4-20 mA, RTD / Thermocouple, Discrete voltage, HART, IO-Link, Other
• What wiring standards and cable classes must installers follow (for example tray separation rules, shielded twisted pair, conduit specifications)?
• Which terminal labeling and as-built deliverable do you require for field I/O (machine-readable terminal schedule, printed schematic, digital cabling map)? Options: Terminal schedule, Printed schematic, Digital cabling map, All of the above
• Who will perform field loop checks and provide loop test instruments during wiring verification (your team or our technicians)? Options: Your team, Our technicians, Joint team
• Identify any hazardous-area or intrinsically safe (IS) requirements for field wiring that impact module selection or installation procedures.

Install IP67 on‑machine I/O modules

• How many on-machine IP67 I/O nodes are required and what I/O mix per node (DI/DO/AI/AO) is expected?
• Which connector and cable types must be used for on-machine I/O to match your existing actuator and sensor cabling (M12 A-coded, M12 D-coded, other)? Options: M12 A-coded, M12 D-coded, Other — specify
• What maximum permissible cable run lengths and flex-cycle rating do you require for on-machine cabling to meet mechanical reliability targets?
• Which ingress protection and washdown standards must the IP67 modules meet for the machine environment (for example IP67 wet-clean, food-grade washdown)?
• Are there on-machine safety I/O integration requirements (safety-rated inputs, safety controllers, category PL/d or SIL level) that impact module selection? Options: Yes — specify level, No safety I/O required, TBD — need assessment
• Identify preferred installation approach for on-machine nodes (pre-cabled on assembly line, vendor-installed at site, or handed-off for your install). Options: Pre-cabled, Vendor-installed, Hand-off for your install

Commission control system with FAT and SAT

• Which factory acceptance test (FAT) scope do you require before shipping (full application simulation, partial, or factory smoke test)? Options: Full application simulation, Partial simulation, Factory smoke test only, Custom — specify
• What site acceptance test (SAT) scenarios must be executed on-site to demonstrate go-live readiness (normal production run, emergency stop, network failover)? Options: Normal production run, Emergency stop, Network failover, All of the above
• Who will be authorized to sign the FAT and SAT acceptance records on your side and what documentation format do you require (electronic sign-off, paper)? Options: Electronic sign-off, Paper sign-off, Both
• What measurable acceptance thresholds must be met during SAT for control performance (scan time under X ms, alarm latency under Y seconds, historian write success rate)?
• What cutover window and rollback criteria do you require for the live plant cutover and who has authority to declare rollback?
• What acceptance evidence will validate commissioning is complete (signed FAT/SAT reports with pass/fail criteria and punch‑list closure)? Options: Signed FAT/SAT reports, Closed punch-list items, Both

• Purchase Agreement
• Statement of Work (SOW)
• Master Services Agreement (MSA)
• Service Level Agreement (SLA)
• Spares & Obsolescence Commitment
• Warranty Statement
• Software License & Subscription Agreement
• Security & Migration Responsibilities Addendum
• Data Processing Agreement (DPA)
• Acceptance Test Protocol
• Payment Schedule & Order Confirmation
• Change Order Agreement
• Termination & Remedies Agreement
• Mutual Confidentiality Agreement (NDA)
• Regulatory Compliance Addendum (conditional)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate and Formal Acceptance (approx day 90)
• Quarterly Operational Review (ongoing)

• Schedule a focused technical detailed review if recurring incidents indicate systemic issues.
• Restate acceptance criteria and numeric targets
• Produce a documented pass or fail result for each acceptance criterion recorded in the Solution Scope and capture the formal acceptance decision.
• Confirm the incumbent system is decommissioned or formally retained-read-only and that data migration or archival is complete where required.
• Agree remediation items with timelines for any failed criteria and a date for verification.
• Publish the formal acceptance record citing each criterion result and the named signatory decision.
• Create a remediation and verification plan for any failed acceptance items with target completion dates.
• Confirm archival of legacy system data and document final decommissioning status.
• Transition accepted deliverables into the quarterly operational review cadence.
• Operational performance review
• Confirm continued compliance with the operational targets recorded in the Solution Scope for availability and repair time.
• Reduce the count of aged warranty and support tickets and agree timelines for remaining items.
• Prioritize enhancement requests that materially affect operational targets and set delivery windows.
• Update the operational dashboard with quarter-to-date availability and MTTR metrics for shared visibility.
• Close or escalate aged support tickets and publish a closure timeline for the remaining items.
• Replenish critical spare parts to the target stock level defined in the Solution Scope or document lead-time mitigations.
• Reconfirm acceptance criteria and owners
• Confirm the deployment completed to the configuration and acceptance checklist recorded in the Solution Scope.
• Produce a prioritized list of critical open issues with named owners and dates for resolution.
• Identify early adoption signals or gaps that require immediate attention before metric evaluation.
• Publish the go-live health report summarizing validation results and open issues.
• Log all defects and warranty tickets in the support system with owners and target resolution dates.
• Schedule the First Measurement Review within the agreed 4-10 week window.
• Present first measurement data
• Determine whether controller availability percentage and mean time to repair hours are moving toward the targets recorded in the Solution Scope.
• Agree a prioritized remediation plan with clear verification steps and dates to close gaps before the acceptance gate.
• Confirm spare parts and warranty mitigation actions required to protect uptime targets.
• Collect and share raw uptime and repair log extracts used to compute the reported metrics.
• Open targeted diagnostics for the top two root causes identified and document remediation steps.
• Update the spare parts procurement plan to meet the availability thresholds in the Solution Scope.
• Create a remediation tracker for cybersecurity findings with target closure dates.
• Deployment and migration validation
• Open warranty and support ticket burn-down
• Diagnose gaps and root causes
• Present outcome data against each criterion
• Support, warranty, and spare parts status
• Early adoption signals and usage patterns
• Document pass/fail per criterion and formal acceptance decision
• Enhancement requests backlog and prioritization
• Cybersecurity findings and mitigation status
• Spare parts and maintenance readiness
• Open issues and blockers
• Incumbent system wind-down confirmation
• Immediate remediation plan
• Agree remediation plan for any failed criteria
• Security and patching status
• Agree corrective actions and timeline to acceptance gate