Background: Many software-intensive organizations are integrating AI/ML components into their systems, yet a significant number of ML models fail to progress beyond the experimentation stage into production. This is due to the complexity of ML life-cycle. To address the challenge in managing the ML life-cycle, organizations are beginning to explore Machine Learning Operations (MLOps), a discipline that extends DevOps principles to the ML. While several academic and industrial frameworks define ideal MLOps architectures, there remains limited practical understanding of how such pipelines can be implemented in organizations with legacy systems, hybrid data infrastructure and mature DevOps capabilities.

Objectives: This thesis is built around three primary objectives. First is to evaluate the current Software CI/CD pipeline of Telenor’s Operations Support Services (OSS)Division, a division with mature continuous software delivery practices but limited ML infrastructure, to assess its readiness to support ML Life Cycle Requirements. Next is to To propose a blue print of a MLOps pipeline which can be built on top of existing software delivery pipeline. The last objective is to identify the technical and organizational barriers in implementing the proposed blueprint.

Methods: To achieve these objectives, we conducted a qualitative case study in Telenor’s OSS division, combining data from a literature review, internal documentation, and semi-structured and unstructured interviews with data scientists, system architects and project managers.

Results: Findings reveal that the existing CI/CD pipeline supports several components of the ML lifecycle, particularly in deployment and artifact management, but lacks critical ML-specific elements such as data versioning, feature stores, and experiment tracking. A customized MLOps pipeline blueprint was proposed, identifying reusable DevOps components and areas requiring augmentation or new implementation. Technical and organizational barriers, including fragmented data infrastructure, limited compute resources, lack of specialized roles, and cultural resistance to automation were also identified.

Conclusions: This study provides a grounded, practical strategy for initiating MLOps in organizations with established DevOps practices and complex infrastructure. It contributes to literature by bridging conceptual MLOps models with real world constraints, and it supports practitioners in similar organizations by offeringa reusable blueprint for incremental MLOps adoption. The results emphasize that successful MLOps transformation is less about replacing DevOps and more about extending it to accommodate the iterative, data-centric demands of ML systems.