When Sharad Kumar’s previous startup, Accurics, was acquired by Tenable, his team spent eight to nine months just moving cloud accounts within the same provider. Not a cross-cloud migration. Not even a change of platform. Just an internal move, and it still took the better part of a year. That experience, lived rather than studied, became the founding insight behind FluidCloud, where Kumar now serves as co-founder and CEO. The lesson wasn’t that migration is hard; everyone already knows that. It was that the tooling industry has spent years solving the easy 20 percent of the problem, compute and storage, while leaving the other 80 percent, IAM, networking policies, security groups, and encryption keys, as manual cleanup work that quietly turns six-week projects into twelve-month ones.
In this VMblog Q&A, Kumar walks through how FluidCloud is positioning itself as something genuinely new rather than another entrant in a crowded migration-tools market. He describes Cloud Cloning, a category he says FluidCloud originated, built on an always-current infrastructure graph called FluidGraph and a purpose-built model, the Large Infrastructure Model (LIM), trained specifically because general-purpose LLMs proved too unpredictable for deterministic infrastructure work. Kumar also gets specific about what’s driving urgency right now, from the Broadcom-VMware fallout pushing enterprises toward steep renewal hikes, to the cost conversations that follow once a workload can actually move between clouds. He closes by previewing where FluidCloud is headed next: AI agents that execute infrastructure changes directly, and a cloud-agnostic SDK meant to let developers build against an operational layer instead of any single provider’s APIs.
++
Origin story
VMblog: You’ve said the idea for FluidCloud came out of a previous startup where it took your team eight or nine months to integrate into a different cloud provider after an acquisition. What did that experience teach you that wasn’t already obvious from outside, and at what point did you decide “someone has to build a better way” was actually “we have to build it”?
Sharad Kumar: This wasn’t a problem we studied from the outside. We lived it. After our previous company, Accurics, was acquired by Tenable, integrating into the new parent’s AWS environment took us months. And that was just moving accounts within the same cloud provider, not a cross-cloud migration. We had highly technical people and years of cloud API experience from building Accurics. Migration was still a herculean task.
Everyone knows migration is hard. The lesson for us was more specific: \The tools handled the easy 20 percent. The other 80 percent, IAM, networking policies, security groups, encryption keys, stayed manual.
The shift from “someone should fix this” to “we have to” came when we mapped the problem against what we already had. Years of cloud API depth from the CSPM work at Accurics, the lived pain fresh in our minds, and a tooling gap that kept widening. Because once you go through that kind of pain, you don’t forget it. So, we started building.
Defining the category
VMblog: You’ve called FluidCloud the world’s first Cloud Cloning platform. For a reader who’s familiar with migration tools, IaC generators, and cloud management platforms, what’s the simplest way to explain what Cloud Cloning is, and what existing categories it replaces rather than complements?
Kumar: With Cloud Cloning, you are able to, essentially, “cut & paste” your cloud estate just like you would operate on a file in your OS. Choose your “source”, choose your “destination,” and the entire environment will move at complete fidelity.
The important part of this is how we create an exact replica of your infrastructure at atomic granularity (every single compute, network, IAM, storage, monitoring, etc. and the relationships between them) into FluidGraph, which is a universally portable graph of your infrastructure with resources, dependencies, and all other metadata. This is simply an always-up-to-date operational graph of your entire environment.
Once you have that graph, the categories your readers know and understand start to collapse – just like coding operations start to collapse into an IDE. Today, migration tools handle workload movement. IaC generators give you templates. Cloud management platforms give you observability. Each solves a minute part of a DevOps or FinOps workflow. What FluidCloud offers is that IDE like operability on your single cloud or multi-cloud estate because cloning, optimizing, recovering, and rebalancing now become different operations on the same underlying graph. And all of those operations are powered by 10+ proprietary patterns – Cloud Cloning and Large Infrastructure Model being the foundation of it all.
We’re building, expanding, and continually optimizing the operational layer that powers all DevOps and FinOps workflows that today’s fragmented toolsets don’t serve well.
The Large Infrastructure Model
VMblog: Most infrastructure AI today is a wrapper around a general-purpose LLM. You built LIM, the Large Infrastructure Model, as something different. Why does infrastructure need its own model, and what kinds of decisions can LIM make that a generic model fundamentally can’t?
Kumar: Most teams putting AI on infrastructure start with a general-purpose LLM and try to teach it Terraform. We did exactly that. We spent four months on it and failed.
The reason comes down to one sentence: infrastructure is deterministic, LLMs are probabilistic. That’s a tough marriage to make work. When a general model hallucinates in language, you get an awkward sentence. When it hallucinates on a Terraform plan or an IAM policy, you get an outage. We saw output referencing AWS APIs that don’t exist, syntactically valid and completely wrong. On infrastructure you need absolute accuracy on the configuration and creativity on the solutioning. You do not get that from current general-purpose AI.
LIM learns from what infrastructure does: the relationships between resources, the patterns in real migration paths, the outcomes of real executions. And because LIM is grounded in FluidGraph, the cloud context graph that we build, it reasons precisely about what’s in the customer’s environment.
That grounding lets LIM make the decisions with unparalleled multi-cloud or multi-account or multi-region context that you can’t even get from your cloud console. Rebalancing a workload across providers. Predicting the cost impact of a change before it runs. Mapping a service from one cloud to its equivalent on another. Those decisions require expertise that the LIM brings and the up-to-the minute context that FluidGraph brings. Prompt engineering simply can’t deliver that.
The VMware exit moment
VMblog: The Broadcom acquisition of VMware has pushed a lot of enterprises to reconsider their virtualization stack. What are you actually seeing inside customer environments right now, where are people going, and what surprises them most about the cost and complexity of leaving?
Kumar: The timeline surprises people more than the cost. Most organizations considering leaving VMware typically think they have enough time. However, when those organizations review the renewal terms, they will see 3-year agreements with rate increases as high as 1,000% and the math quickly gets out of hand
The financial service industry and the healthcare sector lead the charge for exiting VMware. They have large VMware footprints due to heavy compliance and regulatory requirements. One customer we’re working with has 10,000 VMs and less than a year before renewal. The traditional playbook says hire a system integrator and go workload by workload, six figures and six weeks per cluster. At a hundred clusters that playbook falls apart.
The other surprise has to do with how much of your time gets spent. The VMs map in minutes. NSX-T is the slow part. Firewall rules, virtual networks, load balancers, all the policy logic wrapped around the workloads. Teams burn their consulting budgets on that layer, and that layer is exactly what we automate.
Why existing tools stop at the VM boundary
VMblog: You’ve pointed out that traditional migration tools handle compute and storage but miss IAM, Kubernetes manifests, security groups, encryption keys, and database schemas. Walk us through what actually breaks in production when those layers get treated as an afterthought, and how FluidCloud handles them in a single pass.
Kumar: The problem isn’t the virtual machine (VM) in the destination environment. The VM is going to come up clean; what’s broken is every resource that attaches to it.
A workload doesn’t stand alone. Workloads have IAM policies granting it access to other services. Security groups controlling what can talk to it. Encryption keys letting it read its own data. Kubernetes manifests telling it how to scale. Database schemas it depends on. If any one of those is wrong in the destination cloud, the workload either fails to start, or it fails silently. The silent failures are worse. You don’t find out until production traffic hits.
Traditional migration tools were designed when “migration” meant moving a VM. The infrastructure supporting the VM was considered to be secondary as cleanup. That’s how you get a twelve-month project that should have been migrated in six weeks
FluidCloud handles all of it in a single pass because the infragraph already understands what attaches to what. We’re not discovering dependencies during the move. We mapped them when we ingested the environment. When we deploy on the destination cloud, the policies, networks, identities, manifests, and schemas come with the workload, translated into the destination’s equivalents. That’s the difference between a migration and a clone.
From months to minutes
VMblog: You’ve described migrations that used to take months and now take minutes. For an infrastructure leader who hears that and thinks “that’s marketing,” what does a real customer engagement actually look like end-to-end, and what’s the moment in the process where the timeline really compresses?
Kumar: Fair question. “Months to minutes” sounds like marketing to anyone who has done a real migration, so let me walk through what it actually looks like.
Typically, the first step in the process involves using read-only credentials to access your source Cloud. Within 30-40 seconds, we will have scanned and built the graph of your infrastructure , typically around 100,000 resources. The Customer will then see a detailed inventory of all of their current environment at the atomic level (including items they may not have known existed) when they view their Infragraph.
The next step in the process involves selecting a Destination Cloud. We provide the Customer with details about how their Source Environment has been translated into the Target Environment. This includes resource mapping, comparisons of costs, and translations of policies. It is here that the “compression” occurs. What would take weeks of discovery by a traditional SI Team has already been completed in the first few minutes of using FluidCloud platform
When it comes to deploying the Workload, such as moving 100 Virtual Machines with complete Networking, Identity Access Management (IAM), and Storage configurations in minutes, we are able to accomplish such a deployment within minutes. In every customer demo, this is the Aha moment – when optionality emerges within a few minutes.
What we don’t compress is the rest of the operational work. Skills transfer, DR validation, runbook updates. That takes time you can’t skip. But the technical migration that used to be a six-month project becomes a six-week project. That’s where our solution provides immediate value.
There is more though. Like-for-like migrations are largely solved with FluidCloud. We now can support many modernization efforts quite well too where you are taking a VMware estate and moving to native cloud services. Those are the heterogeneous migrations we continue to productize – powered by LIM and FluidGraph!
The cost story beyond migration
VMblog: A lot of multi-cloud conversations start as portability conversations and end as cost conversations. Once a workload can move, how does the cost calculus change for an infrastructure team, and what do you tell CFOs who want a number before they commit?
Kumar: I agree with your point that all of these ultimately turn into cost conversations; and the price of cost will change when the workload can actually be moved.
Right now, hyperscaler renewal negotiation are a one-way street because the workload has been “stuck” since day-one, and so the renewal team prices based on that. When you’re able to move a workload in days, you can then come to the table at the time of the next renewal with a real alternative already scoped and begin negotiating from a position of power.
The interesting math comes beyond just renewals – placement. Customers receive the RGB of infrastructure from us: cost, security, performance. The same workload, three clouds, three scores. In practical terms, compute-intensive workloads go to where compute is least expensive, egress-heavy workloads go to where egress is least expensive, and AI workloads go to where there is an adequate supply of GPUs.
For those CFOs looking for a dollar number. I provide them with a different number: What did this workload cost if you had moved it six months ago? Our tool runs that number through the customer’s actual spend versus actual cloud pricing over the same timeframe. A dollar amount pulled directly out of their own books tends to carry much more weight than any vendor ROI model.
What’s next
VMblog: Looking at the next twelve months, what should infrastructure and DevOps leaders be paying attention to that they probably aren’t, and where do you want FluidCloud to be by this time next year?
Kumar: The thing to watch is AI agents executing infrastructure changes rather than drafting scripts for a human to review. Today’s AI tools can generate a script, and even the good ones still need a human in the loop for anything touching production, because they can’t reason about the operational environment the script will run against.
We’re closing that gap next. We’re entering early access on the Model Context Plane, MCP, which gives AI systems the same continuously updated operational context a senior platform engineer carries around in their head, grounded in the real infragraph. An agent that knows what’s there can make changes safely.
Alongside that we’re building a cloud-agnostic DevOps SDK, so developers, enterprises, and AI systems can program against the operational layer instead of any one provider’s APIs. The path away from lock-in runs through that layer.
A year from now I want FluidCloud underneath every serious multi-cloud and AI-driven infrastructure operation. We tell customers cloud infrastructure is no longer a constraint, it’s a canvas. The next twelve months are about making that true for a lot more of them.
##
