"What would it take to get off Wonderware?" is a question we hear a lot — usually after a license renewal, a server that won't move to a current OS, or a System Platform version that's reaching end of support. Migrating a working SCADA system is not a weekend project, but it's far more routine than most teams fear when it's planned as a phased parallel cutover rather than a big-bang replacement. Here's how we approach it.
What you're actually replacing
"Wonderware" (now AVEVA) is several products, and a migration touches each one: InTouch HMI screens, System Platform / Application Server (the Galaxy, ArchestrA objects and templates), Historian for time-series data, and often Alarm and reporting add-ons. Ignition covers the same ground with one platform — Vision or Perspective for visualization, the tag system and UDTs for the object model, the Tag Historian for history, and a built-in alarm pipeline — which is part of why the footprint usually shrinks.
The licensing difference is usually the driver
The biggest reason teams move is cost structure. Ignition is licensed per server with unlimited tags, clients and screens, where Wonderware's model scales with tag count and client seats. For a plant that's grown organically — more points, more terminals, a few extra dashboards — that difference compounds every renewal. The migration pays for itself faster than people expect, and it removes the reflex to not instrument something because of what the extra tags will cost.
Plan it as a parallel run, not a big bang
The single most important decision is to run the new system alongside the old one before cutting over. Ignition connects to the same PLCs over OPC UA without disturbing the existing Wonderware comms, so you can stand up the new gateway, mirror a line or an area, and let operators watch both in parallel until they trust the new screens. Then you cut over area by area. Nobody bets the whole plant on a single switch-flip.
Mapping the pieces
I/O & PLC comms — point Ignition's OPC UA server (or a dedicated OPC connection) at the same controllers. This is usually the lowest-risk part. Tag model — ArchestrA templates and instances map naturally onto Ignition UDTs and instances; this is where the design work concentrates, and where a clean model pays off for years. Graphics — InTouch windows are rebuilt, not auto-converted; we treat the migration as a chance to modernize layouts in Perspective (web/mobile) or Vision, reusing the proven content and dropping the cruft. Alarms — re-express alarm definitions on the tags, with priorities and notification pipelines. History — stand up Tag Historian for new data and, where it matters, migrate or keep the legacy Historian readable for the retention window.
Migrating historical data
You rarely need to migrate all of it. Decide what history actually gets queried — usually the last year or two, plus anything tied to compliance — and migrate that, while keeping the old Historian available read-only for the long tail. Trying to move a decade of raw history wholesale is effort spent where almost no one looks.
Phasing and risk
A typical sequence: build the gateway and tag model, mirror one non-critical area in parallel, validate data and alarms against the live Wonderware system, train operators on the new screens, cut that area over, then repeat. Keep the old system running until the last area is migrated and a full production cycle has passed. The risk lives in the tag model and alarm logic, not the comms — so that's where the validation effort goes.
Pitfalls to avoid
Lift-and-shift the old screens verbatim and you inherit twenty years of workarounds. Skip the parallel run and the first bad shift erodes trust permanently. Underestimate the tag-model work — that's the real project, not the graphics. And forget operator training; the people who lived in the old HMI need hands-on time before cutover, not after.
Where we come in
We plan and execute Wonderware-to-Ignition migrations for manufacturers and water utilities across California's Central Valley, and remotely nationwide — phased, parallel, and validated against your live system. If you're staring down a renewal or an end-of-support date, let's talk through your system, or read more about our Ignition integration services. Many of these projects also become the moment to add real OEE or remote monitoring that the old platform made too expensive.