Your MLOps Vendor Just Got Acquired — Now What?

In the past 18 months, the MLOps vendor landscape has been reshaped faster than most teams had time to plan for. Iguazio — a platform that many Israeli enterprises and global financial institutions had built production ML pipelines on — was acquired by McKinsey. Dataloop, a data annotation and model management platform, was acquired by Dell. Neptune.ai, one of the most widely-used experiment tracking tools among research-oriented teams, announced shutdown. Seldon, a prominent open-core model serving platform, was acquired by TrueFoundry. And with Modular's pending acquisition by Qualcomm, another piece of the ecosystem is about to change hands.

This is not a transient dip. It is the predictable outcome of a venture-backed tooling market that matured faster than it monetized. The same market forces are still in motion. If your ML stack depends on specialist MLOps platforms — for experiment tracking, feature stores, model serving, data labeling, or pipeline orchestration — the probability that at least one of your vendors undergoes a significant ownership or product change in the next 24 months is not negligible.

What does that actually mean for your team, and what should you do about it? This post covers the mechanics of the consolidation wave, the real risks to customers, and the practical steps for assessing and reducing your exposure.

1. Why This Wave Happened

The 2019–2022 MLOps investment cycle produced dozens of well-funded companies targeting narrow slices of the ML infrastructure stack: experiment tracking, feature stores, model registries, data versioning, model monitoring, annotation tooling, serving infrastructure. Many of these tools were excellent — genuinely solving real problems — but they were solving problems that turned out to be hard to monetize at scale for three related reasons.

First, the most sophisticated ML teams — the ones with the highest willingness to pay — had the engineering capacity to build equivalent tooling in-house, and increasingly did. Second, the hyperscalers (AWS, Google Cloud, Azure) systematically absorbed the most successful patterns into their managed ML platforms, pricing them as add-ons rather than standalone products. Third, the GenAI shift starting in 2023 changed what enterprise ML teams prioritized: inference infrastructure, LLM ops, and RAG pipelines became the dominant concerns, and many MLOps platforms that were designed around classical training pipelines found their core value proposition under pressure.

The result was a market with excellent technology and insufficient standalone revenue, which is precisely the condition that triggers acquisition activity. Strategic buyers — consultancies wanting productized delivery capability (McKinsey/Iguazio), hardware vendors wanting software stickiness (Dell/Dataloop), and cloud-native platforms wanting customer base (TrueFoundry/Seldon) — stepped in to acquire at valuations that reflected the distress rather than the technology quality.

2. The Acquisition Table: What Happened and What Customers Face

The risks differ in character. A shutdown (Neptune.ai) creates an immediate, deadline-driven migration. An acquisition by a strategic buyer (McKinsey/Iguazio, Dell/Dataloop) creates gradual roadmap drift — the platform continues to function but investment priorities shift toward the acquirer's customer base and use cases, which may not match yours. An open-source platform acquisition (Seldon/TrueFoundry) creates fork risk: the hosted product and the OSS community version may diverge, and the fork you're on may not be the one that gets the security patches.

3. Measuring Your Lock-In

The first thing to do when your vendor gets acquired — or when you're evaluating a new one — is a systematic lock-in assessment. Lock-in in MLOps is more multidimensional than in traditional software because the data contracts are more complex.

Data portability

Can you export your experiment history, model artifacts, feature definitions, and metadata in a standard format without vendor tooling? If your experiment tracking lives only in a proprietary API, you don't own your experimental record — you're leasing it. The practical test: try to export six months of experiment data to files on your own infrastructure. If this requires a support ticket or a premium tier, you have non-trivial lock-in.

Pipeline portability

Are your ML pipelines expressed in vendor-native DSLs (Kubeflow Pipelines, ZenML, Metaflow steps, Iguazio's MLRun syntax) or in framework-agnostic code with thin wrappers? The more business logic lives in vendor-specific abstractions, the more expensive a migration becomes. A team that built their entire feature engineering and training pipeline in Iguazio's MLRun syntax faces a substantially harder migration than a team that used MLRun only for scheduling and logging.

Serving infrastructure

Model serving is often the highest-lock-in layer because it touches production traffic. If your inference endpoints are Seldon Deployments, BentoML bundles, or platform-native serving primitives, migrating without traffic disruption requires a parallel-run period and explicit traffic-shifting tooling. The teams that built serving on top of generic Kubernetes deployments with a thin sidecar for metrics are in a much better position.

Operational knowledge

The least visible form of lock-in is institutional knowledge. Teams that have spent 18 months learning a platform's operational quirks — how it handles restart behavior, what its failure modes look like in monitoring, how to tune its resource allocation — carry that knowledge in their heads, not in transferable skills. When the platform changes, that knowledge becomes a liability rather than an asset.

4. What to Do If Your Vendor Got Acquired

The right response depends on what kind of acquisition it is and how central the platform is to your stack. Here is a decision framework we use with clients:

Immediate actions (first 30 days)

• Get your data out. Export everything you can in the most portable format available: experiment logs, model artifacts, feature definitions, dataset metadata. Do this now, regardless of what the acquirer says about continuity. Storage is cheap; the ability to act quickly is not.
• Pin your version. If you're on a hosted platform, identify and document the exact version you're using. Acquirers sometimes accelerate deprecation cycles as they consolidate codebases.
• Map your dependencies. Enumerate every place in your codebase where you import the vendor's SDK, call their API, or rely on their infrastructure. The list is usually longer than teams expect.
• Read the acquisition announcement carefully. Specifically, look for what the acquirer says about their existing customers versus their target customer profile. If McKinsey is acquiring Iguazio to serve McKinsey's enterprise consulting customers, and you're a mid-market team without a McKinsey relationship, that is information.

Medium-term planning (30–90 days)

• Evaluate open-source alternatives at the same layer. MLflow for experiment tracking, DVC for data versioning, Ray Serve or Triton Inference Server for model serving, Feast for feature stores, Airflow or Prefect for pipeline orchestration — the open-source MLOps ecosystem has matured enough that the capability gaps between proprietary platforms and well-implemented OSS stacks have narrowed significantly in most functional areas.
• Assess the actual migration cost honestly. Teams consistently underestimate migration cost because they focus on the core platform replacement and ignore the surrounding infrastructure: CI/CD integrations, monitoring dashboards, data lineage tracking, team workflows, and documentation. A realistic migration estimate includes all of these.
• Talk to the acquirer directly. Ask specifically about pricing trajectory, EOL timelines for specific features you rely on, and the support model going forward. The answers will tell you more than the press release.

The worst migration is the one done in panic. The second worst is the one that never happens because the team convinced itself the acquisition was fine until it demonstrably wasn't. The right posture is planned optionality: keep your migration path warm without committing to it prematurely.

5. Migration Patterns That Work

When migration is warranted, a few patterns consistently reduce risk:

Containerize everything at the model boundary

The most durable serving architecture is a Docker container with a standard API contract (REST or gRPC, with an OpenAPI spec) and no runtime dependency on the MLOps platform that trained the model. If your model can be queried with a curl command against a container image you control, your serving infrastructure is effectively platform-independent. This is the pattern that makes Seldon migrations tractable: replace the Seldon Deployment with a generic Kubernetes Deployment, keep the container.

Abstract your feature access layer

Feature stores are the highest lock-in component in most enterprise ML stacks because feature definitions accumulate over time and encode substantial business logic. The abstraction pattern is straightforward: define features in a neutral format (Feast's feature view definitions are reasonably portable) and wrap all feature access behind an internal service interface. Your training code calls feature_store.get_online_features() from your own service, which delegates to the underlying platform. When you migrate, you change one adapter, not every training script.

Own your experiment artifacts, not just your metadata

Experiment tracking platforms store two things: metadata (parameters, metrics, tags) and artifacts (model checkpoints, datasets, evaluation outputs). Metadata is usually portable; artifacts are often stored in platform-controlled object storage with platform-controlled access patterns. Ensure your training code always persists artifacts to storage you own (S3, GCS, Azure Blob) in addition to the platform. The platform becomes a metadata index over artifacts that live on your infrastructure.

Shadow-run during migration

For serving-layer migrations, run both the old and new serving infrastructure in parallel with duplicated traffic for at least two weeks before cutting over. This is expensive in the short term and nearly always prevents incidents. Teams that skip the parallel-run period because the migration "looks clean" are the ones that find subtle performance regressions in production that weren't visible in offline evaluation.

6. The Case for Vendor-Independent Architecture

The consolidation wave makes a case that goes beyond "what to do when your vendor gets acquired." The more durable lesson is architectural: ML infrastructure built on top of open standards and open-source primitives is more resilient than ML infrastructure built on top of proprietary platforms, and the engineering overhead of the former has been declining steadily as the OSS ecosystem has matured.

This doesn't mean avoiding all managed services. Cloud-managed compute (SageMaker Training, Vertex AI Training, Azure ML Compute), managed object storage, and managed Kubernetes are all appropriate building blocks precisely because they are commodity infrastructure with stable APIs, multiple competitive alternatives, and no acquisition risk that matters to your ML workload. The risk is concentrated in the application-layer MLOps platforms that sit above the infrastructure layer — the experiment trackers, feature stores, model registries, and annotation tools where proprietary APIs and data formats create the lock-in.

The practical architecture guidance: use managed commodity infrastructure at the compute and storage layers, use open-source or open-standard tooling at the ML application layer, and treat any proprietary MLOps platform as a frontend concern (UI, dashboards, scheduling) rather than a backend data contract. Your data and your trained models should be reachable without the platform.

7. Why Vertical Expertise Matters More Than Platform Loyalty

There is a broader point here about what actually makes ML systems work in production, and it is not the MLOps platform. The teams that have navigated the consolidation wave least painfully are not the teams with the most sophisticated MLOps tooling — they are the teams with the deepest domain knowledge of their problem space.

A medical imaging team that understands the clinical context of their model's predictions, the failure modes that matter most in practice, and the regulatory constraints on model updates does not need a specific MLOps vendor to maintain production quality. They can operate effectively on top of whatever infrastructure is available because their value is in the model behavior and the clinical integration, not in the tooling around it. The same is true in industrial anomaly detection, financial risk modeling, ad-tech optimization, and signal processing applications.

Vertical expertise — the knowledge of what good looks like in a specific domain — is not transferable to a competing platform by an acquirer. It lives in your team, your evaluation frameworks, and your production monitoring thresholds. MLOps tooling is a vehicle for that expertise, not a substitute for it. Teams that invested in deep domain competence rather than deep platform competence are demonstrably better positioned as the vendor landscape continues to shift.

This is the positioning MLAIA operates from: we work across medical AI, signal processing, ad-tech, and defense applications not because we are neutral on tooling — we have opinions on tooling — but because the expertise that makes ML systems reliable in production is domain expertise, and domain expertise outlasts vendor ecosystems.

About MLAIA

MLAIA — Machine Learning & AI Approach — is an Israeli AI consulting firm specializing in production-grade ML systems across medical, defense, signal processing, and enterprise domains. Led by Dr. Yochai Edlitz (PhD, Weizmann Institute), MLAIA helps teams build vendor-independent ML infrastructure, execute platform migrations, and design architectures that are resilient to the vendor landscape they actually operate in. Based in Yavne, Israel; serving clients globally.