If you built your Anaplan integrations more than a few years ago, you almost certainly have a folder of Anaplan Connect batch scripts and a Data Hub model doing the cleaning. That architecture still works. The question in 2026 is whether it is still the right answer, because Anaplan now offers three distinct integration tools and they are not interchangeable.
The three options in one paragraph each
Anaplan Data Orchestrator is Anaplan's managed data integration service. It provides prebuilt connectors to systems such as SAP, Salesforce, and Snowflake, plus file and database sources, and it handles transformation (joins, filters, mappings, aggregation) and scheduling outside of your planning models. It is configured in a browser, not in code, and it is the tool Anaplan positions as the modern replacement for the Data Hub pattern.
CloudWorks is the lighter-weight scheduling and connector service built into the platform. It runs Anaplan import and export actions on a schedule, moves files to and from cloud storage (Amazon S3, Azure Blob, Google BigQuery, and similar), and chains actions into integration flows. It does very little transformation; the data needs to arrive already shaped for the import.
Anaplan Connect is the Java command-line client. It runs on a server you manage, authenticates with a user or certificate, and calls the same import, export, and process actions through the Anaplan API. Anything you can script around it (SQL extraction, file manipulation, error handling, your enterprise scheduler) is fair game. It is the oldest tool, the most flexible, and the one that carries the most operational burden.
Underneath all three is the Anaplan REST API, which you can call directly from any integration platform you already own.
Decision matrix
| Question | Data Orchestrator | CloudWorks | Anaplan Connect / API |
|---|---|---|---|
| Sources | Prebuilt enterprise connectors, files, databases | Cloud storage buckets, Anaplan models | Anything you can reach from a server |
| Transformation | Built in (join, filter, map, aggregate) | Minimal | Whatever you script before the load |
| Scheduling | Built in | Built in | Your scheduler (cron, Control-M, Airflow) |
| Skill set | Anaplan admin / integration analyst | Anaplan admin | Developer with Java runtime and scripting |
| Infrastructure | None | None | A server or container you maintain |
| Cost | Licensed capability; confirm with your Anaplan account team | Included with the platform | Free client, but you pay for the server and the person |
| Error handling | Run logs and notifications in the service | Run history and notifications | Exit codes and whatever you build |
When the old Connect script is still the right answer
Connect is not legacy in the sense of deprecated. It is the right tool when:
- Your extraction is complex SQL against an on-premises database that no connector reaches, and your DBA team already owns that job.
- You need the load to run inside an existing enterprise batch window orchestrated by a tool like Control-M, with the Anaplan step just one dependency in a chain.
- You want certificate-based authentication and full control of retries and alerting.
- The integration is a single nightly file and it has run for three years without incident. Rewriting it buys you nothing.
A minimal Connect invocation looks like this. It uploads a file, runs an import, and exits non-zero on failure so your scheduler can react:
#!/bin/bash
# Load actuals into the FP&A model via Anaplan Connect
set -euo pipefail
./AnaplanClient.sh \
-service "https://api.anaplan.com/" \
-auth "https://auth.anaplan.com" \
-certificate "/etc/anaplan/integration.pem" \
-privatekey "/etc/anaplan/integration.key:${KEY_PASSPHRASE}" \
-workspace "8a81b0116c9f1d3e016ca02f9c8a0001" \
-model "2B5C1F7A9D3E4A0B8C6D7E1F2A3B4C5D" \
-file "GL Actuals.csv" \
-put "/data/outbound/gl_actuals_$(date +%Y%m%d).csv" \
-import "Load GL Actuals" \
-execute \
-output "/var/log/anaplan/gl_actuals_errors.txt"
If you would rather skip the Java client, the same three steps are plain REST calls. Authenticate, upload the file in chunks, start the import task, then poll the task until it completes:
# 1. Authenticate (basic auth; use a certificate in production)
TOKEN=$(curl -s -u "$ANAPLAN_USER:$ANAPLAN_PASSWORD" \
-X POST https://auth.anaplan.com/token/authenticate \
| jq -r '.tokenInfo.tokenValue')
BASE="https://api.anaplan.com/2/0/workspaces/$WS/models/$MODEL"
AUTH="Authorization: AnaplanAuthToken $TOKEN"
# 2. Upload the file (single chunk shown; chunk large files)
curl -s -H "$AUTH" -H "Content-Type: application/octet-stream" \
-X PUT "$BASE/files/$FILE_ID" --data-binary @gl_actuals.csv
# 3. Run the import and capture the task id
TASK=$(curl -s -H "$AUTH" -H "Content-Type: application/json" \
-X POST "$BASE/imports/$IMPORT_ID/tasks" \
-d '{"localeName":"en_US"}' | jq -r '.task.taskId')
# 4. Poll until the task finishes
until curl -s -H "$AUTH" "$BASE/imports/$IMPORT_ID/tasks/$TASK" \
| jq -e '.task.taskState == "COMPLETE"' > /dev/null; do sleep 10; done
When to move to Data Orchestrator
Move when the pain is in transformation and ownership rather than in scheduling. The usual symptoms:
- A Data Hub model that has grown to hundreds of modules of lookups and clean-up logic, maintained by model builders instead of a data team.
- Spoke models that each re-implement slightly different versions of the same mapping.
- Business users waiting on a developer every time a new source column is needed.
- Connect scripts nobody dares touch because the author left.
Data Orchestrator moves the mapping and cleaning into a governed, visual layer with its own run history, and it lets your planning models be planning models again.
When CloudWorks is enough
If your data already lands in S3, Azure Blob, or BigQuery in the right shape (because a data engineering team or warehouse produces it), CloudWorks is the simplest way to schedule the loads and exports. No server, no Java, no connector licensing, and an integration flow can chain several actions with notifications on failure. Its limitation is the lack of transformation; the moment you need to join two sources or restate a hierarchy, you have outgrown it.
Migration checklist: getting off the Data Hub
- Inventory every import into the hub and every export from it to a spoke. Record source, frequency, owner, and which transformations happen in between.
- Classify each transformation: pure mapping (Data Orchestrator), aggregation or filtering (Data Orchestrator or the warehouse), planning logic disguised as transformation (belongs in the spoke model).
- Decide the golden source for each hierarchy. The hub was often the de facto master data system; that responsibility has to go somewhere explicit.
- Rebuild one pipeline end to end in Data Orchestrator (or CloudWorks) in parallel with the existing load, and reconcile the spoke model cell-for-cell for two cycles.
- Cut over pipeline by pipeline, not all at once, and keep the old route available for one cycle as a rollback.
- Retire the hub only when no spoke depends on it. Archive the model rather than deleting it.
Our recommendation
For a new implementation in 2026: Data Orchestrator for enterprise sources, CloudWorks for cloud-storage hand-offs, and the REST API from your existing integration platform if you have a mature one. For an existing estate: keep what is stable, and migrate the pipelines that are costing you model-builder time. If you want a second opinion on which is which, our Anaplan Data Integration Services start with exactly that assessment.