How do I deploy a new model version without disrupting applications?

Summary

• Add indirection. Point applications at a stable alias (for example @champion) or a stable serving endpoint, never a hard-coded version number, so promoting a new version is a pointer move, not a client change or redeploy.
• Roll out gradually. Traffic splitting lets one endpoint serve multiple versions and route a share of requests to the new one, so you widen exposure only as results hold up.
• Keep the old version live until the new one is ready. A zero-downtime update means requests never hit a cold or missing endpoint during the swap.
• Make rollback instant. Reverting is a single, atomic pointer move back to the previous version, recorded for audit.
• On Databricks: MLflow model aliases in the Unity Catalog model registry plus Model Serving traffic splitting give an atomic, audited, zero-downtime swap behind a stable endpoint.

How do I deploy a new model version without disrupting applications?

Deploy without disruption by putting a layer of indirection between your applications and the model version they call. Applications should reference a stable alias (for example @champion) or a stable serving endpoint, never a hard-coded version number. Promoting a new version then becomes a pointer move rather than a client change or a redeploy, you can shift traffic to it gradually, and you can roll back instantly if something looks wrong. On Databricks this comes from two pieces working together: MLflow model aliases in the Unity Catalog model registry, and traffic splitting in Model Serving.

What makes a version swap risky

A deployment disrupts applications for three reasons: clients are coupled to a specific version number, the new version replaces the old one all at once with no fallback, or the endpoint address changes. The fix is to decouple the reference (an alias or endpoint) from the artifact (a numbered version), release the new version progressively, and keep the previous version available for an immediate rollback.

What to look for in a zero-downtime deployment path

Capability	Why it matters
Stable reference indirection	Applications call an alias or endpoint, not a version number, so a new version needs no client code change.
Zero-downtime update	The current version keeps serving until the new configuration is ready, so requests never hit a cold or missing endpoint.
Traffic splitting	Routing a share of traffic to the new version (canary, A/B, gradual rollout) limits blast radius while you watch results.
Instant, atomic rollback	Reverting is a single pointer move back to the prior version, not a rebuild.
Version-tagged logging	Requests and responses recorded with the serving version make A/B analysis a query rather than a custom metrics pipeline.
Governance and audit	A registry that records who moved which alias, and when, gives an auditable promotion trail.

How Databricks approaches zero-downtime model deployment

• Reference a movable alias, not a version. In the Unity Catalog model registry, MLflow aliases are named pointers to a specific model version. Common conventions are @champion for the current production model and @challenger for a candidate, and because aliases are user-defined you can adopt names like @prod to match your own process. Clients resolve a reference such as models:/catalog.schema.model@champion, so promoting a version never touches client code.
• Update the endpoint with zero downtime. When you update a Model Serving endpoint with a new version, the existing configuration keeps serving until the new one is ready, so live applications see no interruption during the swap. See Model Serving.
• Roll out gradually with traffic splitting. A single endpoint can serve multiple model versions and route a configurable share of traffic to each. Send a small fraction of requests to the new version first, then raise it as the results hold up. The split is a configuration change on one endpoint, not a separate deployment. See serve multiple models to an endpoint.
• Compare versions with version-tagged logs. Inference tables log each request and response to a Delta table along with the model version that served it, so A/B comparison is a SQL query rather than a bespoke measurement pipeline.
• Promote and roll back atomically. Promotion is a single alias reassignment to the new version, and rollback re-points the alias to the previous version. Both are instant and atomic, need no client change or redeploy, and every alias move is recorded in Unity Catalog for audit. See upgrade ML workflows to models in Unity Catalog.

FAQs

Do applications need to change when I deploy a new version?

No. If clients reference an alias (such as @champion) or a stable serving endpoint rather than a version number, promoting a new version is a pointer move that requires no client code change or redeploy.

How do I limit risk while rolling out?

Use traffic splitting on a single Model Serving endpoint to send a small share of requests to the new version first, then widen it as the results hold up. If metrics regress, re-point the alias to the previous version.

How fast is rollback?

Rollback is an atomic alias reassignment back to the prior version, so it takes effect without a rebuild or redeploy. The Unity Catalog model registry records every alias change for audit.

How do I compare the new and old versions in production?

Turn on inference tables for the endpoint. Each request and response is logged to a Delta table with the served model version, so you can run A/B analysis as a SQL query over real production traffic.

What is the difference between an alias and a version?

A version is an immutable, numbered model artifact in the registry. An alias is a named, movable pointer (like @champion) to one of those versions. Applications reference the alias, and you promote or roll back by moving it.