Platform Migration
Ten Sites, One Naming Standard
A Fortune 200 renewable operator

The situation
A Fortune 200 renewable operator was moving ten solar sites off Wonderware and onto Ignition. On paper it was one migration. In practice it was ten, because each site had grown up on its own - its own tag names, its own screen layouts, its own quiet conventions. Nothing built for one site could be reused at the next, so every screen was effectively a custom job and the fleet had no common language to report against.
The defect
The problem was not Wonderware, and it was not Ignition. It was that a decade of independent site growth had left ten versions of the truth. The same measurement might be named three different ways across three sites, so a dashboard or report had to be rebuilt from scratch each time. Some sites had tags but no Ignition installed yet; a few had access issues that stalled hands-on work. Without a shared standard, those blockers would have stopped the whole program in its tracks.
What we engineered
- Defined one tag naming standard for the whole fleet, so the same measurement means the same thing at every site.
- Built a repeatable page set - Overview, Dashboard, Environmental, DC Health, Tracker - applied site by site instead of redrawn each time.
- Mapped each site's legacy tags onto the standard, removing the manual re-mapping that used to eat engineering hours.
- Sequenced the rollout so sites with access or install gaps never blocked progress everywhere else.
- Kept screens and conventions consistent, so operators moving between sites see one familiar system.
The result
The standard, not the migration, is what the operator kept. Screens and reports built once now travel across the fleet, and a new site joins by adopting the standard rather than inventing another dialect. Because the naming was decoupled from any single platform, work carried on in parallel even where sites were not ready. The migration was really the vehicle; a fleet that finally speaks one language was the deliverable.
Stack