ETL Advisors | Retiring TAC: A Migration Runbook from Talend Administration Center to Talend Management Console

Most Talend estates we are called into in 2026 have already dealt with Open Studio going away and MDM Server's end of life. The piece still humming along in a datacenter is the control plane: Talend Administration Center (TAC) with a pool of JobServers, running execution plans that nobody has touched since the person who built them left.

Under Qlik, the forward path for orchestration is Talend Management Console (TMC) plus Remote Engines running in your own network. This is the runbook we use. It is deliberately inventory-first: the migrations that go badly are the ones that start by clicking around in the new UI.

0. What actually moves, and what does not

There is no "import my TAC" button. Treat the migration as a rebuild of the control plane against the same job code.

TAC concept	TMC equivalent	Moves automatically?
Projects / SVN or Git repos	Same Git repos, connected to Studio	Code yes, config no
Job Conductor task	Task in a Workspace	No — recreate
Execution plan	Plan (sequential/parallel flows)	No — recreate
Trigger (CRON / file / JMS)	Schedule trigger, or external API call	Partly — CRON only
JobServer	Remote Engine	No — new install
Context groups / TAC context params	Task parameters, Resources, Engine env vars	No — re-enter
Users / roles	Qlik Cloud tenant users and roles	No — re-map
Audit / logs (AMC tables)	TMC execution log + your own logging	No — keep the old DB read-only

1. Inventory the TAC database before you touch anything

Everything you need is in the TAC repository schema. Pull it into a spreadsheet, because this list becomes your migration backlog and your test plan.

-- Job Conductor tasks, their job, version, context and JobServer
SELECT  t.label            AS task_name,
        t.job_name,
        t.job_version,
        t.context_name,
        t.active,
        s.label            AS job_server
FROM    scheduler_task t
LEFT JOIN server s ON s.id = t.server_id
ORDER BY t.label;

Exact table names vary by TAC version — inspect the schema first — but you are after four lists:

Tasks: which job, which version, which context, which JobServer, active or not.
Triggers: CRON expressions (and their timezone), file triggers, and anything triggered externally.
Execution plans: the parent/child ordering and the "on error" branches.
Last run timestamps: your evidence of what is actually alive.

That last one is where the savings are. On a typical estate, 30–50% of tasks have not run successfully in a year. Do not migrate them. Produce a kill list, get one named business owner to sign it, and archive the definitions.

2. Get the code building from Git, not from the TAC repo

TMC runs artifacts, not workspaces. A task in TMC points at a versioned artifact in the Talend Cloud artifact repository, published from Studio or from CI.

If you are still on SVN, migrate to Git first — that is its own project and should not be bundled into the cutover weekend. Once the code is in Git, publish artifacts from a pipeline rather than from a developer laptop; our CI/CD walkthrough covers the Maven build, and the same mvn deploy step can push to the cloud repository:

mvn -s settings.xml clean deploy \
  -Dproduct.path="$STUDIO_HOME" \
  -Dlicense.path="$STUDIO_HOME/licenses/license" \
  -Dcloud.publisher.screenshot=false \
  -Dcloud.publisher.env.id="$TMC_ENV_ID" \
  -Dcloud.publisher.workspace.id="$TMC_WORKSPACE_ID" \
  -Dcloud.token="$TMC_TOKEN"

Rule we enforce on every engagement: an artifact that is not reproducible from a Git tag does not get promoted. TAC let people run a job version that existed only in someone's workspace. TMC should not inherit that habit.

3. Design environments and workspaces before you create tasks

TMC's hierarchy is Environment → Workspace → Task. Map it to how you actually promote:

Environments: DEV, TEST, PROD. One Remote Engine (or engine cluster) bound per environment. Never let a DEV engine reach a PROD database — the engine is where network access is decided.
Workspaces: split by team or data domain, not by technology. Workspace permissions are your blast radius.
Naming: domain_source_target_frequency, e.g. finance_sap_snowflake_daily. TAC names full of ticket numbers age badly; fix that now, while you are retyping everything anyway.

4. Install and size Remote Engines

A Remote Engine is the JobServer replacement: it sits in your network, polls TMC outbound over HTTPS (no inbound firewall rule), pulls the artifact, and runs it. Points people get wrong:

Outbound only. If your JobServers needed inbound 8000/8888 rules, those go away. You need egress to the Qlik Talend Cloud endpoints, which usually means a proxy entry rather than a new DMZ.
Parallel execution is licensed. A JobServer would happily run whatever you threw at it. A Remote Engine has a configured number of parallel executions; count the peak concurrent tasks from your TAC log before you size. Two medium engines behind an engine cluster beat one oversized box for patching.
JVM and drivers. The engine ships its own JRE; confirm the Java level your jobs need and see our Java 17 and 21 upgrade notes. Third-party JDBC drivers that you dropped into the JobServer lib folder must be re-installed on the engine or, better, resolved through the artifact.
Filesystem assumptions. Any job reading /data/inbound on a JobServer needs the same mount on the engine host — or, preferably, a move to object storage while you are here.

5. Rebuild schedules with intent

CRON expressions copy over, but two details bite:

Timezone. TAC triggers ran in the JobServer's OS timezone. TMC schedules carry an explicit timezone. Every DST-sensitive nightly job needs a decision, not a paste.
Chains disguised as clock times. A huge number of "schedules" are really dependencies — job B at 02:15 because job A usually finishes at 02:00. Rebuild those as a Plan with real ordering, or hand orchestration to Airflow/Dagster and call TMC's API. Chaining by wall clock is the single biggest source of 3 a.m. pages, and the cutover is your one free chance to fix it.

File triggers and JMS triggers have no direct TMC equivalent. Replace them with an event-driven call to the public API — a small watcher (cloud function, or an engine-side script) that POSTs an execution request:

curl -X POST "https://api.<region>.cloud.talend.com/processing/executions" \
  -H "Authorization: Bearer $TMC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"executable":"'"$TASK_ID"'","parameters":{"file_path":"/data/inbound/orders.csv"}}'

We covered that API in more depth in Automating Qlik Talend Cloud, including polling the execution status and wiring it into promotions.

6. Contexts and secrets

TAC context groups become task parameters and shared Resources. This is also the moment to stop shipping passwords inside Default.properties — see the multi-environment context pattern for the job-side setup.

Our preferred layout: non-secret values as TMC task parameters (visible, diffable), secrets resolved at run time on the engine from Vault, AWS Secrets Manager, or Azure Key Vault via a routine or an tContextLoad from a credentials service. Secrets then never exist in an artifact, in Git, or in a TMC screen.

7. Users, roles, and the audit story

TMC authentication lives in the Qlik Cloud tenant. Export the TAC user list with their roles, map each to a TMC role (and to SSO groups if you have SAML/OIDC), and use the migration to delete the accounts of people who left in 2019. Service accounts for CI need their own tokens with the narrowest workspace scope that works.

Keep the AMC/TAC database online but read-only for as long as your retention policy requires. Auditors ask for run history, and it does not come with you.

8. Cutover: run both, then turn one off

Do not big-bang. The pattern that has never burned us:

Shadow week. Rebuild a wave of tasks in TMC pointed at the same sources but writing to a parallel target schema. Run both. Compare row counts, checksums, and durations.
Read-only wave first. Extracts and reports move first; loads that mutate production tables move last.
Freeze in TAC. Deactivate each migrated trigger in TAC the moment its TMC twin is verified — never leave both writing. A disabled trigger is reversible; a double-load is not.
Watch durations. Engines are usually different hardware than the old JobServers. A job that took 20 minutes and now takes 55 is telling you something about memory or pushdown; see performance tuning.
Decommission on a date, in writing. TAC servers that stay up "just in case" get used, and six months later you are running two control planes.

Plan roughly one to two days of effort per 50 simple tasks for the rebuild, plus the shadow-run window, plus a fixed block for the 10% of jobs with file triggers, custom JobServer scripts, or hardcoded paths. That 10% is where the schedule actually goes.

A checklist you can paste into a ticket

If you are staring at a TAC instance with several hundred tasks and no documentation, that inventory step is the one worth getting help with — it is also the deliverable that tells you whether this is a six-week project or a six-month one. Our Qlik Talend Cloud consulting practice does exactly this assessment; get in touch if you want a second pair of eyes on the plan.