Talend 7.3 Is Out of Support: Four Exit Paths, Costed Honestly

Last updated: August 2026

If Talend 7.3 still runs your production loads, this is no longer a roadmap conversation. Standard support for 7.3.1 ended on 30 November 2024. Everything since has been a paid extension, and per Qlik's product lifecycle page the last window you can buy runs through December 2026.

Nobody publishes what leaving costs. So: dated facts from primary sources, four exit paths with a decision rule each, our own observed effort bands, and the reconciliation protocol that decides whether you get to switch the old jobs off.

One thing up front, because it changes the maths. An active Talend subscription already entitles you to a current Talend 8 licence, which Qlik states in the official 7.3.1 end-of-support FAQ. We have seen teams buy extended support while that licence sat unused.

What expired, and when

Every date below comes from Qlik's own product lifecycle page and its 7.3.1 end-of-support FAQ, with one exception. Open Studio has no row in the commercial lifecycle table at all: the free edition was retired in January 2024, and a product with no contract behind it gets no lifecycle entry. That absence is the point.

The Open Studio row is the one people miss. Free-edition installs stopped receiving patches in January 2024, and no extended support covers them because there is no contract behind them. Talend 8 is the only supported version now, patched through monthly service releases.

What Limited Extended Support actually buys you

Per Qlik's FAQ, it lets you log a case when a severity 1 error happens and a product issue blocks your production environment. That is all of it.

• Severity 1 only. A job running 40% slower does not qualify. Nor does a connector silently truncating a field, unless production is down. You are buying an outage hotline, not maintenance.
• Third-party components excluded. Qlik states that issues requiring a fix in a no-longer-supported third-party component are not eligible for product fixes. Your real 7.3 risk is a CVE in a bundled library or JDBC driver, which is what this cannot fix.
• No maintenance, no new certifications. Nothing in an offering scoped to production-blocking severity 1 cases commits anyone to certifying 7.3.1 against a newer Oracle, JDK or OS. Upgrade the platform underneath and you are on your own. This is how an estate becomes frozen infrastructure.

The cost trap: extended support buys time and removes zero weeks from the migration. Each month you buy is a month of carrying two budgets.

Path 1: Upgrade to Talend 8 and Qlik Talend Cloud

Lowest risk if your jobs do ETL work that would be expensive to re-express. Qlik's migration and upgrade guide names only two exceptions: migrations from 7.1 or earlier require Qlik Professional Services, and projects from 4.1 or any previous version can no longer be migrated from Talend 8.0 onwards. 7.3 is in neither, so it is the normal supported case. It is not a patch, though: you install the 8.0 components, then upgrade the administration database, the Artifact Repository, JobServer, Log Server and Administration Center, and migrate the projects in Studio.

There is tooling. The Qlik Talend Cloud Migration Toolkit automatically scans and catalogues the customer-developed assets in an on-premises environment, maps asset types, usage patterns and interdependencies, then assesses technical compatibility with Qlik Talend Cloud and identifies gaps, risks and required transformations. Qlik lists Talend 7 to Talend 8 among its supported paths. Run it even if you are leaving: cheapest estate inventory going.

What agentic data engineering adds. Qlik took these to general availability on 30 June 2026. The headline is Declarative Pipelines: Qlik Talend Cloud pipelines designed and configured programmatically in YAML, natively integrated with GitHub, so peer review and promotion across environments become ordinary GitOps workflows instead of GUI job diffs. The legacy JSON format stays supported to the end of June 2027. Alongside it: the Data Product, Data Quality, and Catalog and Business Glossary agents, Talend Agentic Routes for LLM, RAG and event-driven agent calls inside data integration jobs, and the Qlik MCP Server, which exposes catalog, lineage, quality and data products as tools to any MCP-compatible assistant. The caveat: that YAML applies to cloud pipelines, not to Studio jobs, so an upgrade alone still leaves you with a GUI job model that does not diff in Git.

Pick this if you have 100+ jobs, heavy non-database connectivity, an ESB or MDM footprint, or a team whose only integration skill is Talend.

Path 2: Rebuild the transformation layer on dbt and Snowflake

The path we deliver most often, and the one most often mis-scoped, because dbt does not replace Talend. It replaces the transformation half. Something still has to land raw data, so scope ingestion separately or the estimate is wrong on day one.

dbt Projects on Snowflake reached general availability on 6 November 2025: create, edit, test and run dbt Core projects inside Snowflake, in a Snowsight workspace synced to Git, scheduled with tasks. The constraints matter:

• Concurrency. Multiple EXECUTE DBT PROJECT commands cannot run concurrently against the same project object, even with model selectors. Parallelising by domain means duplicate project objects.
• Serverless tasks cannot execute dbt project objects. User-managed warehouses only.
• Size limits. A project folder is capped at 20,000 files including logs; the DAG view shows up to 300 models.
• dbt Core and Fusion only. Snowflake supports dbt Core and dbt Fusion projects; dbt Cloud projects are not supported.

Pick this if Snowflake is already the target, most logic is tMap joins and aggregations, and your team writes SQL.

Path 3: Move to Azure Data Factory

The default when the organisation is Microsoft-committed and the decision is made above the data team.

• Two engines, not one. Copy activity moves data; mapping data flows transform it on a scaled-out Spark cluster ADF manages. Data flows follow an ELT approach and work with staging datasets that are all in Azure, over a far shorter connector list than the 90-plus Copy reaches. Anything else has to be loaded by Copy into a supported staging area first: one more hop than Talend needed.
• Self-hosted integration runtime. Anything on a private network reaches ADF through a SHIR you install, patch, scale and monitor. Your JobServer, same obligations.
• Parameters port cleanly. Context variables become pipeline and data flow parameters; the values are set by the calling pipeline through the Execute Data Flow activity.
• Cold clusters cost minutes. Microsoft's own recommendation is to give the Azure integration runtime a time to live so it holds a warm cluster instead of paying the several minutes of start time a cold one costs. Many small frequent jobs convert badly into many small frequent data flows. Consolidate before converting.

Pick this if the target is Azure SQL, Synapse or Fabric and whoever maintains the pipelines will not write SQL. Avoid it if your jobs are full of custom Java.

Path 4: Rebuild on an open-source stack

An ingestion tool plus dbt plus an orchestrator such as Airflow or Dagster. Attractive on the licence line, and right for some teams. The trade:

• Licence spend becomes headcount. Somebody owns the orchestrator, connectors, upgrades and on-call. Below two platform engineers, this becomes the stack you migrate away from in three years.
• It is a rewrite, not a conversion. Talend job definitions do not port. Every flow is re-expressed from the requirement: slower, but the only path that removes accumulated cruft.
• Connector coverage breaks first. Relational and file sources convert fine. The long tail (SAP, mainframe, EDI, an ancient SOAP endpoint) becomes bespoke Python nobody wants to own.

Pick this if the estate is under about 60 jobs and you already have engineers who run production software.

How long does a Talend migration actually take?

The number nobody publishes. These are CelestInfo's own observed ranges from migrations we have delivered, not an industry benchmark: elapsed weeks from kickoff to the old jobs being switched off, for a two to three person team with a part-time client SME. Add 4 to 6 weeks if you are also building the target platform.

Average components per job predicts effort better than job count: forty jobs at 80 components is harder than two hundred at 15. CDC is a separate project, not a modifier: capture, ordering, late-arriving updates and replay all get redesigned, which has never taken us under three weeks. And 30 to 40% of elapsed time is parallel run and sign-off, not build. Count the repository first: estates come in 20 to 30% larger than the team thinks.

The four things that blow the estimate

• Undocumented tJava, tJavaRow and custom routines. The biggest variance driver. Each is business logic nobody wrote down, authored by someone who has left. Reading it is not the hard part; deciding whether the behaviour was intentional is.
• Reject flows and restartability. Talend gives you row-level rejects, error connections and recovery checkpoints. dbt has no row-level reject, so per flow you must decide whether a bad row fails the run, is quarantined, or is dropped. Teams discover this three weeks in, after quoting.
• The CDC that is not in Talend. Capture is often configured source-side: triggers, a replication publication, log mining, a shadow table a DBA maintains. None of it is in the repository, so none is in your inventory, and it surfaces the week you cut over.
• Sign-off, not build. Business users validate when the deadline becomes real, which is after you thought you were done, and every mismatch costs a round trip through someone with a day job.

A fifth is a pure cost trap: parallel running means paying for both stacks, and a nightly batch run twice roughly doubles that Snowflake warehouse's credits. Nobody's budget until the invoice lands.

Component-level conversion: what maps to what

Not every Talend construct has a target; knowing which do is most of the estimate.

Everything a tMap does inside SQL's range converts cheaply; everything outside converts expensively or not at all. Triage: count the jobs containing a tJava-family component or custom routine call. Usually 5 to 15% of jobs, and 40% of the effort.

The parallel-run validation protocol nobody budgets for

You do not switch Talend off because the new pipeline runs. You switch it off when someone with authority signs a statement that the numbers match. Run both stacks against the same source data into separate schemas, reconciling into a results table on a schedule.

Level one is row counts and a content fingerprint per business date. HASH_AGG hashes an unordered set of rows, so row order does not matter, though column order does.

CREATE TABLE IF NOT EXISTS ops.migration_recon (
    run_ts        TIMESTAMP_NTZ,
    table_name    STRING,
    business_date DATE,
    legacy_rows   NUMBER,
    target_rows   NUMBER,
    legacy_hash   NUMBER,
    target_hash   NUMBER,
    rows_match    BOOLEAN,
    hash_match    BOOLEAN
);

INSERT INTO ops.migration_recon
WITH legacy AS (
    SELECT order_date                                             AS business_date,
           COUNT(*)                                               AS row_count,
           HASH_AGG(order_id, customer_id, ROUND(net_amount, 2))  AS content_hash
    FROM   legacy_talend.fact_orders
    WHERE  order_date >= DATEADD('day', -7, CURRENT_DATE())
    GROUP  BY order_date
),
target AS (
    SELECT order_date                                             AS business_date,
           COUNT(*)                                               AS row_count,
           HASH_AGG(order_id, customer_id, ROUND(net_amount, 2))  AS content_hash
    FROM   analytics.fact_orders
    WHERE  order_date >= DATEADD('day', -7, CURRENT_DATE())
    GROUP  BY order_date
)
SELECT CURRENT_TIMESTAMP()::TIMESTAMP_NTZ,
       'fact_orders',
       COALESCE(l.business_date, t.business_date),
       COALESCE(l.row_count, 0),
       COALESCE(t.row_count, 0),
       l.content_hash,
       t.content_hash,
       COALESCE(l.row_count, 0)     = COALESCE(t.row_count, 0),
       COALESCE(l.content_hash, -1) = COALESCE(t.content_hash, -1)
FROM            legacy l
FULL OUTER JOIN target t ON l.business_date = t.business_date;

Note the rounding inside the hash, where most first attempts fail: Talend computes in Java BigDecimal or double depending on the component, Snowflake uses its own NUMBER and FLOAT semantics, and two correct pipelines then disagree in the fifteenth decimal place.

Level two finds the rows: MINUS in both directions separates missing rows, extra rows, and the same key with different values.

WITH legacy AS (
    SELECT order_id, customer_id, ROUND(net_amount, 2) AS net_amount, status
    FROM   legacy_talend.fact_orders
    WHERE  order_date = DATE '2026-08-04'
),
target AS (
    SELECT order_id, customer_id, ROUND(net_amount, 2) AS net_amount, status
    FROM   analytics.fact_orders
    WHERE  order_date = DATE '2026-08-04'
)
SELECT 'legacy_only' AS side, d.*
FROM   (SELECT * FROM legacy MINUS SELECT * FROM target) d
UNION ALL
SELECT 'target_only' AS side, d.*
FROM   (SELECT * FROM target MINUS SELECT * FROM legacy) d
ORDER  BY order_id, side;

Level three gets you signed off: business users read report numbers.

WITH legacy AS (
    SELECT SUM(net_amount)             AS revenue,
           COUNT(DISTINCT customer_id) AS customers,
           COUNT(*)                    AS orders
    FROM   legacy_talend.fact_orders
    WHERE  order_date >= DATE_TRUNC('month', CURRENT_DATE())
),
target AS (
    SELECT SUM(net_amount)             AS revenue,
           COUNT(DISTINCT customer_id) AS customers,
           COUNT(*)                    AS orders
    FROM   analytics.fact_orders
    WHERE  order_date >= DATE_TRUNC('month', CURRENT_DATE())
),
diffs AS (
    SELECT 'revenue_mtd' AS metric, l.revenue AS legacy_value, t.revenue AS target_value
    FROM legacy l, target t
    UNION ALL
    SELECT 'customers_mtd', l.customers, t.customers FROM legacy l, target t
    UNION ALL
    SELECT 'orders_mtd',    l.orders,    t.orders    FROM legacy l, target t
)
SELECT metric,
       legacy_value,
       target_value,
       target_value - legacy_value                                     AS abs_diff,
       ROUND(DIV0(target_value - legacy_value, legacy_value) * 100, 4) AS pct_diff
FROM   diffs
WHERE  ABS(DIV0(target_value - legacy_value, legacy_value)) > 0.0001
ORDER  BY ABS(pct_diff) DESC;

Two rules separate a clean cutover from a three-week argument. Agree tolerances in writing before you start: zero for counts and keys, stated decimal places for money. And make the exit criterion consecutive clean days: seven in a row, including one month-end. A single green run proves nothing.

Pick a path: the decision rule

Four questions, in order. Stop at the first yes.

• ESB, MDM, or 100+ jobs with heavy non-database connectivity? Talend 8. Nothing else absorbs that surface area in a sensible timeline, and the licence is already yours.
• Snowflake already the warehouse, most logic joins, lookups and aggregations? dbt plus Snowflake, scoping ingestion separately from day one.
• Azure-committed, decision made above the data team? ADF, consolidating small frequent jobs before converting them.
• Under 60 jobs, database and API sources, engineers who run production software? Open-source stack. If you cannot answer yes to all three, pick one of the first three.

Whatever the answer, run the inventory this month. December 2026 is not a deadline for starting a migration. It is a deadline for finishing one, and a large estate needs most of a year.