Skip to content

Move the next run before you move the history.

The lowest-risk move from a self-hosted MLflow server is usually a staged cutover. Send new runs to the managed server, and keep the old server readable while you decide which history still matters.

A staged cutover

  1. Deploy the new server

    Create the Trackshund server. Before changing production jobs, confirm that a small test run can log metrics and an artifact.

  2. Change the tracking URI

    Update the environment variable or shared configuration that sets MLFLOW_TRACKING_URI, plus the new token.

  3. Keep the old server read-only

    Leave historical experiments available long enough for the team to finish comparisons and identify any models or artifacts it still needs.

  4. Plan history separately

    Trackshund does not currently have a one-click importer for an existing MLflow database and artifact store. Scope historical migration as a separate project.

What changes in the training code?

Usually, only the configuration changes. The new endpoint uses standard MLflow, so run creation, metric logging, artifacts, and the model registry continue to use the same SDK.

# Before
export MLFLOW_TRACKING_URI=https://old-mlflow.example

# After
export MLFLOW_TRACKING_URI=https://your-team.mlflow.example
export MLFLOW_TRACKING_TOKEN=<your-token>

Illustrative hostnames. The dashboard supplies your actual address and connection instructions.

Before switching a real job

Record the old tracking URI, confirm who can still access it, and run one disposable experiment against the new server. A cutover is easy to reverse when the previous address and credentials have not been dismantled yet.

Cut over the next experiment.

Deploy a standard MLflow server, test the new tracking URI and keep the old history in view while you cut over.

Deploy your MLflow server