Automated ETL Migration With Maia

From Exported Legacy ETL Jobs to Validated Pipelines

Your legacy ETL estate runs the business, but nobody fully remembers what every job does, and migrations stall on reverse-engineering logic long before the first pipeline gets rebuilt. Automated ETL migration converts exported legacy jobs into pipelines on your target platform, so engineers review the output instead of rewriting each job by hand. Maia's Migration Agent does this for 16 platforms, and in a proof of concept at St. James's Place it cut ETL migration effort by roughly two-thirds, turning days of work into hours. This guide covers what Migration Agent converts, how a conversion runs and how to check the result against your source. The feature is in public preview, and the Maia docs call it Convert workloads.

Why ETL migration is slow

Most of the time in an ETL migration goes to understanding the old job and proving the new one behaves the same, not to writing the new one. At St. James's Place, consolidating several ETL tools meant engineers translating existing jobs by hand, validating the logic and rebuilding each transformation, which often took days per pipeline.

Legacy estates make this worse. Balfour Beatty had 1,300 Informatica pipelines with logic buried in decade-old XML, and a senior engineer needed a full week to reverse-engineer a single one. With Maia, that analysis takes six minutes, and a multi-year migration became a six-month roadmap. Undocumented logic and security exposure are the usual reasons a legacy migration stalls, and each month of delay adds to the hidden costs of legacy ETL.

Migration Agent, part of Maia's AI Data Automation platform, takes on that Manual Data Work. It reads the exported job, describes what it does in plain language, and builds the equivalent Maia pipeline once you agree with the description. Your engineers spend their time on review and validation, where their knowledge of the business logic matters most. For the commercial side of the decision, read the real cost of legacy ETL migration.

What Migration Agent converts

Export your project files from the source platform and keep them in a Git repository or ready to upload. The table lists each supported platform with its vendor, category and accepted file types, whether SQL pass-through is available, and where to learn more.

Sixteen named platforms are supported. Apache NiFi, IBM DataStage, WhereScape and Oracle ODI were added in February 2026, and Ab Initio support is coming soon. If your platform isn't listed, choose Other, which accepts text-based formats even when the file extension is proprietary. If you're weighing a move off one of these tools, the comparisons for Informatica and Alteryx cover the platform decision.

Moving off Matillion ETL? Use the Upgrade Assistant instead. It retrieves your jobs through the Matillion ETL APIs and recreates them as Maia pipelines. It's a separate feature, built only for Matillion ETL customers converting their own workloads.

Maia projects run on Snowflake, Databricks, Amazon Redshift and Google BigQuery. Each project connects to your data warehouse through an environment, and converted pipelines are built in that project.

How automated ETL migration runs in Maia

1. Prepare your files. Export the workload and remove passwords, secrets and other sensitive information first. Source files are processed by an LLM service that doesn't use customer data for model training. Git repository files are the recommended method, with each file up to 10 MB. Uploading suits small workloads: up to 10 files at a time, 20 MB combined.
2. Start the conversion. In your Maia project, open Files, select Add, then Convert workloads. Choose the workload type and load your files.
3. Add guidance (optional). Edit conversions/user-guidance.md with naming conventions, schema mapping rules and design standards. Maia reads it every time it builds converted pipelines on your branch.
4. Let Maia analyze. Maia preprocesses the files to remove noise, analyzes the workload, runs a self-review pass over its analysis and reports progress as it goes. It writes a natural-language analysis to the conversions folder in your project.
5. Review the analysis. Look for logic that's missing, constructs that were misread, and table or schema names that don't match your workload. The key references section is the quickest check on names. If a schema isn't captured there, Maia had no way to know about it when it built your pipelines.
6. Plan, then build. Choose Plan conversion with Maia to review the approach and request changes before any pipeline exists. Skip planning only once similar workloads are consistently coming out the way you want.

Steering results with conversion guidance

Maia's output is non-deterministic, so the same workload can produce different pipelines on different runs. The guidance file is how you bring that under control. When a run goes wrong, identify what went wrong (naming, logic, structure or component choice), add one targeted instruction, run again and compare. Repeat until the result is consistent across several runs.

Specific instructions work better than broad ones. "All source tables are in the raw schema. Use staging as the target schema for every converted pipeline" gives Maia far more to work with than "use the correct schema names." On your first conversion the file doesn't exist yet. Leave it empty, review what Maia produces, then add instructions as you spot patterns.

For IBM DataStage, Informatica IDMC, Informatica PowerCenter and Other, SQL pass-through (under Advanced options) passes the exact SQL from your source files to Maia. Maia doesn't reproduce it verbatim by default, so add an explicit instruction to the guidance file if you need that.

Validating the output before you cut over

Don't cut over on trust. Load the output from your source workload into the same warehouse as the Maia output, in a different schema. Fixed input data makes side-by-side comparison easier. Then build a transformation pipeline that loads both outputs with Table Input and compares them with Detect Changes, Assert View or Aggregate. You can also ask Maia to compare the two tables and review the results. Validating by hand without loading the source output works too, but it takes more effort.

What to expect from a public preview feature

Support has grown since launch. In September 2026, Maia added preprocessing that removes noise from workloads, with the cleaned version written to your branch for debugging, a self-review step that double-checks its analysis, and detailed progress reporting. Output varies between runs and the feature is in preview, so treat every converted pipeline as a first draft and have an engineer review it before it goes near production.

Check each converted pipeline against your source output before you cut over, using the validation steps above.

See Migration Agent in action

Maia has published walkthroughs of real conversions, including:

• Converting Informatica Pipelines with Maia: a full PowerCenter pipeline converted in under seven minutes, with automatic connection mapping and a conversion summary
• Converting Alteryx Pipelines with Maia: migrating Alteryx to Snowflake
• dbt/SQL to DPL conversion with Maia
• 100 Informatica workloads in 30 minutes (webinar): a backlog of real PowerCenter pipelines converted on screen

Related reading: The real cost of legacy ETL migration isn't the licence fee.

Try it on your own workloads

Book a Migration Agent demo and bring a workload from your legacy estate.