Resources / Comparison
Ignition vs. Wonderware: what a migration really involves
If you're mid-decision on a Wonderware to Ignition migration, here's a straight comparison - and an honest look at what breaks, so you can plan around it instead of discovering it live.
Feature & licensing comparison
| Dimension | Ignition (Inductive Automation) | Wonderware (AVEVA) |
|---|---|---|
| Licensing model | Unlimited-tag, server-based licensing (per server, not per tag or client) | Tiered per-tag / per-client licensing that scales cost with the system |
| Clients & access | Web-deployed clients (Perspective) plus native (Vision); no per-seat client fees | Licensed clients; web access depends on product tier and version |
| Platform | Cross-platform (Windows, Linux, containers), modular architecture | Primarily Windows-based stack (System Platform / InTouch) |
| Protocols | Native OPC-UA, MQTT/Sparkplug, Modbus, DNP3 and many drivers | OPC and native I/O servers; MQTT typically via add-ons |
| Historian | Built-in tag historian to SQL databases; pairs with Canary/PI | Wonderware Historian (AVEVA Historian) - mature, separately licensed |
| Extensibility | Python (Jython) scripting, SDK, module ecosystem | Scripting + ArchestrA object model / Application Server |
Both are capable platforms. The right choice depends on your licensing math, existing investment, and where you want to be in five years. We deliver either - this page reflects what we see in real migrations, not a vendor pitch.
What actually breaks in a migration
Tag database & naming
Legacy tag names rarely map 1:1. Duplicate, ambiguous, or vendor-specific tags need auditing and standardization before they become Ignition UDTs - this is where migrations quietly overrun.
Historian continuity
You need a plan for historical data: run old and new historians in parallel, backfill, or bridge. Losing trend continuity across the cutover is a common, avoidable mistake.
Alarms & notification
Alarm definitions, priorities, shelving, and notification pipelines don't port automatically. They must be re-modeled and re-tested against the same conditions.
Redundancy & failover
Redundancy topology differs between platforms. Gateway redundancy, store-and-forward, and network segmentation all need validation under fault conditions, not just on the bench.
Graphics & UX
InTouch/System Platform graphics are re-built in Vision or Perspective. This is an opportunity to consolidate screens - but it is real engineering effort, not a converter.
A realistic phased timeline
For a multi-site fleet, a big-bang cutover is the riskiest path. We phase migrations so production is never betting on an untested system.
Assessment & tag audit
Inventory tags, screens, alarms, historian scope, and redundancy. Standardize naming. Produce a phased plan and risk register.
Pilot on one line or site
Migrate a bounded scope, run in parallel with the legacy system, and validate data, alarms, and failover before touching the fleet.
Phased fleet rollout
Roll site-by-site with historian bridging so trends stay continuous. Each site is verified before the next begins.
Cutover & handoff
Decommission legacy on a schedule, deliver documentation, and hand a system your team owns end to end.
Planning a migration?
Book a free assessment and we'll map your tags, historian, and alarms into a phased plan with a realistic timeline.