🧭 How toAIIntermediate✨ AI-assisted

How to Promote Models Between Environments With MLflow

WittyTech·9/12/2026·2 min read

#mlflow#model-registry#mlops

Teams that train or fine-tune their own models often move them between environments by copying files: a notebook saves a model, someone uploads it to a bucket, and production loads whatever is there. A few months later, nobody can say which training run produced the model in production. A model registry fixes that.

MLflow's Model Registry is a common choice. It's open source and also available as a managed service on several platforms.

Step 1: Log models from training runs

Log the model, its parameters and its evaluation metrics in the same run:

import mlflow

with mlflow.start_run():
    mlflow.log_params(params)
    mlflow.log_metric("f1", f1_score)
    mlflow.sklearn.log_model(model, name="model", registered_model_name="ticket-classifier")

Registering creates a new version of ticket-classifier linked to this run, so any version can be traced back to its code, data and metrics. The example uses MLflow 3, where name replaced the older artifact_path argument.

Step 2: Use aliases instead of stages

Recent MLflow versions use aliases rather than the older fixed stages. An alias is a movable name that points at one version:

from mlflow import MlflowClient

client = MlflowClient()
client.set_registered_model_alias("ticket-classifier", "champion", version=7)

Services load the model by alias, such as models:/ticket-classifier@champion, instead of by file path.

Step 3: Gate promotion on evaluation

Before moving the champion alias to a new version, run the candidate against a fixed evaluation set and compare it with the current champion. Automate this in CI, so promotion only happens when the candidate meets the agreed thresholds.

Step 4: Promote by moving the alias

Promotion is a single call that points champion at the new version. Rolling back is the same call pointing at the previous one. Record who moved the alias and why, for example as tags on the model version.

Step 5: Reload safely in services

Services should load the model at startup, or reload it on a schedule, and log which version they loaded. For large models, prefer a rolling restart over reloading in place, so you never serve two versions unpredictably.

Things to watch

Permissions. Restrict who can move production aliases.
Dependencies. Log the environment with the model, so production installs matching library versions.
Large artifacts. Keep model files in object storage behind the registry, not in the tracking database.

← More in AI