Table of Contents

Migrating from the TE2 Command Line

  • 2026-10-27
  • 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-12-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).

Scripts (-S) in TE2 mode behave as they did in Tabular Editor 2:

  • A failed script stops the run. If a script throws or doesn't compile, the run exits with code 1 before anything is saved, analyzed or deployed. There is no build output (-B, -F, -TMDL), no BPA result and no -T file, and any output from an earlier run is left as it was. A pipeline step that always reads the .trx file must handle it being absent.
  • Compile errors show where they are. Each error is written to stdout as Error <code> on line <line>, col <column>: <message>. With -V or -G, it becomes an annotation that points at the line in the script file.
  • Each script runs as one change. Follow-on changes, such as fixing up DAX that refers to a renamed column, are applied when the script ends rather than after each statement. A script that renames a column and then reads a measure that uses it sees the old expression until the script ends.
  • TECLI is defined. Scripts see the TECLI preprocessor symbol and not TE3, as with te script. Tabular Editor 2 defines neither.

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.
-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 codes as TE2, and checks more kinds of tables - see Schema check.
-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, which also checks Power Query and Direct Lake tables.
    • 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 Tabular Editor 2's schema check with the new CLI:

  • te2 <model> -SC works as before. It checks only the tables Tabular Editor 2 checked, legacy query partitions on a provider data source, and writes the same -T results. Use it to move a pipeline over without changing its result.
  • te schemacheck is the command for new pipelines. It also checks Power Query (M) and Direct Lake tables, and supports JSON output.

Both use Tabular Editor 2's exit codes: an added or retyped source column is a warning and exits with code 0, and a missing source column, or a legacy query that can't be read, is an error and exits with code 1. Both honor Tabular Editor 2's schema check annotations, except TabularEditor_AddFalseWhereClause.

Differences from Tabular Editor 2:

  • Some sources are no longer checked. A legacy query partition on Oracle, ODBC, or an OLE DB provider other than SQL Server is listed under Not checked and doesn't fail the run. The SQL Server OLE DB providers are checked on Windows only.
  • The -T file from te2 -SC matches Tabular Editor 2's. It has four results per table, named Table '<name>' <assertion>, so Azure DevOps keeps the test history. A table on one of the sources above gets four Inconclusive results. te schemacheck --trx writes a different file, with one result per finding.
  • Duplicate source columns no longer stop the run. Tabular Editor 2 showed a dialog box when a source returned the same column twice. The CLI reports it once as information.