THE ENGINE — v2.2
Seven stages. 157 checks. One certificate you can verify yourself.
Most conversion tools output files and wish you luck. ScadaPort treats a migration as an engineering deliverable: every object accounted for, every alarm re-tested, every file hashed. Here is exactly what happens between the project you send and the project you receive.
- 91 tags
- 10 alarms
- 4 screens
- 158 graphic components
- 157 verifications
- 0 non-equivalent
Figures from the reference run: Movicon.NExT → Ignition
01 — THE PIPELINE
From project file to signed delivery, in seven stages.
1 · INGEST
Reads the source project in its native form
The engine opens the project exactly as the platform stores it — .movprj and its resources, the .UFProject folder, an Ignition project export. Nothing is retyped, nothing is approximated from screenshots or documentation. If a project file is incomplete or a resource is missing, it is reported before anything else runs.
Stages 1-4 produce the project. Stages 5-7 produce the evidence. Both ship with every conversion.
02 — COVERAGE, OBJECT BY OBJECT
What is converted, and how each object is verified.
| Object | What the engine does | How it's verified |
|---|---|---|
| Tags & UDTs | Converted with data type, scaling, address and UDT structure preserved | Structurally matched one-to-one against the source (147/147 on the reference run) |
| Alarms | Converted with thresholds, priorities and activation delays | Seven-point threshold sweep per alarm; must trip identically on both platforms |
| Screens | Rebuilt on the target with layout and component hierarchy | Rendered to HTML previews for visual review before installing the target platform |
| Graphic components | Converted where a direct equivalent exists; substituted and individually listed where not | Every substitution named with its screen in the report (55 on the reference run) |
| Bindings | Reconnected to the converted tag namespace | Matched against source bindings as part of the 157 checks |
| Scripts | Translated where the target supports the language; copied verbatim and flagged where not | Flagged items appear under 'manual action required' before you pay |
| Device connections | Documented with protocol, address and description for recreation in the target driver layer | Listed in the report; the engine never writes to a live control system |
| Historian | Configuration converted (retention, deadband) plus a data export | Settings restated in the report for confirmation |
| Trends, recipes, schedules | Converted and mapped one-to-one | Counted and listed in the report |
| Users & roles | Usernames and roles carried over — credentials never migrated | Explicitly reported as requiring re-provisioning |
Coverage figures come from verified conversion runs, not estimates. Your project's exact numbers arrive with the free scan.
03 — HOW THE ALARM SWEEP WORKS
Why we don't just compare configuration files.
Two alarm configurations can look identical in a diff and behave differently — a delay interpreted in different units, a comparison that is inclusive on one platform and exclusive on the other, a deadband applied before instead of after. So the engine doesn't compare settings. It simulates behaviour: for every alarm it drives the source value through seven points around the threshold — well below, just below, exactly at, just above, well above, and back down through the reset band — and requires the alarm state to match on both platforms at every point. An alarm that disagrees at even one point is reported as non-equivalent, with the point at which it diverged.
04 — THE SHADOW FILE
What the destination cannot hold, the shadow keeps.
Every platform can express things the others cannot. Convert without accounting for that and the difference is simply lost — which is why SCADA migrations are treated as one-way doors. Alongside every conversion the engine writes a shadow file containing, byte for byte, everything the destination format cannot represent: animation types, bindings, scripts in their original language, recipes, schedules. Convert back and it is restored. On a verified round-trip: 24 tags, 19 bindings, 2 animations, 7 original-language scripts, 1 recipe and 1 schedule came back intact after passing through a format that could not hold them.
A reversible migration is a migration you can actually decide to make.
05 — ANATOMY OF THE CERTIFICATE
The artifact that outlives the migration.
In regulated plants a migration has to be justified, sometimes years later. The certificate is the artifact that does that: it names the engine version, the direction, the score, and the SHA-256 of the source file and of every generated file. Reproduce the hashes and you have proved the delivery is the one that was verified.
equivalence_certificate.sccert.json
- certificate_id
- 1877c6cd2a234fb6
- engine
- 2.2.0
- project
- Demo_Estrusore
- direction
- movicon_next → ignition
- score
- 100.0% (157 verified · 0 failed)
- alarms
- 10/10 seven-point sweep
- structure
- 147/147
- source sha256
- bdb5aaa1…2da4116
- issued
- 2026-08-05
- formats
- .sccert.json + .html
06 — ENGINE SPECIFICATIONS
Specifications.
Runtime
C# / .NET, runs on Windows
Network
Fully offline. The engine reads project files; it never connects to a PLC, a gateway or a running control system.
Data handling
Source projects processed under NDA and deleted after delivery. Credentials in source projects are never read into the output.
Delivery
Converted project + conversion report + equivalence report + signed certificate + security report + SBOM + HTML screen previews + shadow file
Reports
Available in English and Italian
Licensing
Offline licensing, no phone-home, no subscription server
Extensibility
Parser architecture is modular: new platforms are added against a stable internal model
Versioning
Every delivery records the exact engine version that produced it
07 — WHAT THE ENGINE WON'T DO
The limits, stated plainly.
- It does not claim 100% automation. On the reference project 2 items required manual action and 55 objects were substituted and listed — before the customer paid.
- It does not touch a running plant. Device connections are documented for recreation; nothing is written to live equipment.
- It does not guess at scripts it cannot translate. Unsupported languages are copied verbatim and flagged.
- It does not replace commissioning. The converted project still has to be tested and signed off on the real system — by you, or by us as a service.
- It does not migrate credentials. Users and roles come across; passwords do not, by design.
Every one of these is in the report you receive before you commit. That is the point.
08 — TECHNICAL FAQ
Technical questions.
What exactly do I send you?+
.movprj plus its resource folder (Movicon 11), the .UFProject folder (Movicon.NExT), or a gateway project export (Ignition). The free scan tells you if anything is missing.
How big a project can it handle?+
The reference runs are mid-size supervision applications. Larger projects are quoted after the scan, which reports the real object count.
Can I see the result before installing the target platform?+
Yes: every converted screen is rendered as a static HTML preview you open in a browser.
What happens to objects with no equivalent on the target?+
They are substituted with the closest supported construct and listed individually, with object name and screen.
Can I go back after converting?+
Yes, that is what the shadow file is for.
Does anything leave my network?+
The engine runs offline. Project files are exchanged for the service under NDA and deleted after delivery.
How do I know the delivery I got is the one that was verified?+
Reproduce the SHA-256 hashes listed in the certificate.
Is the engine updated?+
Every delivery records the engine version that produced it, so a result is always reproducible against a known version.