Why Model stages (staging, production, archived) in MLOps? - Purpose & Use Cases

The Big Idea

What if a simple label could save your app from using the wrong AI model?

The Scenario

Imagine you have a machine learning model that you update often. You keep testing new versions on your computer, then try to put the best one on your website. But you have no clear way to separate models you are testing from the ones your users see. You also don't know which old models you can safely delete.

The Problem

Doing this by hand means you might accidentally use a test model for real users, or keep too many old models that clutter your system. It's slow to track which model is ready and which is not. Mistakes can cause your app to break or give wrong results.

The Solution

Using model stages like staging, production, and archived helps you organize your models clearly. You put new models in staging to test them safely. When ready, you move them to production for real use. Old models go to archived to keep history without clutter. This makes managing models simple and safe.

Before vs After

✗ Before

model = load_model('model_v3.pkl')  # no clear stage, risky to use directly

✓ After

model = get_model(stage='production')  # safely get the live model

What It Enables

This lets teams confidently update models without breaking apps, keeping users happy and systems clean.

Real Life Example

A company tests a new fraud detection model in staging. After confirming it works well, they promote it to production so all transactions use it. Older models move to archived for record-keeping.

Key Takeaways

Manual model management is risky and confusing.

Model stages organize testing, live use, and archiving clearly.

This improves safety, speed, and cleanliness in ML workflows.

Practice

1. What is the primary purpose of the staging stage in model lifecycle management?

easy

A. To deploy models for live user traffic

B. To test and validate models before they go live

C. To permanently delete old models

D. To archive models for long-term storage

Solution

1. Step 1: Understand model stages

   The staging stage is used to test and validate models before they are deployed to production.

2. Step 2: Differentiate from other stages

   Production is for live use, archived is for storage, so staging is the testing phase.

3. Final Answer:

   To test and validate models before they go live -> Option B

4. Quick Check:

   Staging = Testing phase [OK]

Hint: Staging means testing before live use [OK]

Common Mistakes:

• Confusing staging with production
• Thinking archived means active use
• Assuming staging is for deleting models

2. Which MLflow command correctly transitions a model version to the production stage?

easy

A. mlflow models transition-version --model-name my_model --version 3 --stage production

B. mlflow model transition-version --model-name my_model --version 3 --to-stage production

C. mlflow models transition-version --model-name my_model --model-version 3 --stage production

D. mlflow models transition --model-name my_model --model-version 3 --stage production

Solution

1. Step 1: Recall MLflow CLI syntax

   The correct MLflow CLI command to transition a model version is mlflow models transition-version with flags --model-name, --version and --stage.

2. Step 2: Identify correct flags and command

   mlflow models transition-version --model-name my_model --version 3 --stage production matches the correct syntax.

3. Final Answer:

   mlflow models transition-version --model-name my_model --version 3 --stage production -> Option A

4. Quick Check:

   Correct MLflow syntax = mlflow models transition-version --model-name my_model --version 3 --stage production [OK]

Hint: Use 'transition-version' with --version and --stage flags [OK]

Common Mistakes:

• Using 'model' instead of 'models'
• Mixing up --model-version and --version flags
• Incorrect command order or missing flags

3. Given this MLflow Python snippet, what will be the stage of the model after execution?

from mlflow import MlflowClient
client = MlflowClient()
client.transition_model_version_stage(
    name="my_model",
    version=2,
    stage="archived"
)

medium

A. Archived

B. Production

C. Staging

D. None (error)

Solution

1. Step 1: Understand the method call

   The method transition_model_version_stage changes the stage of a model version to the specified stage.

2. Step 2: Check the stage argument

   The stage argument is set to "archived", so the model version 2 of "my_model" will be moved to archived stage.

3. Final Answer:

   Archived -> Option A

4. Quick Check:

   transition_model_version_stage with stage='archived' = Archived [OK]

Hint: Stage argument sets the model's new stage directly [OK]

Common Mistakes:

• Assuming default stage if not specified
• Confusing method name with other MLflow functions
• Thinking 'archived' means deletion

4. You run this MLflow CLI command but get an error:

mlflow models transition-version --version 5 --stage production

What is the most likely cause?

medium

A. The command should be mlflow model transition-version (singular 'model')

B. Incorrect stage name; should be 'prod' instead of 'production'

C. Version number must be a string, not a number

D. Missing the --model-name argument

Solution

1. Step 1: Check required arguments for transition-version

   The mlflow models transition-version command requires the --model-name argument to specify which model to update.

2. Step 2: Identify missing argument

   The command lacks --model-name, causing the error.

3. Final Answer:

   Missing the --model-name argument -> Option D

4. Quick Check:

   Missing required flags cause errors [OK]

Hint: Always include --model-name when transitioning versions [OK]

Common Mistakes:

• Assuming stage names are abbreviated
• Using singular 'model' instead of 'models'
• Passing version as string instead of number (both accepted)

5. You have two model versions: v1 in production and v2 in staging. You want to promote v2 to production and archive v1 using MLflow Python API. Which sequence of calls correctly achieves this?

hard

A. client.transition_model_version_stage('model', 2, 'archived') then client.transition_model_version_stage('model', 1, 'production')

B. client.transition_model_version_stage('model', 2, 'production') then client.transition_model_version_stage('model', 2, 'archived')

C. client.transition_model_version_stage('model', 1, 'archived') then client.transition_model_version_stage('model', 2, 'production')

D. client.transition_model_version_stage('model', 1, 'production') then client.transition_model_version_stage('model', 2, 'staging')

Solution

1. Step 1: Archive current production version first

   To free the production stage, first move v1 from production to archived.

2. Step 2: Promote staging version to production

   After archiving v1, promote v2 from staging to production.

3. Final Answer:

   Archive v1 then promote v2 -> Option C

4. Quick Check:

   Archive old before promoting new [OK]

Hint: Archive old production before promoting new [OK]

Common Mistakes:

• Promoting new before archiving old causes stage conflict
• Archiving staging version instead of production
• Reassigning stages incorrectly