Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

60 Days of Data Days! Live and on-demand sessions, challenges, study groups and more! And it's all FREE!. Join now. Learn more

Reply
binitafulpagare
Kudo Collector
Kudo Collector

ML Deployment

Hi everyone,

I'm learning how organizations move machine learning models from experimentation to production using Microsoft Fabric.

For those working in production environments:

How do you deploy models?
How do you monitor model performance?
How do you manage retraining?
Which Fabric services do you use throughout the ML lifecycle?

I'd appreciate hearing about your architecture and best practices.

Thank you!

1 ACCEPTED SOLUTION

Hi @nbleonhard,

Thank you for sharing your real-world experience. It's interesting to see how moving from a local laptop-based workflow to Microsoft Fabric has improved your machine learning process.

I particularly liked your point about having a dedicated Lakehouse for each ML project. Separating ML workflows from data ingestion while storing reference tables and prediction history in Delta tables seems like a practical approach that also makes collaboration with BI teams much easier.

I have one question based on your implementation. As the number of ML projects grows, how do you manage shared datasets and reusable features across multiple Lakehouses? Do you maintain a centralized feature repository or rely on OneLake shortcuts to avoid data duplication?

Thanks again for sharing your experience—it's always valuable to learn from production implementations rather than just theoretical best practices.

View solution in original post

4 REPLIES 4
nbleonhard
Advocate I
Advocate I

Before Microsoft Fabric, our entire machine learning operation ran on my laptop. One of the big advantages of moving to Fabric was that each ML project got access to its own lakehouse, which now plays a central role in our entire ML lifecycle.

Here are a few of the biggest benefits we've seen:

  • Decoupled workflows: It allowed us to decouple our machine learning pipeline from the data ingestion process.
  • Reference tables: Setting up reference tables is super convenient. For example, I use a delta table as a crosswalk to map our raw feature names to user-friendly names.
  • BI accessibility: Storing our current predictions (as well as past predictions) directly on the lakehouse is convenient for our BI team.

Hi @nbleonhard,

Thank you for sharing your real-world experience. It's interesting to see how moving from a local laptop-based workflow to Microsoft Fabric has improved your machine learning process.

I particularly liked your point about having a dedicated Lakehouse for each ML project. Separating ML workflows from data ingestion while storing reference tables and prediction history in Delta tables seems like a practical approach that also makes collaboration with BI teams much easier.

I have one question based on your implementation. As the number of ML projects grows, how do you manage shared datasets and reusable features across multiple Lakehouses? Do you maintain a centralized feature repository or rely on OneLake shortcuts to avoid data duplication?

Thanks again for sharing your experience—it's always valuable to learn from production implementations rather than just theoretical best practices.

v-abhinavmu
Community Support
Community Support

Hi @binitafulpagare,

Thanks for reaching out to the Microsoft Fabric Community forum.

 

We've started following the MLflow-native workflow that Microsoft recommends for Fabric.

 

Our typical lifecycle looks like this:

OneLake/Lakehouse → Fabric Notebook (Spark) → MLflow Experiment → ML Model Registry → ML Model Endpoint → Monitoring Hub → Fabric Pipeline (scheduled retraining)

  • Development: Train models in Fabric notebooks and track every run with MLflow Experiments, which logs parameters, metrics, artifacts, and code versions.
  • Deployment: Register the best model in the ML Model Registry and activate a Machine Learning Model Endpoint for real-time inference.
  • Monitoring: We use the Monitoring Hub to track experiment runs and monitor endpoint metrics such as request count, error count, latency, and traffic. For business KPIs (accuracy, drift, etc.), we'd typically implement our own monitoring notebooks or pipelines since Fabric's built-in monitoring focuses on experiment and endpoint operations rather than automated drift detection.
  • Retraining: Scheduled Fabric Pipelines rerun training notebooks, log the new run to MLflow, evaluate the results, and register a new model version when it meets our acceptance criteria.
  • Production MLOps: For enterprise environments, cross-workspace MLflow logging supports Dev → Test → Prod promotion while maintaining separate workspaces and governance.

Microsoft has done a nice job of integrating experimentation, model management, deployment, and monitoring into a single platform, making it possible to implement an end-to-end MLOps workflow without relying on multiple external services.

 

For more details, please refer to the below offical documentation:

Machine learning experiment - Microsoft Fabric | Microsoft Learn

Serve real-time predictions with ML model endpoints (Preview) - Microsoft Fabric | Microsoft Learn

Monitor machine learning experiments and models - Microsoft Fabric | Microsoft Learn

 

I hope this helps. Please feel free to reach out if you have any further questions.
Thank you.

 

 

Hi @v-abhinavmu,

Thank you for the detailed explanation. I really appreciate how you've outlined the complete MLflow-native MLOps workflow in Microsoft Fabric, from model development through deployment, monitoring, and retraining.

I found the integration of MLflow Experiments, the Model Registry, Model Endpoints, Monitoring Hub, and scheduled Fabric Pipelines particularly valuable, as it provides a clear framework for managing the entire machine learning lifecycle within a single platform.

I have one follow-up question. As organizations manage multiple machine learning models across different business domains, what best practices do you recommend for organizing MLflow experiments, model versioning, and the Model Registry to keep everything scalable and easy to maintain? It would be great to understand how enterprise teams typically structure these assets as the number of models grows.

Thank you again for sharing these insights and the official Microsoft Learn resources. I'm looking forward to learning from the experiences of other community members as well.

Helpful resources

Announcements
FabCon and SQLCon Barcelona 2026

FabCon & SQLCon – Barcelona 2026

Join us in Barcelona for FabCon and SQLCon, the Fabric, Power BI, SQL, and AI community event. Save €200 with code FABCMTY200.

60 days of Data Days Carousel

Data Days 2026

Join Data Days 2026: 60 days of free live/on-demand sessions, challenges, study groups, and certification opportunities.