Table of Contents

Migrating from the TE2 Command Line

  • 2026-10-16
  • Peer Grønnerup
Applies to:
  • ❌ Tabular Editor 2
  • ❌ Tabular Editor 3
  • ✔ Tabular Editor CLI
Important

The Tabular Editor CLI is in Limited Public Preview. It is offered for evaluation with a Tabular Editor account; no license is required during preview. Commands, flags, and outputs may change before general availability. The preview build stops functioning after 2026-10-31. We recommend against using the CLI in production CI/CD pipelines during preview.

Teams with existing build pipelines that invoke TabularEditor.exe with TE2-style flags (-S, -A, -D, -O, -C, etc.) can adopt the new CLI incrementally. The Tabular Editor CLI accepts both command shapes: the new subcommand-based form (te deploy, te bpa run, …) and the legacy TE2 flag syntax, via a built-in compatibility layer.

For the legacy TE2 Windows command-line reference, see Command Line (Tabular Editor 2).

How TE2 compatibility works

TE2 compatibility mode is activated in any of three ways:

  1. Binary name. Rename te to te2 (or symlink it) and the CLI runs in TE2-exact mode. This is the drop-in replacement path: swap TabularEditor.exe for te2 in your existing pipeline and the same arguments work.
  2. Environment variable. Set TE_COMPAT=te2 before invoking te to force TE2 mode.
  3. Auto-detection. If the first argument isn't a te subcommand (deploy, validate, …) and at least one recognized TE2 flag appears somewhere in the argument list, the CLI auto-routes to TE2 mode. This means most existing TE2 invocations work without any changes.
# All three are equivalent - each runs in TE2 mode
./te2 Model.bim -S fix.csx -D "localhost\tabular" MyDB -O
TE_COMPAT=te2 te Model.bim -S fix.csx -D "localhost\tabular" MyDB -O
te Model.bim -S fix.csx -D "localhost\tabular" MyDB -O
Note

TE2 mode runs the same Load → Scripts → Schema Check → Save → BPA → Deploy → TRX pipeline as TabularEditor.exe, including context-sensitive flag behavior (e.g., -S after -D means -SHARED, not -SCRIPT).

The migrate command

Use te util migrate as a live reference for how TE2 flags map to the new CLI. It prints a colorized table of every known TE2 flag, its status (supported, renamed, planned), and the equivalent te command.

te util migrate                   # Full flag mapping table
te util migrate -A                # Look up a single flag
te util migrate --output-format json     # Machine-readable mapping

Refer to the output of the te util migrate command for the current mapping that reflects the CLI version you have installed.

Flag mapping (curated subset)

Below is a non-exhaustive summary of the most commonly used flags. Run te util migrate for the full list.

TE2 flag New CLI equivalent Notes
file (positional) --model <path> (global option) Always the global --model option; no command takes the model as a positional argument. Or set an active model once with te connect <path>.
server, database te connect <server> <database> or global -s <server> -d <database> -s/-d always identify the model source; deploy destinations use --target-server / --target-database.
-L / -LOCAL te connect --local Windows only.
-S / -SCRIPT te script --file <file.csx> or --inline "code" A bare .csx path also works (te script fix.csx). Supports multiple scripts (--file a.csx --file b.csx), inline code, and stdin (--inline -); files and inline code run in the order given.
-A / -ANALYZE te bpa run --rules <file-or-url> Supports --fail-on, --fix, multiple rule files.
-AX / -ANALYZEX te bpa run --rules <file> --no-model-rules Model-embedded rules are included by default; --no-model-rules excludes them, matching what -AX did.
-B / -BIM te save-as --model <model> -o <file.bim> --serialization bim
-F / -FOLDER te save-as --model <model> -o <dir> --serialization database.json After -D, TE2's -F means -FULL - see --deploy-full.
-TMDL te save-as --model <model> -o <dir> --serialization tmdl --serialization can be omitted - the format is inferred from the output path.
-D / -DEPLOY te deploy --model <model> --target-server <server> --target-database <database> --execute Separate command with named options. Without --execute, te deploy is a dry run that prints the TMSL it would send.
-O / -OVERWRITE (default) or --create-only to opt out Overwrite is the default in the new CLI.
-C / -CONNECTIONS te deploy --deploy-connections
-P / -PARTITIONS te deploy --deploy-partitions
-Y / -SKIPPOLICY te deploy --deploy-partitions --skip-refresh-policy Requires --deploy-partitions.
-SHARED te deploy --deploy-shared-expressions After -D, TE2's -S means -SHARED.
-R / -ROLES te deploy --deploy-roles
-M / -MEMBERS te deploy --deploy-role-members
-FULL (after -D) te deploy --deploy-full Equivalent to overwrite + connections + partitions + shared + roles + role-members.
-X / -XMLA <file> te deploy ... > <file> (omit --execute) Script emission is the default: without --execute, deploy connects read-only and prints the TMSL to stdout - redirect it to a file.
-V / -VSTS --ci vsts on validate, bpa run, schemacheck, deploy, test run Emits ##vso[...] annotations to stderr. azdo and azure-devops are accepted aliases.
-G / -GITHUB --ci github (alias gh) Emits ::error:: / ::warning:: / ::notice:: annotations.
-T / -TRX <file> --trx <file> on validate, bpa run, schemacheck, test run VSTEST .trx file for Azure DevOps test publishing. Each command writes its own file.
-W / -WARN (default) Warnings always reported in deploy results.
-E / -ERR (default) Deploy returns non-zero exit on DAX errors.
-SC / -SCHEMACHECK te schemacheck Same exit-code rule as TE2, and read-only like TE2. Checks more than TE2 did - see Schema check. Not the same as te validate, which checks DAX and does not connect to data sources.
-L / -LOGIN <user> <pass> (after -D) te auth login -u <id> -p <secret> -t <tenant> Use service principal or env-based credentials. The login is cached, so subsequent commands acquire tokens silently - see Authentication and Connections.

Migration playbook

The recommended path from a TE2-based pipeline to the new CLI:

  1. Drop-in replacement. Replace TabularEditor.exe with te (or te2) in your existing pipeline. Verify the pipeline still runs - TE2 compatibility handles most invocations unchanged.
  2. Replace flags incrementally. Convert one flag group at a time:
    • Start with -A / -AX → te bpa run to pick up richer BPA output (--fail-on, --fix, --trx).
    • Then -SC → te schemacheck for wider coverage (Power Query and Direct Lake tables) and JSON findings.
    • Then -D → te deploy for fine-grained deploy control.
    • Finally -V / -G → --ci vsts / --ci github.
  3. Switch to non-interactive CI flags. Add --non-interactive to every te command (and --ci <vsts|github> on validate, bpa run, schemacheck, deploy, and test run), pass --execute --force on deploy/refresh steps that must act, and remove any start /wait wrappers - the new CLI is a regular console binary and doesn't need them.
  4. Adopt service principal auth. Replace -D -L <user> <pass> with te auth login -u ... -p ... -t ... or an environment-credential pipeline step. See Authentication and Connections.

Important differences

  • BPA gate on deploy. te deploy now runs BPA as a pre-flight gate by default. Use --skip-bpa to preserve the old behavior, or --fix-bpa to auto-fix violations before deploy. See Custom Configuration.
  • Dry run by default. te deploy and te refresh print the exact TMSL they would send and change nothing; pass --execute to act. --execute asks for confirmation at a terminal (with n as the safe default); CI pipelines must pass --execute --force.
  • Structured output. Every command supports --output-format json for machine-readable output - see Automation and Scripting.
  • No start /wait needed. The new CLI is a regular console binary; invoke it directly in shell scripts, PowerShell, and CI tasks.
  • Cross-platform. The CLI runs on Windows, macOS, and Linux. Local SSAS and Power BI Desktop connections remain Windows-only.

Schema check

There are two ways to run TE2's schema check with the new CLI:

  • te2 <model> -SC keeps an existing pipeline behaving exactly as it did. It checks only what TE2 checked - legacy Query partitions bound to a provider data source - so a Power Query or Direct Lake table cannot change its result.
  • te schemacheck is the command for new pipelines. It also checks Power Query (M) partitions and entity-bound Direct Lake and Fabric tables, and supports --output-format json - see schemacheck.

Both follow TE2's exit-code rule: an added or retyped source column is a warning and exits 0 (SucceededWithIssues under --ci vsts / -V), while a missing source column, or a legacy SQL query partition whose query cannot be read, is an error and exits 1. te schemacheck --fail-on warning fails on any drift for one run; the model-level TabularEditor_SchemaCheckNoWarnings annotation does the same for every run, under both commands. All of TE2's schema-check annotations are honoured, including the historical misspelling TabularEditor_SkipSkemaCheck.

Differences from TE2 worth knowing before you swap the step:

  • Sources TE2 checked and the new CLI does not. A legacy Query partition on an Oracle or ODBC data source, or on an OLE DB provider for anything other than SQL Server, is reported as Not checked and does not fail the run, so a pipeline that is green today stays green. If you rely on such a table being checked, gate on tablesSkipped or on the SCHEMA_TABLE_SKIPPED findings in the JSON output. The SQL Server OLE DB providers (SQLOLEDB, MSOLEDBSQL) are checked as before on Windows; on Linux and macOS such a table fails with a message saying it can only be checked on Windows.
  • TRX files. te2 <model> -SC -T results.trx writes the same test names and outcomes as TE2 (Table '<name>' <assertion>, four assertions per table, any change Failed), so Azure DevOps keeps the test history and failTaskOnFailedTests fails on the same drift as before. Tables in the gap above report all four assertions as Inconclusive. te schemacheck --trx writes a different file: one result per finding, with the severities shown on the console.
  • Duplicated source columns. TE2 showed a dialog box when a source returned the same column twice, which blocked a command-line run. The new CLI reports it once as an informational note and never fails the run.
  • Not reproduced. TE2's warning that partitions of the same table return different columns. A table is described from its first partition only.