PUBLISHED DATE: 2026-08-05 04:13:34
VIDEO TRANSCRIPT
SPEAKER A:
Hello everyone. I started my IT career 25 years ago as a business analyst in financial services. Documenting the current state understanding used to always be the first step in a multi-year legacy modernization program. I remember spending hours with my engineers in agony trying to decipher the code written by someone else years ago or trying to piece together the jigsaw puzzle based on stakeholder interviews. Fast forward to April 2024. This was the first day I saw a demo of how Publicis Sapien was partnering with a large healthcare firm and using generative AI to reverse engineer functional specifications from COBOL code. I remember saying to myself, man, I should have been born like 25 years later. My life as a BA with access to generative AI would be a cakewalk today. I'm Priya Bajoria and I'm the growth lead for AI products and solutions at Publicis Sapient. Welcome to our webinar to discuss the reality of how modernization journeys specifically for mainframe applications can now be accelerated using generative AI. Please join me in welcoming here today Pinak Vedalankar, who is the CTO for Agentic AI and the Engineering Lead for Publicis Sapient International based in London. He has been at the forefront of building out and utilizing our Agentic AI platforms as especially Sapient's slingshot to accelerate value generation for our clients on their modernization journeys. I also have with me David Yalom, who is the Group Product Manager responsible for application modernization in Google Cloud, including mainframe, .NET and other workloads. David and I first met in the fall of 24 and have been collaborating since. I'm happy to share that earlier this year, Publisys Sapient has been listed on the Google mainframe solutions page as a Gen AI partner as well as a technical and delivery partner based on our client engagements together. Delighted for our conversation to follow, so let's jump into it right away. I'll start with you, David. Mainframe modernization has been postponed by organizations for years due to risk and complexity. Can you talk a bit about why is the tech debt in mainframe suddenly becoming a board level risk instead of just an IT problem to solve? And in your experience, what is the number one reason these projects stall before they reach the cloud?
SPEAKER B:
Thanks, Pia. That's a great question. First of all, let me just start by saying we do have quite a great partnership together and very excited to help customers modernize legacy debt together with public sapiens. So that's a very loaded question. And I think there I could answer it in five minutes, 50 minutes or five hours, depending on how deep you want to go. I think that Mainframe is a legacy tech debt. Has always existed as a problem for customers. They are looking, they have been looking to see how they can modernize it for decades, right? That's a fair statement to say. And the reason is, again, multidisciplinary. It could be because of talent shortage. You know, we have COBOL engineers or experts in the legacy applications that are retiring. A lot of the knowledge, the institutional knowledge goes out with them. It could be around innovation, companies who are looking to become more competitive, more efficient, launch new digital experiences for their customers, legacy application mainstream specifically. can slow them down. It could be around security risk, right? I see platforms. We actually heard from a few customers that mainframe applications, even though the mainframe is secure, because these are applications that were created a long time ago, they are no match for modern threats. It could also be the high cost of operating the mainframe and the rigidity that those applications cycle innovation. So all of these reasons combined are becoming a pressure point for customers and I think that now with the You know, with the developments and with the increase in potential of what AI can offer around legacy tech modernization, I think a lot of customers are finally realizing that there is a light at the end of the tunnel. Before the age of AI, it used to be much more difficult, much more costly. and took a longer time to consider modernizing a single mainframe application. And now if what AI can bring to the table in terms of boosting developer efficiency and accelerating the process of magic, obviously, but it can really help and we're seeing some of that early traction from customers. I think that while the pressure for modernizing mainframes has been there for a very long time, with AI, now it finally becomes... becomes you know the customer believe they have a shot at this and they see a light at the end of the tunnel and those previous initiatives around modernization that might have been stalled or not budgeted, now all of a sudden become viable again. And I think really with the solutions that we have, your SlingShop platform, you know, and the capabilities that we offer with Gemini and some of the associated AI capabilities around mainframe. Some of those other languages, I think customers are finally see that they have like a short of modernization and it's very exciting times for the future of what we can do to help those customers, you know, address their their mainframe problem and get them where they want to be.
SPEAKER A:
Thank you, David. Pinak, anything to add there based on your conversations with clients and engagements that we are executing?
SPEAKER C:
I think completely aligned with everything kind of David mentioned, right? Basically, I think the real power is honestly understanding some of those business logic and the way some of those mainframe systems are constructed because that is where most of the organization can start, right? So eco with everything David mentioned.
SPEAKER A:
So when we are using AI to refactor legacy code, how do we ensure that the output isn't just functional, but also secure and compliant with enterprise standards and leverage what is already in place inside the organizations?
SPEAKER B:
When you think about mainstream modernization, it's not just about code conversion and translation. That is a single part of the problem, but there are multiple layers to it. It's not about just taking legacy code and converting it to modern code, say COBOL to Java. That problem is pretty much solved, right? It's about, as you mentioned, integration, green field integration, brown field integration. It's modernizing applications that can work with the new stack that already exists in the cloud, right? But also modernizing an application, but figuring out, wait, there's still some... Remnants of other applications still in the mainframe, how does this new application talk to those applications and we don't break the interdependency, right? So it is a complex problem to solve. And also, of course, making sure that the modern code is aligned with the organization coding practices and security and so on. So the way we look at it, we do look at it as a multi-step process for modernization with solutions that try to achieve the different stages in the code conversion workflow, right? Starting with, I think Pinak alluded to it, reverse engineering, first of all understanding. What is the business logic that currently exists, sometimes hidden, in the source mean from applications, right? Reverse engineering surfacing those business insight, the business rules, the way that the business actually operates from the mainframe code, generating documentation, knowledge base and mapping those application dependencies, creating this really a wiki of the mainframe and how the business... this processes operate on the mainframe as the starting point and then from there there there are multiple ways to modernize by the way you mentioned refactoring but you can think of the modernization approach it could be like to like it could be reimagination and anything in between you can take existing application and apply a deterministic approach to modernize them right whatever you have on the mainframe in legacy code gets converted to modern code that's one way but you can also look at the way that you do business and modify it update it get rid of some you know dead code legacy business rules that are no longer relevant and there's of course everything that's in between this right so when we look at okay look at the code conversion problem you start by reverse engineering and then you apply code modernization at various degrees of reimagination right to that to generate the modern code the models they need to understand the integration points that are needed they need to understand the security best practices and the compliance requirements and when we look at the overall flow all of this is baked into the workflow we provide this can be done by when you provide you know slingshot and gemini with the you know source application to modernize You don't just provide with the code, you provide it with the application dependency map, right? This spaghetti of code integration point, you provide it with a PRD that we can automatically generate defining how the target application would look like. You can provide it with the user journeys, with the user stories, you provide it with requirements to adhere to certain security best practices and standards and compliance requirements. So you need to provide all of these. together with the code together with the business rules that were extracted from the legacy applications to achieve the best result from the code that will be modernized right so first of all this is again not just a code conversion problem you have to provide this additional guidance and you know we are together building tools that can help customer achieve that and then once you have the modern application and typically not a one-shot thing it's iterative Tim, once you have the modern application, you also have to apply a very rigorous testing framework to ensure that the modern application is functionally viable and equivalent and you have to certify it before going live. We also have solutions for that such as Jura and some of the capabilities you have in Slingshot as well to test the modern application with integration points. tested to meet certain security standards and coding practices. So all of this workflow together is what we position as the way to actually achieve those requirements and those needs that you have mentioned from security to meeting coding standards and integrating with brownfield and greenfield applications.
SPEAKER A:
Thank you, David. That really illustrates the methodology that we are following in our engagements today. I wanted to have Pinak weigh in on this. While we are building out these frameworks and maturing them as we work with clients, we've seen a massive jump in context windows and reasoning and, you know, introduction of Gemini 3 Pro. For example, how has this long context capability helped us in solving the problem for cobol monoliths as an example?
SPEAKER C:
Yeah, no, I think that's a great question, right? And thanks Priya for that, right? So look, I think if I almost start with a bit of a direct observation, right, which is, I think if I take a step back. The entire mainframe modernization has been on roadmaps for like 15 to 20 years, as David alluded to as well. I personally feel it has now become more of a people problem, which is we literally, I have been in multiple situations over the last like two to three years where we had to call people back from the golf course. because they are the only people who understand that specific technology as such, right? And it is painful to say the least, right? Most, I mean, I don't know about you both, but I hardly know of anyone coming out right from the graduate, right from the college saying, I want to now master in mainframe, right? So the skills are getting scarce day by day. The subject matter expertise is kind of reducing substantially as part. is part of that right and if I kind of allude to like five fundamental enterprise problem which kind of exist and I'll come to the the question Priya on how the large context window solves and attacks that as well but the five fundamental problem that is the way we see that is there is an institutional knowledge which kind of lives in SMEs and the subject matter experts. Most of the organizations have created those plethora of tools, right? And the entire interoperability of those tools has not been thought through kind of well. lot of them are dependent on this code to code translation right what david kind of mentioned the cobalt to java that means what they are kind of doing is they are kind of literally migrating i mean the the word commonly used nowadays is like joe ball which is effectively what you're doing is you are migrating your bad practices from cobalt for example if everything is like a batch processes or everything is like a non-modular it all in the new world we want all of them to be even driven with kafka or something or we want it to be modular composable and the likes right so the code to code translation is like a one big thing which creates a lot of technical debt the regulated enterprises cannot afford failure right so how do we kind of get to this business safe change or a migration is like a one fundamental thing which like the enterprises have not solved and they are kind of afraid of and the last one is effectively focusing on transformation along with modernization the dilemma which kind of always remains from a business perspective right basically because business always wants change transformation the the tech debt and the modernization is like a one dimension I mentioned right so I think if I summarize all of that the real challenge is not migration it's effectively this institutional knowledge extraction at scale kind of stuff right and that is where the large context window kind of comes in because now like we are pretty much not limited with like a 100k 200k kind of tokens and now we can go into the millions of tokens as such right basically and that's where the entire economics of AI has kind of has fundamentally shifted because of some of the large large context windows as such basically obviously with large context window it comes with his own gotchas which is how do we make sure the chunking size is accurate the accuracy is kept into mind and the likes for example I mean we'll talk more about best practices but it definitely has helped mess with my perspective
SPEAKER B:
And if I may also chime in, I think this is a very insightful observation. I think that one of the things that we have discovered as you know, we are working together helping customers modernize is that context windows, that's that's obviously that's the baseline right that you need large context windows to address those large applications, you can do it without and of course with Gemini we have largest context window in the industry. But it's even beyond that because The very large context windows, right, they're not enough. To look at the 20 million lines of code COBOL application that's billing, right, for a large enterprise and then magically convert it into a runnable, workable application in the target modern language, right? Because you have to be able to understand there is so many of those interfaces going out, the spaghetti of code, the dependencies, the ability to detect what this application needs to talk to. to talk to and then look at those target applications and you know also I think a lot of application they a lot of customers they don't do a big bang approach for modernization obviously they want to do a continuous modernization cycle where they modernize each relatively optimistic so being able to detect a business function within this entire spaghetti of code and then to modernize that business function and then to make sure that again that modernized business function can talk back to the mainframe can talk with the new application run but all of these are associated problems that need to take care of the data structures right those applications even if you look at the code they speak to legacy databases right they speak to can speak to ims they can speak to db200 mainstream they can speak to you know data com all kinds of databases and data stores that have maybe not a direct equivalent in the modern world of cloud so you have to think okay so now i need to also reinvent the data structure and reinvent how the data is written you know files are predominant on mainframe you have system files you read and write files they're you know kind of like a part of how you do legacy applications on the mainframe are you actually going to modernize your application to read and write the files in the cloud or are we shifting the data model as well to a relational database to a key value pair to spanner is going to be you know in in beekeeper so i think that problem is also very important to address a context window that's the baseline you need large context windows but then also you need those solutions that are built on top of the LLM right such as your your infrastructure platform and such as the solutions that we are building within our application modernization team at Google to help focus the capabilities of the LLM at the specific unique problem that it is made from applications
SPEAKER C:
that's that's a very well put right david i think the that that's exactly as you alluded to right that's that is exactly why we kind of build this hpns link short right it's effectively it's not a tool it's an ai native modernization operating system right we call it like software os which is at the core of it is effectively this enterprise context graph which codifies a program fees data lineage business rules regulatory controls cross system dependencies everything you kind of mentioned right and instead of analyzing like systems file by file we create this living digital blueprint of the enterprises and that pretty much changes everything right to kind of the point that you make so no i think very well put david
SPEAKER B:
And you mentioned, you know, like you mentioned the job, right? So we see a lot of customers that we talk to the same customers right together where they say, you know, we don't want job. We don't want this. We don't want to take the monolithic mainframe application and
SPEAKER C:
Got it.
SPEAKER B:
then generate from it some Java application that looks like it was written by a COBOL programmer in the 80s. We don't want that because it's a step, but not enough. It's a half measure. It's kicking the can down the road because then you end up with new tech debt that you need to somehow eventually get out of, right? So you mentioned business rules, and I think I also talked about it, which is... very, I think, fundamental to one way to look at solving this problem, which is some applications absolutely like direct conversion, but other applications customers might say, you know, let's extract the actual business process that, you know, the rules of how the business operates from this spaghetti of code.
SPEAKER A:
let's look at those rules let's see if we want to make any changes let's validate them right because you still sometimes want to have a human in the loop right to say this is yeah this is the way the business operates and then from it give that to Gemini with your tooling as well right and as well as for PRD that includes the security compliance requirements that are needed the coding standards the user journeys the target architecture right and then build a new application from the ground up so that's one path and of course again this code translation thing exists as well and we see a lot of customers say let's mix and match right let's take some applications and just do a direct conversion that's okay for now but some other maybe more core applications in our you know you know business portfolio we do want to maybe start from a clean slate we want to maybe reimagine move from batch to real-time to streaming to you know build a digital native platform for for our next generation of customers so i think all of those capabilities are critical and this is why those platforms built on top of the llms on top of gemini right why they are things so critical for customers it kind of surfaces the best the llms to offer with additional capabilities that are domain specific to the customers
SPEAKER B:
Exactly, exactly. Yeah.
SPEAKER C:
Vinak, this could be a good segue to talk a little bit about Sapien Slingshot, which is very near and dear to my heart and how we've been taking that offering to clients, you know, alongside the Google ecosystem and partnering with clients to deliver on the promise.
SPEAKER B:
absolutely absolutely and then this is where i kind of mentioned earlier as well which is the the nuances it's not the one with the best model who will win this game is it is the one who has the best context on top of it is the one who will win this game uh in our view right and that's why we kind of build this uh serpent slingshot the heart of that as i kind of mentioned is the enterprise context graph this is effectively a living digital blueprint of of the enterprise where we store pretty much like reverse engineer your code your decisions because right now the problem is most of the decisions from enterprises are either stored in your Word documents your PPTs your your your committees and then how do we kind of move from committees to code and then kind of codify all of those dimensions and have this AI driven ontology with a semantic knowledge graph with each node of the graph kind of having this vector embeddings in the store vector embeddings for the entire we call it like a software os for the software operating system as such for the entire ecosystem right so that that's where at the heart of it is the the reason we call software os is very similar to an operating system your android or ios where we have the foundation services where we have the context graph and we have business sort of software studio and effectively a combination of those three allows us to kind of create multiple different agent orchestrators it can help me in reverse engineering the code it can it can help me in defining a data lineage it can help me in extracting business rule it can help me in making mapping the business rule to the target it can help me in doing service introductions it can help me in doing non-functional testing like performance engineering like a like high latency low throughput to put a kind of a scenario it can help me doing service introductions effectively it can be customized for that enterprise as such in a way right so along with operating system what we do is we give like a certain pre-packaged apps so which is our pre-packaged agents and then there are custom agents that you can build on top of it as such right so that's why we can i think i think one of our best partnership is actually with google because like gemini provides this large-scale reasoning capability capability which is like a so much needed from this context graph perspective which helps us to understand complex states and not just isolated code snippets as such and that's where slingshot orchestrates that intelligence into a structured auditable business artifacts and google cloud kind of provides the secure scalable foundation to operationalize it and importantly this integrates naturally into the broader modern ecosystem so I will modernize a workload that can land into a GKE or a cloud run data model feeds which will directly into like BigQuery or an AI driven analytics which extend into vertex AI or an APIs that can be exposed via APG or governance that aligns the enterprise grade controls of the Google cloud controls and it's this is not a modernization in isolation it kind of becomes a broader digital and a data strategy technology on Google Cloud as such and some of the benefits that we have seen in the CIOs is it helps them in like a more than 80% reduction in discovery timelines, reduces mean dependencies substantially, the entire business logic it preserved, the regular regulatory confidence is kind of maintained and modernization is aligned with the cloud native operating model and this is where the Google validation kind of matters quite a lot right so and then yeah and And then we recognize the cross AI, technical delivery, modernization, because it's not a theory, it's an execution at scale along with Google basically.
SPEAKER A:
Absolutely. But I think you hit a couple of like very, very, very interesting points that are so true. One is modernization at scale. You know, it's easy to take 50,000 lines of COBOL code, modernize it to something and make sure that it functionally equivalent runs well and ready to production. it becomes a much more challenging problem when you have millions or tens of millions of lines of code and all the integration that we talked about, the data structures that are proprietary, all that stuff. It's that modernization factory. It is modernization at scale. It's a problem that we are working together to solve, not that one application. That is easy. That is already solved, right? And I think that, you know, what you're saying is like music to my ears because our approach at Google is we want partners to build with with Google. We want to be able to provide you this toolbox of capabilities from super you know strong and industry-leading you know LLMs with Geminis right and the different variants of Gemini that we offer to some of the additional you know capabilities we have that are mainframe specific like some of the mainframe assessment tool capabilities that we offer partners to extend with Juran you know some agentic flows and for partners to take those building blocks and build together a workflow that can support this modernization at scale for customers so you can take those capabilities that we offer that we develop in Google and then you bring it to market with your own real world expertise and your ability to platformize it and then provide it to customers to be successful with so I think it's a really it's like a stronger together approach and I think I'm again very proud of what we've been able to able to achieve.
SPEAKER B:
Absolutely. And one thing I think that I think almost reminded me one thing which David, I always say, right, is most of the time that I have seen enterprise pretty much embark on multiple pilots and they kind of declare those pilots as success. Right. And I think I think the I think my my favorite quote, which I have written in this case is most AI pilots succeed. And that's exactly why they don't scale. Because in pilots, data is clean, scope is narrower, risk is controlled, humans are always in the loop, integration is minimal. And you remove the very complexity that exists in enterprises, so the pilot works. But when you try to scale the point that you are making, David, right, which is messy data that shows up, governance kicks in, systems don't connect, edge cases explodes, ownership becomes unclear, and suddenly what worked in isolation fails in reality, right? And that's where I think the entire looking at the dimension of like slingshot shaping. Safe and stable shot in Google Cloud like turns this modernization from a high risk migration program into a structured AI-enabled enterprise transformation, which is kind of moved from this pilot to an enterprise value. That's how it is we look at it basically.
SPEAKER A:
Absolutely. And I think that, you know, the way at least we see pilots, they are essential to do two things. One, prove the technology for the customer. They still want to see if the technology works and they want to, you know, kick the tires, so to speak, and see, oh, wait, this can actually take a legacy small application and modernize it. And I think those pilots are also useful. Those like, you know, pilot engagements useful in helping customers build the business case and understand what would a full blown modernization. organization look like so you prove that the technology is working and then you say okay and if we apply this technology at a broader scale to align with your modernization goals and inspiration this is what it would look like you know we're hearing from customers that they also want to make make sure that the business case is sensible right so the investment in modernization would be you know offset by the savings down the road right the ROI and also I think that And kind of you're alluding to what you're saying, correct me if you don't speak this way, but the way I see it is that AI is the modernization of mainstream. It's a technology and people. combined together so it's taking the capabilities that the AI offer and that the platforms offer together we've experts that are again required it's not a push button migration you have a magic solution if you just press a button boom you're in the cloud right you still need the experts to be
SPEAKER B:
Good.
SPEAKER A:
part of the process and also where we see partners being so beneficial for customers is to bring this real-world expertise working with youth mainstream, working in digital transformation with customers, right, and bringing that expertise together with the capabilities, together with AI, together with Gemini to make the modernization more viable, faster, and more cost efficient.
SPEAKER C:
Let's
SPEAKER B:
Exactly.
SPEAKER C:
talk about a real-life case study here. I'm drawn to like March of 25 when we first started to partner with the UK Global Bank as they were looking to undertake this core modernization journey. They had a bunch of legacy core banking feeds and they first wanted to understand what was embedded what was the business logic that these feeds were bringing in and so Pinak do you want to talk about how we worked on this Unisys mainframe modernization program and how we leveraged Slingshot and Google to deliver results to our client
SPEAKER B:
Absolutely, absolutely. Let me make this very tangible, right? Like a start of the last year, and then we partnered with the leading UK bank, as Priya kind of mentioned, to modernize their core banking feeds, which were running on the Unix's mainframe. The system supported high volume payments, standing order, future data transactions, regulatory reporting, hundreds of programs, hundreds of feeds, deep interdependencies between them. The challenge was not a COBOL syntax, it was embedded business logic accumulated over decades. So I think we kind of executed in a couple of phases. The first phase was effectively understanding the estate at scale. What we did was we kind of used slingshot score-to-spec capability powered by Gemini on Google Cloud. We analyzed like 237 different programs, 327 feeds and generated business-ready specifications, flow diagrams, field mappings, data lineage, feed comparisons and artifacts. And the measured impact was quite interesting because we were able to get up to like 95% accuracy. see with like 95% coverage the entire the feed analysis time reduced from like 35 days which was estimated earlier like five days as like a substantial efficiency gain and for the CIO that meant discovery risk dropped dramatically and transformation timelines compressed and then from there from a phase two what we did was like we went from understanding to redesign where what we did was we kind of extracted business rules was To our standing orders and future dated payments, we didn't translate the code, we need to redefine the capability. So we kind of left with the backlog AI agent where we generated like 200 plus structured user stories, cloud-aligned target state designs, modernization roadmaps, which kind of gave them like a substantial efficiency and accuracy, which created a clear defensible path to a GCP native implementation. why this was scalable I would say three reasons the entire enterprise context graph in ECG which I kind of mentioned that they preserved the interdependencies The second is the entire agent orchestration which enabled the parallel analysis and the third one is Gemini which provided this deep reasoning across large state and this was not an experimentation it was an enterprise grade modernization under regulatory scrutiny. From the bank perspective what that means was they moved from can we safely do this to how fast can we scale this right and because outputs were cloud ready they followed directly into the broader Google Cloud. Google Cloud Transformation Strategy, data modernization, API exposure, analytics, and the entire dimension kind of stuff. It's quite exciting, basically, a journey.
SPEAKER C:
What was most exciting for me was also the fact that as opposed to just doing a lift and shift, we were able to make the requirements fit for purpose based on today's requirements and giving that ability to, you know, reimagine. what the platform of the future would look like.
SPEAKER B:
Absolutely.
SPEAKER C:
So that was truly what I felt, you know, the business was very excited with the outcome.
SPEAKER B:
Super exciting. Yeah.
SPEAKER C:
So if you enjoyed our discussion today, please visit our booth at Google Next in Las Vegas on April 22nd, book a live demo with us on site or reach us for any kind of follow-ups and conversations. Thank you.
SPEAKER B:
Thank you.