CloudBees CEO: Why Migration Is a Mirage Costing You Millions  ## Document Notes ## Highlights - **Modernization ≠ Migration** - Enterprises routinely equate modernization with migration, which delays real customer value delivery. - Anuj Kapur calls this pattern the "migration mirage" because migrations cost more, take longer, and yield distant benefits. Transcript: Anuj Kapur Yeah, Alex, what I would say is that I think this is the first survey of its kind to really get an assessment of both the pain and the reward of something that enterprises have always believed In, which is modernization. I think the challenge has been that people have equated modernization, which is very essential, both in the IT tier and the application tier, with migration. And I think we ourselves have always believed this data to be generally accurate and representative of the reality that our customers face. But this is the first time that we actually have a quantitative assessment of it. And I think when you talk to most customers, what they will tell you is it takes longer, costs more, and basically pushes you back. On moving your company forward and catering to customer requirements are actually spent on replatforming and restructuring your IT environment to be able to ultimately deliver Value in the future. But that value is more distant. It's more modest. ([Time 0:01:54](https://share.snipd.com/snip/1a737761-4543-4b79-90f3-31789f235d79)) - **Apps Outlast Leadership Changes** - Applications often outlast CIOs, so repeated wholesale replacements ignore system longevity. - Kapur notes developers resist reworking functioning systems and prefer building new customer-facing features. Transcript: Anuj Kapur Yeah, I mean, we have a saying, which is the half-life of an enterprise application is probably five times the half-life of an enterprise CIO. You know, put simply, what it means is that most customers underestimate the longevity of applications and the resiliency of the infrastructure that exists to actually support them. I think what we have seen in the past is CIOs come and go, applications don't. And what that typically means is that a decision to modernize, which is couched in the form of migration, tends to sort of sap the creativity of the core persona that is responsible for That. And that is the engineers and that is the developers, right? The developers sort of that we call the builders, the persona that we cater to, because we want to help them go better, faster, and build safer. If you look at sort of that profile, and you look at what their mandate is, and what you look at sort of their what their profile and psychology is, they want to build, they want to create, They want to deliver value. What they don't want to do is take systems from 10 years ago and say, how do we actually make those better, especially if those systems are actually working and delivering value. And so I think this is sort of what we're finding is there is a subjective narrative with regards to existing systems that does not necessarily relate to the objective metrics of that Infrastructure. So we're believers in modernization, not migration. ([Time 0:04:02](https://share.snipd.com/snip/96997296-ea14-4545-9dde-9c93fd9ece05)) - **Leverage Existing Tooling** - Embrace existing tooling as value drivers instead of forcing rip-and-replace migrations. - Kapur advises meeting developers where they are and adding guardrails for governance, compliance, and security. Transcript: Anuj Kapur And our philosophy as a company, a CloudBees, is to effectively embrace the tooling and the platforms of your choice. We're not trying to change our customers' religion. We want to embrace their religion. And we want to work with that in an effort to actually drive the core goal that all enterprise CIOs and the C-suite and developers have, which is modernization. Modernization, not migration. Alex Williams That's an interesting term. You use the term religion. Absolutely. Anuj Kapur I mean, you know, I'll share with you another anecdote which has been hardened along the way which is telling developers what tools to use is like telling teenagers what to wear i don't Know how it goes in your household but i can tell you i'm only successful half of the time and it's sort of the same thing here which is you know if you're empowering developers to build If you're hiring developers because they have the creativity if you believe that they're the focal point of the transformation you need to drive, then you need to empower them with The decision-making. You need to treat them like adults. They are going to have their beliefs. Some of those beliefs are going to borderline be religious in nature because that's who they are. And our philosophy is let's embrace that to an extent. Let's basically drive the modernization agenda. Let's cater to the needs of the organization, which is governance, compliance, and security. But let's give the freedom to the developers to be able to build within the guardrails that the organization believes are appropriate. And those guardrails are driven by geography. ([Time 0:07:18](https://share.snipd.com/snip/1db1b6c1-09be-4830-8276-a9e966c624b9)) - **Telling Developers What To Use** - Kapur compares dictating developer tools to telling teenagers what to wear, noting limited success. - He uses this story to argue developers should be treated like adults and empowered with tool choices. Transcript: Anuj Kapur I mean, you know, I'll share with you another anecdote which has been hardened along the way which is telling developers what tools to use is like telling teenagers what to wear i don't Know how it goes in your household but i can tell you i'm only successful half of the time and it's sort of the same thing here which is you know if you're empowering developers to build If you're hiring developers because they have the creativity if you believe that they're the focal point of the transformation you need to drive, then you need to empower them with The decision-making. You need to treat them like adults. They are going to have their beliefs. Some of those beliefs are going to borderline be religious in nature because that's who they are. And our philosophy is let's embrace that to an extent. Let's basically drive the modernization agenda. Let's cater to the needs of the organization, which is governance, compliance, and security. But let's give the freedom to the developers to be able to build within the guardrails that the organization believes are appropriate. And those guardrails are driven by geography. They're driven by regulatory constructs. They're driven by the industry that they're in. They're driven by the size and scale of the customer. And they're driven by the risk tolerance. But the reality is those guardrails do exist. They are important. They are important. They keep folks out of jail, and they allow developers to actually execute within a very creative environment. ([Time 0:07:43](https://share.snipd.com/snip/c3cf82a5-baa3-4c70-aaab-38500131574f)) - **Create Golden Paths, Not Monolithic Platforms** - Build 'golden paths' that offer limited, practical choices rather than infinite options. - Use central workflow and orchestration to enforce guardrails while preserving developer autonomy. Transcript: Anuj Kapur Ultimately, what we want to do is we want to ensure that there are sort of what we call golden paths. And golden paths effectively are synonymous with the few different permutations of the right way of doing things. And so flexibility and choice to an extent, obviously, as far as the organization defines it. So we don't want to integrate with everything. What we want to do is integrate with the most commonly used tools that organizations have deployed to allow a central layer of workflow and orchestration with the guardrails of security And compliance. Ultimately, the goal is build software, build it better, build it safer, build it faster, and do it within the guardrails of an organization's risk tolerance. And if we think we have a solution that does that while providing choice, not infinite choice, but limited choice that actually works within the framework of the organization, we think We're actually doing good. ([Time 0:09:23](https://share.snipd.com/snip/acd44f60-66a1-4737-8b96-9e270245a83f)) - **Choice Is Inevitable In AI Tooling** - No single vendor will dominate AI or development tooling; choice will persist as with cloud. - Kapur highlights rapid change since ChatGPT and the resulting broad set of options for developers. Transcript: Anuj Kapur Three years ago, in fact, three years and one month ago, almost to the date, we all saw what we witnessed was an inflection point in technology, which is the launch of ChatGPT. Six months ago, six months after that, we told our customers at a customer event to believe that Microsoft wins AI on the back of GPT, on the back of OpenAI, and on the back of Copilot is To sit here in 2016 and believe that Amazon wins cloud. We don't believe that there are any absolutes in technology. We don't believe that there's a single vendor that will win it all and a single vendor being synonymous with sort of high levels of opinionation and high conviction around it. And here we are over three plus years later, which is it's a toss up between who has the best foundation model. Is it OpenAI or is it Google with Gemini? It's a toss up with regards to what the best code generation and code assistant technology is. Right. I think most market participants would tell you it's Claude, right, which is from Anthropic, not from OpenAI. I think it's an open question as to what is the best integrated development environment to actually be able to do this, right? Google is making a very strong case with anti-gravity compared to the traditional tooling that exists. So even within the span, I would say, Alex, of a technology that didn't exist three years ago, which is AI and code assistance, you have choice that is very broad, very significant, and Sort of creates options for developers as to how they want to build, right? Not to mention sort of the high capability application development platforms that have recently become very popular, whether it's Replit or whether it's lovable. So in some ways, right, we're believers in choice, we're believers in innovation, we're believers in the fact that no one company that can control it all and no one company can provide The platform and tooling necessary for any organization to actually succeed. It was true in cloud, where there was never a single cloud. It was true in every other part of technology. It's going to be true in AI. And those sentiments drive this notion of choice, of flexibility. And so for us, we embrace that. We're not doing this because we don't have opinions. We absolutely do, to your phrase, right? We're opinionated where we need to be. We're absolutely flexible where we need to be. ([Time 0:11:32](https://share.snipd.com/snip/91b8f96b-3252-463b-b7e2-eea49249ee62)) - **AI ROI Is Layered And Economic** - ROI for AI depends on silicon, model token costs, and application accuracy. - Kapur says enterprises must weigh cost per token, hardware choice, and hallucination risk when adopting models. Transcript: Anuj Kapur It's an interesting one, actually. So it's a very broad topic, but let me provide one data point that I find to be fascinating, which is I think there's a debate in the industry between proprietary and open bias and open Weight models. I think I read somewhere that virtually all the startups that are approaching Andreessen, and I would say by association Sequoia, to actually build out AI based systems, typically At the application layer, are actually using open-weight models. And when you think about open-weight models, you actually think about models like DeepSea coming out of China, rather than obviously open AI, which are weighted and proprietary. So I think there are two vectors here that we need to be mindful of, which is open- models versus proprietary models and what are the unit economics of either, right, both in terms of efficiency, Scale, and cost per token. And the second is whether we're going to actually see significant innovation for both training and inference-based GPUs and how that cost model applies relative to ASIC-based solutions Like TPUs, right? And TPUs coming from Google and Tranium coming from Amazon and their Annapurna division. So in some ways, the good news is that there will be choice. There'll be choice at the silicon layer. There'll be choice at the model layer. And that will drive innovation at the application layer. And in some ways, I think we will normalize to what is appropriate, because the ROI model for enterprises has to take into account all three, which is how much do they pay for silicon? How much do they pay for tokens? ([Time 0:17:37](https://share.snipd.com/snip/103c889f-9aea-4bd9-94c4-47adadd64cb9)) - **Code Assistance Changes The SDLC** - Code assistance raises code volume and velocity while reducing marginal cost, changing SDLC dynamics. - Kapur predicts more software, faster delivery, and growing importance of DevOps teams in a multi-agent world. Transcript: Anuj Kapur Absolutely. Look, I mean, it's a great time to be in software. And I believe that ever since I was working closely with the AppDynamics teams, when the phrase used to be, your software is your business. And your ability to succeed is going to be based on whether you can transform fast enough using the power of software. So there was a phrase that I used with our customers at our customer conference, nine months after GPT was launched, which is the volume and velocity of code goes up. The marginal cost of code, which we've now said, is going to approach zero. That means you can burn down features that you had over the next five years into the next year. And if you believe that, we'd probably just get to Mars 10 years earlier, right? Which is, we are believers as a company in the power of software to change humanity. We believe the job in software is never done. And we believe that this basically empowers developers to do better, faster things and build them safer. So if you sort of put that all together, we're never going to be done with regards to the problem statement of how we can change humanity using the core vector that we believe in. And if you sort of bring that down into the enterprises, then we believe and we continue to do that there will be more software engineering that's done, whether it's done in an automated Manner or in an agent assist manner or a human manner. I think that sort of equation will sort itself out. But at the end of the day, in a competitive market, software continues to be core in terms of driving innovation. At the enterprise layer, at the consumer layer, there continues to be significant innovation in the underlying infrastructure and platforms to help developers to be a lot more productive And to help DevOps teams to be a lot more efficient. And we're believers in that. And we're starting to actually see that across most of our large scale customers that are thinking about what the future of the SDLC is in a multi-agentic world. Those conversations lead us to believe that the enterprises believe that the DevOps teams will continue to get more important, not less important. ([Time 0:20:17](https://share.snipd.com/snip/1ea53f73-7ced-4254-a1f5-42fadeef3778)) - **Invest In Outer-Loop Tooling** - Focus innovation on outer-loop tooling like testing, security, and release orchestration. - Kapur recommends building vertical point solutions that solve specific developer pain points in a code-abundant world. Transcript: Anuj Kapur We have been on code assistance as an industry for three years. And if our experience as a company that builds software with one of the larger software teams is that, you can imagine that it's going to be that for every large enterprise that is either More sophisticated or even less sophisticated than us. So I think that will continue to be a thread over the course of the next 12 months. Is that the emergence of vertical solutions within the software development workflow that take a very narrow outcome and do it really well, right? We are proponents of that in the testing world. So what we have focused on is the second order implications of code assistance technology, a world where the marginal cost of code is zero. What happens next? And so the downstream outer loop aspects around testing, around security, around release orchestration is where we play. And I think the next 12 months, we'll start to see the emergence of very specific point solutions that address a very specific pain point for developers, especially as that pain point Gets magnified in a world of code abundance. ([Time 0:28:18](https://share.snipd.com/snip/23cbfec4-e984-4cec-8422-a3a2b26df33a)) - **Secure Agentic AI Deployments** - When applying agentic AI to development, prioritize security, observability, and compliance. - Kapur warns enterprises should roll out agentic solutions thoughtfully to avoid unsafe production deployments. Transcript: Anuj Kapur Net new, you have to think about two or three things. You have to think about security, you have to think about observability, and you have to think about compliance. You do that in the traditional SDLC. You absolutely have to do that in the agentic AI world that gets applied to the SDLC. I think consumer-facing applications move a lot faster because there is more of an allowance of failure there. I think enterprise AI solutions will move a little bit slower. They will be a lot more thoughtful with regards to their rollout schedules to be able to account for some of these areas that they need to address before they put something in production. But that is squarely within the area of what our teams are working on and frankly discussing with across the leading edge and early adopters of our customers. ([Time 0:31:21](https://share.snipd.com/snip/61ebe137-b146-4ff6-8098-0f88d65a01b0))