How the importers work
The Talend, Informatica and SSIS importers read an export from the source tool and write Apache Hop
pipelines (.hpl), workflows (.hwf) and metadata, plus a migration report that lists what
needs a person. This page explains the ideas they share, so you know what a converted pipeline and
a line in the report do and do not mean.
Rules, not a language model
Each importer is a set of converters, one per source component, written and tested by hand. A converter reads the component's settings and writes the Hop transform or action that does the same job. By default, nothing is generated by a language model, and nothing is sampled.
That gives three properties a migration can rely on:
- The same input gives the same output. The Talend importer's golden-file test imports every fixture twice and fails if one byte differs. Re-running an import after fixing a source job changes only what the fix touched, so the diff is reviewable.
- A wrong conversion is a bug with a test, not a draft to re-roll. When a converter gets something wrong, it is fixed once, for every job that uses that component.
- What the importer cannot convert, it says. It does not invent a plausible-looking pipeline for a component it does not understand.
Where translation is hard, the importers translate the parts they recognise and mark the rest:
Talend tJavaRow code is translated idiom by idiom, an Informatica expression becomes a Hop Formula only
where the Formula computes exactly what PowerCenter does, and Java with PowerCenter's rules
otherwise, with the original expression above each line, and an SSIS expression becomes Java with
SSIS's rules.
The one exception is optional and says so: the SSIS importer can ask a language model to translate a Script Component's C#, when you turn that on. Such a translation is compiled and checked, always flagged for review, and only a first draft; see Translate Script Components.
Statuses in the report
Every source component gets one status in the migration report.
| Status | Meaning |
|---|---|
| AUTO | A converter carried the component's settings across. |
| PARTIAL | Converted, but a known part of the behaviour is not. Always flagged for review. |
| MANUAL | The converter fell back to a placeholder with a TODO, or left part of the component for a person: embedded Java that was not translated, for example, kept as comments to port by hand. |
| UNSUPPORTED | No converter, or the converter failed. The component is a placeholder. |
Independently of the status, a component can be flagged for review, with the reason in the
report. tJava, tJavaRow and tJavaFlex always are, even when their code was translated completely
and they count as AUTO.
AUTO is a statement about what the importer did, not a guarantee that the Hop pipeline produces the same rows. Prove that with a parallel run before you switch over.
Placeholders keep the shape
A component the importer cannot convert becomes a placeholder: a Dummy transform with the component's name and its hops, and the reason in its description. The pipeline keeps the shape of the original job, so you can see where the gap is and fill it in place, instead of discovering later that a step went missing.
The Informatica report goes one step further and checks each generated pipeline as a whole: a pipeline with a placeholder on the data path is reported as non-functional as converted, even when every other transformation in it converted.
Why there is no conversion rate
The same importer gives very different results on different projects. On the public Talend corpus
used in Get started, most components convert automatically, because those
are teaching examples with almost no embedded Java. On a project that puts a tJava in every job,
far fewer do. Both are honest measurements of the same importer.
So we don't publish one percentage. Run the importer on your own export, and the report gives you your project's figures. See Assess a Talend project, Assess an Informatica export or Assess an SSIS project.
Each importer's overview page has a section on what we tested it on, and what that does and does not tell you about your project: Talend, Informatica and SSIS.
What the importers never carry across
- Passwords. Talend encrypts them with a key that is not in the export, so they cannot be read; the Informatica importer leaves credentials empty on purpose; SSIS does not keep them in the package in clear text, so the SSIS importer puts a variable in their place. You add them in Hop after the import.
- Schedules. Talend Administration Center plans, Informatica workflow schedules and SQL Server Agent jobs are not in the files the importers read.
- Anything outside the export. Files, databases and libraries the jobs use at run time have to exist where Hop runs.