Hi All,
I want to convert my Vision project into a Perspective project. Does anyone know the best way to do this? Is there a tool or recommended process for converting a Vision project to Perspective?
The systems are so different, that I wouldn't trust it being done automatically.
There's a lot you can keep, like tags, UDTs, scripts, but not screens.
Personally, I would keep the old and new project side to side, and try to recreate screens and functionality that way. It might help to create styles for repeated screens/objects beforehand, so you only have to configure them once.
Good luck
I think one of the biggest shifts is the styling. It's bit of a double edged sword. On one hand, it makes standardising styling across the project really nice. On the downside, it means you have to first define that style library which can be time consuming upfront. This is a major difference between Vision and Perspective though, and one that puts Perspective miles ahead of Vision at the end of the day.
I second @JVDM in that, even if there was a tool that could recreate your Vision graphics in Perspective (there isn't one that I know of), I also wouldn't trust it to create something worth keeping. It would be like automatically converting a logix 500 project to 5000. It might technically work, but its output would be extremely gross
@alexmarcy has a tool that does this conversion.
I have a vague memory of a LinkedIn post where he was maybe trying to sell ownership of the tool? Not sure if I'm imagining this.
Anyway, the tool doesn't seem to be publicly available, so if Corso still does these migration projects the tool is probably some private advantage they have.
Last time I tried to find any info on this after seeing it possibly at ICC one year, it was like trying to find a needle in space... and that was a year or 2 ago
I was chatting to him at ICC last year about it, I’m not sure if it’s changed since then.
I officially sold to tool too Vertech so you can reach out to them if you want to go that route before September 2027 when we can use the code again.
The overall gist of how it works is we took XML exports of the Vision windows/templates (either go into the designer, right click and export to XML, or we still have an open source tool that will handle that for you) then we wrote some python scripts that basically did a find/replace along with some regular expressions to convert the vision component specifics like the structure, properties, bindings, etc. into their Perspective equivalents. This output the relevant JSON files and we dumped them into the appropriate folder structure in the file system, then did a gateway/project refresh to bring them into the designer.
The XML aspect was the "secret sauce" and the limiting factor on what platforms we supported. WinCC and ClearSCADA did not have an easy way to get a human readable file so we didn't support those, although it seemed like ClearSCADA had a ton of Australian deployments so would have been beneficial to have that. Worked super easily with all of the other major brands although InTouch had a few hoops to jump through to get the windows into a human readable format.
This approach doesn't work with things that don't exist in Perspective like momentary buttons so you may or may not have some additional manual work you need to do on the Perspective side based on what components you are using. Short of any third party modules I don't think there was anything except momentary buttons in Vision that caused an issue. The biggest hurdle we ran into was the Tamaki replay module on one project. Had to do some trickery with custom properties to minimize the number of queries for historical data otherwise the performance would grind to a halt.
The other limiting factor, mostly due to ease of deployment, was it only supported coordinate containers for the main views. 99% of our projects were converting other SCADA platforms to Ignition and those didn't support responsive design to begin with and adding in breakpoint containers, flex containers, etc. would have made life a lot more difficult. This also applies to Vision where we would effectively make a 1:1 copy of the window, just in Perspective.
You also need to adjust scripts to reference the correct component paths since those are different in Vision vs. Perspective. event.source.parent.getComponent("Component") vs. self.parent("Component") for example, as well as to map custom properties to either View properties or custom properties in Perspective.
You might also run into issues if you are using Symbol Factory graphics, in that case we replicated something similar using SVGs in Perspective. Also image paths in the image manager will be slightly different in Perspective compared to Vision so you'd need to account for that in the migration code.
The other issue we ran into performance wise was nested templates. In Perspective you can quickly grind things to a halt if you have multiple levels of template nesting so we had a couple projects where we had to go in and do some manual consolidation to reduce nesting and update bindings accordingly.
If a project wasn't using templates and had 400 copies of a popup or something like a button that was copy/pasted we'd usually write some custom code to pull that into a template, although the tool wasn't set up to automatically generate templates without some guidance/custom code if templates didn't already exist.
You can get deeper into the weeds using styles no problem, you just need to add style bindings into the python scripting to map thing appropriately during the migration.
The nice thing about Vision to Perspective was all the tags already existed so it saved a lot of validation compared to a legacy SCADA system where we also had to do tag conversion and UDT setup.
I'd have to ask the folks who got deep into the weeds on the Vision migrations, I think overall we just developed alarm and trend windows by hand because that was faster than parsing through everything on the legacy side so we didn't write an automated tool for that.
The initial version of everything was built prior to ChatGPT existing, so we did it mostly by hand, would be a relatively simple operation to do with LLMs in their current state.
As I recall, doing the initial Vision to Perspective proof of concept with buttons, text fields, images, and converting some of the graphics like tanks to use the Perspective Symbols along with tag bindings on everything only took me less than half a day of effort. It wasn't necessarily production ready, just enough to prove it was possible.
I joked along the way the hardest part of the whole endeavor was being naive enough to take on the challenge, doing the actual code to convert XML to JSON was relatively straightforward, just time consuming to cover all the various component types. We also had a tool that would parse through the existing windows and flag anything we hadn't converted before so we could add that into the mix before running it 100%.
Happy to answer any questions and/or direct you to the people on my team who fleshed out the overall codebase, just can't share the tool or any direct code examples, although you can reach out to Vertech. I don't know if they have made any improvements or have done much on the Vision side, they were more focused on the iFix capabilities initially.
Is there currently any tool other than vertech, available to convert a Vision project to a Perspective project?
ClearSCADA has an automation interface in the shape of a COM interface that I used to use to build graphics via code. I'm pretty sure it supported reading graphics as well, but to what extent i'm not sure. You needed to have the "designer" (ViewX) open in order to actually use it though. I believe the source of the mimics is all stored in the internal ClearSCADA (or whatever they call it now... "EcoStruxure Geo SCADA Expert Global Operations Suite Pro Ultimate Infrastructure Architect Max Mission-Critical Deployment Tier" - maybe it's not that name yet, but give "them" time!!) database. Not actually sure what format that is in as I used to access it via another COM interface.
I guess my whole issue or concern with using automated tools is that it may replicate a majority of it 1:1, but if a customer wants to move to Ignition I would rather not replicate what they had and do things instead with flex containers where I can, style libraries, etc to optimize everything and do it properly. There's so many times I've come across projects that have been modified so much by so many people that it would be better and faster to just redo the entire project from scratch. The whole garbage in, garbage out thing.
Same goes for even Vision where it would be easier, but you've got capabilities in Perspective that you don't have in Vision or other software that would benefit from a rework rather than a conversion.
I feel like the rework after the conversion may take as much time as just building it by hand would.
But, with AI, it may be able to do things the Ignition/Perspective way (I haven't tested this myself) without a direct conversion which would be more beneficial.
Not to my knowledge.
Only about 1% of the inquiries we ever received for conversions were for Vision to Perspective conversions and I would imagine we received the most inquiries of anyone. That said I don't think there is a huge market for such a tool and the main reason I had my team build it was for marketing purposes.
If there was a big market for it I could see Inductive building something to handle conversions, and if they ever phase out Vision entirely they might do that, until then sadly I think you're mostly on your own.
We did not receive enough inquiries to dig that deep 
The other issue was although the cost was generally less than a completely manual conversion, there was usually sticker shock for legacy platforms without a huge license cost attached and most of the folks we talked to using ClearSCADA didn't have the budget for it. The cost of converting a project and turning the files over to the customer as-is was minimal since it usually took longer to get the files into the right format than it took to actually convert them. The main cost was all the validation that had to be done since there wasn't an easy way to automate that with production systems.
Completely agreed.
The main driver for nearly every conversion we did was to move away from ever increasing licensing costs of the legacy platforms.
Especially with what amounted to private equity taking over Wonderware and raising licensing costs the cost of the conversion plus Ignition licensing was often cheaper than extending their support contracts. The usual goal was "get us off the other platform so we don't need to renew our license, then we'll improve it later if needed."
Most of the conversions were for systems they had been using for 10+ years with no major changes along the way so they weren't focused on improvements as much as ongoing costs as painful as that was from a "do things the right way" perspective.
I don't think we're too far away from a generation of AI-assisted conversion tools that don't need to understand the source file formats, and instead operate on an inventory of screenshots/images of every screen and dialog, with optional specification/text to accompany each. Or even an "operator manual" as source if those still exist and get updated.
Had a customer once that essentially paid 2x for a conversion. First time was a Wonderware upgrade that a large integrator did to the latest version but they thought they were getting a reworked and improved system, but turns out they just upgraded the version for them. (Not sure what their proposal said since we weren't involved), second time they came to us and we converted it to Ignition but completely reworked it and the PLC logic because it was all a mess. (Their old InTouch screens were horrible with so many visibility animations it was a mess to decode it all)
I used to love this in Citect SCADA. There was one popup I remember for a sequence that had about 35 groups all stacked on top of each other with visibility expressions. Of course, in the "designer" which isn't a "live" environment, all of the 35 groups were all visible, so really only the top one could be seen properly, but each had different elements so you could see parts of the groups behind. It was a lot of fun to work with.
Now that I think about it, "love" and "fun" might be the wrong choice of words...