Back to Sync Connect

Technical comparison

A Kepware Alternative for Standard OT/IT Routes

Sync Connect can be a practical Kepware alternative when the requirement is a focused, configuration-driven route between standard industrial sources and modern IT targets. It is not a replacement for Kepware’s full driver catalogue.

Architecture.

Migration does not have to be all-or-nothing. Run Sync Connect beside the existing server, move one route with explicit acceptance criteria, and retire the old path only after values, quality and recovery behaviour match.

OPC UA, S7, Modbus or KNX to MQTT, Kafka, REST or databases through Sync Connect integration layer

OPC UA, S7, Modbus or KNX

Sync Connect integration layer

MQTT, Kafka, REST or databases

When this route fits.

Move standard OPC UA, S7 or Modbus routes to a Linux-native deployment.

Replace GUI-managed point mappings with version-controlled YAML.

Separate a modern MQTT or database route from a large legacy server.

Configuration pattern.

A first migration slice should be small and reversible. This pattern moves one OPC UA resource to MQTT while the existing middleware remains available for comparison.

config.yaml
resources:
  migration-slice:
    temperature: ns=4;i=1
    machineState: ns=4;i=5

providers:
  existing-opc-endpoint:
    driver: opcua
    config:
      endpoint: opc.tcp://192.168.10.20:4840

connectors:
  production-mqtt:
    driver: mqtt
    config:
      broker: 192.168.20.15
    routes:
      migration/line-1:
        mode: read
        provider: existing-opc-endpoint
        resource: migration-slice

Use parallel observation before cutover. Compare value, timestamp, quality, update rate and reconnect behaviour—not only whether a number arrives.

Technical fit.

Sync Connect strength
Focused standard routes, headless deployment and versioned config
Kepware strength
Broad legacy and specialist driver catalogue
Migration unit
One source-to-target route at a time
Decision basis
Protocol fit, operations model, lifecycle and total cost

Security and network.

  • Run both systems with read-only access during the observation phase where controller capacity permits.
  • Give the new route separate broker/database credentials and monitoring.
  • Record the existing scan rate, deadband, quality mapping and timestamp source before migration.
  • Keep a documented rollback path until the acceptance window is complete.

Failure and recovery behaviour.

Parallel comparison

Compare values and quality over representative production states, communication interruptions and maintenance windows.

Cutover

Switch one consumer or topic at a time. Avoid changing source acquisition, payload model and dashboard logic in the same step.

Rollback

Preserve the old configuration and credentials until the new route has passed the agreed stability period.

Limitations and better alternatives.

  • Choose Kepware when the project depends on a specialist or legacy driver outside Sync Connect’s supported provider set.
  • Existing Kepware plug-ins, client interfaces or vendor support agreements may make migration uneconomical.
  • A lower license cost does not automatically mean lower total cost; engineering, validation and operations must be included.

Compare one real route

Bring the current driver, tag count, scan rates, clients and license model. We will identify a representative migration slice and the evidence needed for a decision.

Check technical fit