> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-4-2/guides/migration/migrating-from-ignition.md). # Migrating from Ignition This guide shows you how to migrate the connectivity layer of an Inductive Automation Ignition Gateway to Connectware by exporting the tag configuration as JSON and translating it into a [service commissioning file](/2-4-2/data-flows/service-commissioning-files.md). Ignition covers many roles, from HMI to historian. This guide is about one of them: the device connections and OPC tags that read data from PLCs. In more detail, the following topics are covered: * Understanding how Ignition concepts map to Connectware resources * Exporting tags from the Ignition Designer and collecting device connection settings * Translating the export into a service commissioning file with an AI assistant * Reviewing the generated service commissioning file * Verifying the migrated data points in the [Data Explorer](/2-4-2/monitoring/data-explorer.md) A complete worked example, from tag export to service commissioning file, is available at the end of this guide. {% hint style="info" %} Migration is not the only way to combine the two products. Many teams keep Ignition for visualization and move the connectivity and Unified Namespace layer to Connectware, with Ignition consuming data from Connectware over MQTT or OPC UA. See [Ignition Integration](/2-4-2/guides/system-connectivity/mes-erp-business-systems/ignition-integration.md) for that pattern. {% endhint %} ## Prerequisites To follow this guide, you will need the following: * A running instance of Cybus Connectware with licenses for the connectors that replace your Ignition device drivers. * Access to the Ignition Designer and the Gateway web interface. The export steps apply to Ignition 8.x, including Ignition Edge. * Network access from Connectware to the PLCs that Ignition currently polls. After the migration, Connectware connects to the devices directly. * An AI assistant to translate the export. Any capable large language model (LLM) works. [Cybus Connectware GPT](/2-4-2/tools/cybus-connectware-gpt.md) is a ChatGPT assistant that already knows the service commissioning file format. * Basic knowledge of the Connectware [services](/2-4-2/data-flows/services.md) concept (for example, [service commissioning files](/2-4-2/data-flows/service-commissioning-files.md), [connections](/2-4-2/data-flows/service-commissioning-files/resources/cybus-connection.md), and [endpoints](/2-4-2/data-flows/service-commissioning-files/resources/cybus-endpoint.md)). ## How Ignition Concepts Map to Connectware Ignition's OPC UA module turns the Gateway into an OPC UA server that hosts device drivers. Tags subscribe to driver data through the internal OPC UA connection, and tag groups define the polling policy. Connectware organizes the same information in resources of a service commissioning file: | Ignition concept | Connectware resource | Notes | | ------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Device connection | [Cybus::Connection](/2-4-2/data-flows/service-commissioning-files/resources/cybus-connection.md) | One connection per configured driver instance, carrying the host, port, and device-specific options. | | OPC tag | [Cybus::Endpoint](/2-4-2/data-flows/service-commissioning-files/resources/cybus-endpoint.md) | The `opcItemPath` contains the device name and the driver-specific address; the tag data type and tag group complete the endpoint definition. | | Tag folder hierarchy | MQTT topic hierarchy | Folder nesting becomes path segments in the topics of a [Cybus::Mapping](/2-4-2/data-flows/service-commissioning-files/resources/cybus-mapping.md). | | Tag group | Polling interval | The tag group rate becomes the endpoint `interval` (or the connection `pollInterval` for connectors that poll per connection, such as S7). | | User-defined type (UDT) | No direct equivalent | UDT instances must be flattened into explicit endpoint lists during translation. | | MQTT Transmission (Cirrus Link) | [Cybus::Mapping](/2-4-2/data-flows/service-commissioning-files/resources/cybus-mapping.md) | Connectware publishes every endpoint to its integrated MQTT broker. For Sparkplug B consumers, see [Sparkplug B Integration](/2-4-2/guides/system-connectivity/industry-standards-interoperability/sparkplug-b-integration.md). | | Tag provider | MQTT topic root | Providers become a prefix in the topic structure. | ### Mapping Drivers to Connectors The following Ignition OPC UA drivers have a native Connectware connector: | Ignition driver | Connectware connector | | ------------------------------ | ----------------------------------------------------------------------------------- | | Modbus | [Modbus/TCP](/2-4-2/connectors/shop-floor-connectors/modbus-tcp.md) | | Siemens (S7-300/400/1200/1500) | [Siemens SIMATIC S7](/2-4-2/connectors/shop-floor-connectors/siemens-simatic-s7.md) | | Allen-Bradley Ethernet (Logix) | [EtherNet/IP](/2-4-2/connectors/shop-floor-connectors/ethernet-ip.md) | | BACnet | [BACnet](/2-4-2/connectors/shop-floor-connectors/bacnet.md) | For drivers without a native connector, for example DNP3, Omron, or Mitsubishi, keep the Ignition Gateway in place for those devices and read them through Ignition's OPC UA server with the Connectware [OPC UA Client connector](/2-4-2/connectors/shop-floor-connectors/opc-ua/opc-ua-client.md). A migration can be partial: native connectors for the covered devices, the OPC UA route for the rest. ### What Does Not Migrate 1:1 Ignition is an application platform, and everything beyond connectivity needs a deliberate decision instead of a translation: | Ignition feature | Connectware approach | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Vision and Perspective screens | Out of scope. Visualization stays in Ignition or moves to another HMI, consuming data from Connectware. | | Transaction groups (SQL Bridge) | Map endpoints to a database with the [SQL](/2-4-2/connectors/enterprise-connectors/sql.md) or [MSSQL](/2-4-2/connectors/enterprise-connectors/mssql.md) connector. | | Tag Historian | Store time-series data in an external database through the enterprise connectors, for example [InfluxDB](/2-4-2/connectors/enterprise-connectors/influxdb.md). Historical data itself does not transfer. | | Gateway and project scripts | Re-implement data logic with [Rule Engine](/2-4-2/data-flows/rule-engine.md) rules or in the [Node-RED Workbench](/2-4-2/data-flows/node-red-workbench.md). | | Alarm pipelines | Re-implement alarm evaluation and notification in the consuming systems. | | Reporting | Out of scope for a connectivity layer. | ## Exporting the Ignition Configuration The migration needs three inputs: the tag export, the device connection settings, and the tag group rates. ### Exporting Tags 1. In the Ignition Designer, open the **Tag Browser**. 2. Select the **Tags** tab, a folder, or individual tags. 3. Open the **More Options** menu and select **Export Tags**. 4. Save the export as a `.json` file. If your project uses UDTs, export the definitions as well: they are not included in the tag export. Repeat the export on the **UDT Definitions** tab of the Tag Browser and keep both files. For details, see [Exporting and Importing Tags](https://www.docs.inductiveautomation.com/docs/8.1/platform/tags/exporting-and-importing-tags) in the Ignition documentation. ### Collecting Device Connection Settings The tag export references devices only by name in the `opcItemPath`, so the connection settings must be collected separately: * On Ignition 8.3, the Gateway configuration is stored as human-readable `config.json` files under the `data/config` directory of the Gateway installation, and the Gateway REST API serves the same information. Hand the device connection files to the AI assistant together with the tag export. * On Ignition 8.1 and earlier, device connections live in the Gateway's internal database, and the Gateway backup is a binary archive. Transcribe the settings from the Gateway web interface under **Config > OPC UA > Device Connections**: driver type, hostname, port, and driver-specific options such as rack and slot for Siemens devices. ### Collecting Tag Group Rates The tag export names the tag group of each tag in the `tagGroup` property, but not its rate. Open the **Tag Group Editor** in the Designer and note the mode and rate of every tag group that your exported tags reference. The default tag group polls at 1,000 ms. ## Translating the Export with an AI Assistant {% hint style="warning" %} Tag exports can contain more than addresses, for example connection details in UDT parameters or documentation properties. Review the export and remove anything sensitive before you paste it into an AI tool, and check the data privacy terms of the tool you use. See also the privacy notes for [Cybus Connectware GPT](/2-4-2/tools/cybus-connectware-gpt.md#data-privacy). {% endhint %} Copy the following prompt, attach the tag export, the UDT definitions if any, and your list of device connections and tag group rates: {% code title="AI translation prompt" lineNumbers="true" expandable="true" %} ``` You are translating an Ignition tag export (JSON) into a Cybus Connectware service commissioning file (YAML). Produce one complete, valid service commissioning file with description, metadata, parameters, definitions, and resources. You also receive the device connection settings and the tag group rates, because they are not part of the tag export. Structural rules: - Only tags with "valueSource": "opc" read from devices. Skip memory, expression, and derived tags and list them at the end under "Not migrated". - Parse the device name from the opcItemPath: the format is "ns=1;s=[DeviceName]address". Create one Cybus::Connection per device, using the provided device connection settings (driver, host, port, rack, slot). Exports may JSON-escape the "=" character as "\u003d" inside the opcItemPath. - Create one Cybus::Endpoint per tag, referencing its connection with !ref. - Resolve UDT instances ("tagType": "UdtInstance") into concrete endpoints: take the tag definitions from the UDT definitions export, substitute each instance's "parameters" into the parameterized opcItemPath bindings, and emit one endpoint per resolved tag. - Polling: look up each tag's "tagGroup" in the provided tag group rates (default group: 1000 ms). For Modbus endpoints, set "interval" per endpoint. For S7 connections, polling is per connection: set the connection "pollInterval" to the most common rate of its tags and flag tags whose rate differs. - Create one Cybus::Mapping that publishes every endpoint to an MQTT topic mirroring the tag folder hierarchy, lowercase kebab-case. Keeping the hierarchy identical to Ignition makes the migration easy to validate. - Define host addresses as parameters, never hardcoded. Do not include any credentials in the output. Driver-specific rules for Modbus devices (protocol: Modbus): - Ignition Modbus addresses use designators: HR (holding register, fc 3), IR (input register, fc 4), C (coil, fc 1), DI (discrete input, fc 2). The numeric part is 1-based: HR1 -> address 0, HR20 -> address 19. - Typed designators set the data type and length: HR/IR with dataType Int2 -> int16BE, length 1; HRUS/IRUS -> uint16BE, length 1; HRI/IRI -> int32BE, length 2; HRUI/IRUI -> uint32BE, length 2; HRF/IRF -> floatBE, length 2; HRD/IRD -> doubleBE, length 4; C/DI -> boolean, length 1. - A leading "." prefix before the designator is the Modbus unit ID. A trailing "." suffix is bit access: flag it for manual review. Driver-specific rules for Siemens devices (protocol: S7): - Connection: host, port 102, rack and slot from the device settings. - Ignition S7 addresses like "DB10,INT4" or "IX20.3" translate to the Connectware S7 address syntax, which is very similar ("DB10,INT4", "DB10,X0.0" for bits). Verify data type letters against the Connectware S7 connector documentation and flag any address you are not certain about with a comment. For any device whose driver has no Connectware connector, skip it and list it under "Not migrated" with the recommendation to read it through the Ignition OPC UA server instead. After the YAML, output a migration report: number of devices and tags translated, all assumptions made, and every flagged item that needs manual review. [Attach: tag export JSON, UDT definitions JSON (if any), device connection settings, tag group rates.] ``` {% endcode %} For large projects, translate one tag provider or folder at a time and combine the results. Projects that rely heavily on UDTs need the most review effort, because every instance must resolve to concrete addresses. ## Reviewing the Generated Service Commissioning File Work through this checklist before installing: 1. Validate the file structure. The [Cybus Connectware Extension for VS Code](/2-4-2/tools/cybus-connectware-extension-vs-code.md) validates service commissioning files against the official schemas as you edit. 2. Check every connection against the Gateway's device connection settings: driver, host, port, rack, and slot. 3. Spot-check translated addresses, especially Modbus designators with typed suffixes and resolved UDT instances. The 1-based to 0-based register offset is the most common translation error. 4. Check that every tag group rate was applied and that S7 connections with mixed rates are handled deliberately. 5. Confirm that no credentials ended up in the file and that all site-specific values are parameters. 6. Compare the endpoint count against the migration report of the AI assistant and the tag count in the Tag Browser. ## Installing the Service 1. Install the service commissioning file. See [Installing Services](/2-4-2/data-flows/services/managing/installing.md). 2. Enable the service. See [Enabling Services](/2-4-2/data-flows/services/managing/enabling.md). **Result:** Connectware connects to the migrated PLCs directly and the connections reach the **Connected** state. {% hint style="info" %} For read-only validation, Connectware and Ignition can usually poll the same PLC at the same time. Check the connection limits of your devices first: Siemens S7 PLCs in particular accept only a limited number of concurrent connections, and S7-1200/1500 devices must have PUT/GET communication enabled for both clients. Remove the migrated devices from Ignition once the migration is verified. {% endhint %} ## Verifying the Data Open the [Data Explorer](/2-4-2/monitoring/data-explorer.md) and subscribe to the topics of the migrated service. Compare live values side by side with the Tag Browser in the Ignition Designer: * Every migrated tag publishes on its topic with plausible values. * Values match between Ignition and Connectware for the same data point. * Implausible numbers on multi-register Modbus tags indicate a wrong register offset or data type. * Data arrives at the rate of the original tag group. ## Worked Example The following tag export contains one folder with three OPC tags, spread over two devices: a Siemens S7-1500 behind the Siemens driver and a PLC behind the Modbus driver. {% code title="line1-tags.json" lineNumbers="true" expandable="true" %} ```json { "name": "Line1", "tagType": "Folder", "tags": [ { "name": "MotorSpeed", "tagType": "AtomicTag", "valueSource": "opc", "opcServer": "Ignition OPC UA Server", "opcItemPath": "ns=1;s=[S7-1500_Line1]DB10,INT4", "dataType": "Int2", "tagGroup": "Fast500ms" }, { "name": "FillLevel", "tagType": "AtomicTag", "valueSource": "opc", "opcServer": "Ignition OPC UA Server", "opcItemPath": "ns=1;s=[ModbusPLC]HRF20", "dataType": "Float4" }, { "name": "RunningFlag", "tagType": "AtomicTag", "valueSource": "opc", "opcServer": "Ignition OPC UA Server", "opcItemPath": "ns=1;s=[ModbusPLC]C5", "dataType": "Boolean" } ] } ``` {% endcode %} The device connections, transcribed from the Gateway: `S7-1500_Line1` is a Siemens driver instance at `192.168.1.100`, rack 0, slot 1; `ModbusPLC` is a Modbus driver instance at `192.168.1.101`, port 502. The tag group `Fast500ms` polls at 500 ms; the other tags use the default group at 1,000 ms. Applying the translation rules produces the following service commissioning file. `MotorSpeed` becomes an S7 endpoint with the address `DB10,INT4` on a connection polling at 500 ms; `FillLevel` (`HRF20`) becomes a holding register endpoint with `fc: 3`, `address: 19`, `length: 2`, and `dataType: floatBE`; and `RunningFlag` (`C5`) becomes a coil endpoint with `fc: 1`, `address: 4`: {% file src="/files/c7OPLxvApdwv8XXoBeRi" %} {% code title="ignition-migration-example.yml" lineNumbers="true" expandable="true" %} ```yaml description: > Service commissioning file migrated from the Ignition tag folder Line1 with the devices S7-1500_Line1 and ModbusPLC (Example) metadata: name: Ignition Migration Example provider: cybus homepage: https://www.cybus.io version: 1.0.0 parameters: s7Host: description: IP address of the device S7-1500_Line1 type: string default: 192.168.1.100 modbusHost: description: IP address of the device ModbusPLC type: string default: 192.168.1.101 definitions: # Topics mirror the Ignition tag folder hierarchy MQTT_TOPIC_PREFIX: line1 resources: # Ignition device connection "S7-1500_Line1" (Siemens driver) # Connection-level polling: tag group Fast500ms (500 ms) s7Line1Connection: type: Cybus::Connection properties: protocol: S7 targetState: connected connection: host: !ref s7Host port: 102 rack: 0 slot: 1 pollInterval: 500 # Ignition device connection "ModbusPLC" (Modbus driver) modbusPlcConnection: type: Cybus::Connection properties: protocol: Modbus targetState: connected connection: host: !ref modbusHost port: 502 # Tag "MotorSpeed": [S7-1500_Line1]DB10,INT4, Int2, tag group Fast500ms motorSpeed: type: Cybus::Endpoint properties: protocol: S7 connection: !ref s7Line1Connection subscribe: address: DB10,INT4 # Tag "FillLevel": [ModbusPLC]HRF20, Float4, default tag group (1000 ms) fillLevel: type: Cybus::Endpoint properties: protocol: Modbus connection: !ref modbusPlcConnection subscribe: fc: 3 address: 19 length: 2 dataType: floatBE interval: 1000 # Tag "RunningFlag": [ModbusPLC]C5, Boolean, default tag group (1000 ms) runningFlag: type: Cybus::Endpoint properties: protocol: Modbus connection: !ref modbusPlcConnection subscribe: fc: 1 address: 4 length: 1 dataType: boolean interval: 1000 mapping: type: Cybus::Mapping properties: mappings: - subscribe: endpoint: !ref motorSpeed publish: topic: !sub '${MQTT_TOPIC_PREFIX}/motor-speed' - subscribe: endpoint: !ref fillLevel publish: topic: !sub '${MQTT_TOPIC_PREFIX}/fill-level' - subscribe: endpoint: !ref runningFlag publish: topic: !sub '${MQTT_TOPIC_PREFIX}/running-flag' ``` {% endcode %} For all S7 and Modbus connection and endpoint properties, see [S7 Connection Properties](/2-4-2/connectors/shop-floor-connectors/siemens-simatic-s7/s7connection.md), [S7 Endpoint Properties](/2-4-2/connectors/shop-floor-connectors/siemens-simatic-s7/s7endpoint.md), [Modbus Connection Properties](/2-4-2/connectors/shop-floor-connectors/modbus-tcp/modbusconnection.md), and [Modbus Endpoint Properties](/2-4-2/connectors/shop-floor-connectors/modbus-tcp/modbusendpoint.md). {% hint style="info" %} Disclaimer: Ignition and Ignition Edge are registered trademarks of Inductive Automation, LLC. Cybus is not affiliated with or endorsed by Inductive Automation. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cybus.io/2-4-2/guides/migration/migrating-from-ignition.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.