AWS re:Invent 2025 - LSEG's migration & modernization journey: blueprint for cloud success (MAM206)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - LSEG's migration & modernization journey: blueprint for cloud success (MAM206)

In this video, AWS experts and London Stock Exchange Group (LSEG) leaders discuss cloud transformation success through the Experience-Based Acceleration (EBA) program. Bhavna Sarathy emphasizes that 70% of cloud migration friction is non-technical, with 38% of customers citing silos as blockers. Brian Quinn shares LSEG's journey, including migrating their highly regulated Collateral Management System with multi-region architecture achieving 2-hour RTO and zero RPO. LSEG has run 11 EBAs with 200+ participants, identifying 26 process improvements and removing 50 critical blockers. Magnus Schoeman provides actionable guidance on laying foundations through executive sponsorship, delivering seamlessly with stretch goals and agile methods, and enabling scaling through capability building and knowledge sharing across teams.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

The People-First Approach to Cloud Transformation

Hi everyone, thank you so much for joining us today. I'm excited that you're here to learn about real-world migration, modernization, and transformation. I've had the privilege of working at multiple large enterprises at various stages of cloud fluency. This has taught me how important migration, modernization, and transformation are, and has also given me a passion for helping customers.

Before I joined AWS, I was a product manager eager to add new features and ship new features for our customers. Our engineering team did a fantastic job of adding new features, and then I was told the deployment had to happen on a Saturday. Why Saturday? Because there was downtime involved. Watching our talented engineers spend their weekends deploying new features, that's when it hit me. Not only was our aging legacy architecture holding back providing new features to our customers, it was also limiting our engineers and our business potential.

Fast forward to today, here at AWS, I hear similar challenges from our customers: system downtime, technical debt, and brilliant teams who are trapped behind aging systems, focused on maintenance as opposed to innovation. That's why I'm so excited to be sharing this powerful transformation story with all of you today. I'm Bhavna Sarathy. I lead go-to-market efforts globally for our Experience-Based Acceleration Program, or EBA, at AWS. Joining me today are Brian Quinn, Head of Cloud Transformation at London Stock Exchange Group, who is spearheading LSEG's cloud journey, and Magnus Schoeman, Principal Customer Solutions Manager, who has worked with LSEG since day one.

As far as the agenda is concerned, we always have to start with the why: why cloud transformation? I'm going to talk a little bit about that and give you AWS's experience. Brian is then going to take the stage and talk about LSEG's cloud journey. And then Magnus is going to talk about what is in it for all of you. What are you going to take away from this talk? How are you going to implement this in your own organizations?

Over the next hour, you'll see this is what I want you to take away: those challenging migration and modernization projects are solvable. Over the next hour, you will see that with the right methodology, with the right expertise, the most complex migration and modernization projects can turn into success stories. Let's get started.

What is the number one ingredient for a successful cloud transformation? Is it technology? Technology certainly plays an important role, but it's not the number one ingredient. The number one ingredient is the people. It's all of you. You are all leaders, you are innovators, you are pioneers, and you can shape the future of technology with your ideas. You are the ones who can truly unlock the innovation necessary to transform.

Technology enables transformation, absolutely, but it's the people who drive it forward. The most successful enterprises who are spearheading cloud journeys today are prioritizing organizational readiness, stakeholder alignment, and building the right expertise from day one. For an organization moving to the cloud, 70% of the friction points are actually not technical. Enterprise transformation is not just about technology. It's about bringing the people along on this journey and making an entire organization cloud fluent.

Breaking Down Barriers: Common Challenges in Cloud Migration

Talking to several hundreds of customers around the world, there are some insights that we have gathered.

38% of the customers talk about silos and how silos are blocking their cloud success. Think about it. When you're talking about cloud transformation, you need everybody rowing in the same direction. But if you don't have people communicating and talking to each other, that will hamper progress. Breaking down silos is not just a nice to have. It is absolutely imperative for making cloud projects successful.

45% of the folks we talked to, our customers, cite that competing priorities are an issue. Your builders are focused on keeping the lights on. They have a day job, and then they're also asked to go in and work on these cloud projects. It is very difficult for builders to be balancing multiple priorities, and then cloud projects just fall to the wayside. So when teams are expected to work on multiple initiatives in parallel, it drastically reduces the productivity and causes fatigue. That's just human nature.

4 out of 10 companies lack the right AWS cloud skills. That's 40%. 40% of customers are saying that moving to the cloud, they just don't have the right skill set to do so. This is exactly why cloud transformation isn't just about technology. It's also about aligning the people, process, and technology.

To drive this point home, I want to give you a scenario. You are focused as a builder. You are focused on, you've heard about all of the great AWS services. You then move your application to a container. Great, you're using ECS or EKS. And then you have a monolith and you say, you know what, I'm going to use serverless technologies. I'm going to break up this monolith into microservices. And then you have a third-party database and you want to move that into a purpose-built AWS database, maybe RDS or Aurora or DynamoDB. And then you start thinking about CI/CD.

You then move that to, maybe you've heard of GitOps, and you move that into infrastructure automation. You are excited about the fact that push-button automation is in your reach, so you go talk to your manager. You say, hey, I've done all of this great work. Your manager is ecstatic because you've put all of this hard work in, and then reality hits you. You go get buy-in from the platform team, the security team, DevOps team. You have to get buy-in from all of them. You send out an email and then you wait. Crickets. You don't hear back from them, or even if you hear back, they're not all on the same page. And that is why, you know, I see a lot of you nodding, and you've been there. I've been there as well.

So some of the key factors that we should consider are technology, getting that executive buy-in. That makes a huge difference. I'll give you an example of executive buy-in from a CIO, CXO, whoever. Let's say they say, you know, we have seven data centers. I want to shut down two of those data centers in 18 months. It's a tall order. It's possible. That's where that executive has now mobilized all of these teams, application teams, security teams, DevOps teams, platform teams, to move in the same direction. That's what you need. That is called strategic imperative for a cloud journey, migration, or modernization.

Getting Started: Strategic Approaches to Cloud Projects

Having that buy-in provides you that air cover. That's fantastic. But the teams have to come together. The teams have to work together. And this is where, you know, one thing that I will say is it is important to just get started. And you may have heard of the saying, think big, start small. What that means is come up with a scope, pick one or two or three applications, and just get started.

And when it comes to an application, my recommendation would be to pick applications that actually have business purpose. Because if there is no business purpose or there's no customer using the application or internal customers using it, then you don't see the business value.

So once you do that, don't pick the gnarliest of applications that's very difficult to modernize. You can pick an application that's somewhere in the middle, and then you identify work streams and select your subject matter experts.

When it comes to training, given how important cloud training is, I'd like to suggest this. When you go through training, spending a few months training on AWS services, rather than doing that, think about just-in-time training. When you get trained, then you want to actually utilize that training on a project, actually make use of it, learning by doing. That is what I would recommend. Also, any time you have a community within your organization, think about sharing that information within your community. It could be a lunch and learn, it could be a hackathon. Those are all great ways to share what you have learned, and that also builds a bigger community towards the cloud projects.

Introducing Experience-Based Acceleration (EBA): An Immersive Framework for Cloud Success

So now I want to introduce you to Experience-Based Acceleration, or EBA. After speaking to hundreds, if not thousands of customers, we have discovered that migration and modernization needs a systematic approach. That's why we created this program. The program is not new. It's been around for four or five years, and we've helped a large number of customers through the program.

What is it? EBA is an immersive, agile, hands-on approach to build capability and meet those target outcomes. You can create organizational capability. Remember I talked about silos? How do you break those silos? We always go to an executive within a customer to get buy-in to run this and get all of the stakeholders within the organization aligned. Second is, you know, when you have to get stakeholder alignment and to accelerate those outcomes that you have, migration or modernization or even Gen AI or AI/ML, you want to make sure that decision making is fast and decision making is not impeded.

And then as far as builders are concerned, you get to do what you absolutely love to do: build and innovate. And you get the air cover for two to three days where this is what you're doing. You're not working on your day job. You are actually working on cloud projects. In just two to three days of an EBA party, we can build cool solutions, so you can do things that would have taken weeks or months because you're focused and you're working on the scope that was defined and you're working on cloud projects.

EBA is a truly immersive framework, and nothing becomes real until you experience it. Speaking of experience, I was in one of the EBAs not so long ago, and we also create an experience for the customer wherein a theme is selected. In this particular EBA, the theme was Star Wars. So there was a group of customers who are all there to do technical work. They're there to migrate applications, they're there to modernize applications, but they're also in there having fun and building camaraderie. And that's a big piece of what EBA is. And more and more customers in your organization then get very interested. Hey, why are they having so much fun? I want to get involved in that. And so this is why it is very successful.

And I wanted to share a picture with you, an EBA in action. This is an actual migration EBA that is going on. You'll see stickies on the wall. You'll see two application teams, automation platform, Cloud Center of Excellence, also security. How often does that happen where you have security in the room? Security is part of the building that you're doing. And there's a command center where AWS folks and also some of the customer leadership folks are available to help quickly dissipate any issues or blockers that might come along.

So just to sum all of this up, EBA enables transformation at scale for three core pillars. First one is migration, next is modernization, and the third one is innovation. In modernization, in migration EBA, we don't just plan migration. There's no PowerPoints. We just actually help customers

build and create these blueprints as you're building so that if you've migrated one application, you can do that again. You can do three, four, five, six, ten, twenty. You can use those blueprints to migrate. Modernization EBA, we have seven different proven pathways: cloud native, containers, databases, analytics, DevOps, open source, and also move to AI. That's a recent pathway. So you're actually building and modernizing.

Last but not least is innovation EBA, where you're building cool Gen AI projects. It's not a toy project. You're actually building Gen AI workloads. EBAs are not one and done. Customers plan multiple EBA parties, and Brian's going to talk all about it and about how LSEG has done multiple EBAs. With that, I'd love to give a warm welcome to Brian, who will talk about LSEG's cloud journey.

LSEG's Cloud Journey: From Planning to Production

Thanks, Bhavna. Wow, it's great to be reminded about the people aspect of cloud transformation. Often we're hyper-focused on the technology, and for good reason. This is new stuff to some of us. But it's the people and the technology that make it all happen. I'm sure many of you are at various stages of your cloud migration and modernization efforts. As Bhavna mentioned, my name is Brian Quinn. I'm the Head of Cloud Transformation at the London Stock Exchange, and today I'm going to walk you through some of our experiences and what has helped us develop our transformation.

LSEG is a leading global financial markets infrastructure and data provider, playing a pivotal social and economic role in today's world's financial system. With our open approach, trusted expertise, and global scale, we enable sustainable growth and stability of our customers and their communities. We're dedicated partners with extensive experience and deep knowledge and a worldwide presence across multiple asset classes.

LSEG is headquartered in the United Kingdom with significant operations in over 65 countries across EMEA, North America, Latin America, and Asia Pacific. We employ over 26,000 people globally. Our business spans across five divisions. We're a global leader in data and analytics, delivering financial data, analytics, and workflow solutions that empower decision making and drive market insights.

The world's essential index provider, FTSE Russell, offering benchmarks and analytics that shape investment strategies across asset classes. Risk Intelligence, a trusted partner for compliance and risk management, providing screening, due diligence, and identity verification solutions to mitigate financial crime and regulatory risk. Capital Markets, connecting issuers and investors through world-class venues and platforms across equities, fixed income, foreign exchange, and ETFs.

And Post Trade, innovative clearing, risk management, and collateral optimization services that enable efficiency and reduce counterparty risk. Each division has its own unique requirements and regulatory considerations. And today I'm going to focus in a little bit on our Post Trade division, specifically the LCH division that sits inside Post Trade.

Our business drivers that have driven us to the cloud, many of you may recognize these as they look familiar. They may look familiar to you. Business resiliency and scalability, it's no surprise that that's our top driver here with our global market, with our essential role in global markets.

Our strategic drivers also include cost efficiency and optimizing our technology investments, creating a platform for innovation and experimentation in order to build innovative solutions and quickly iterate for our customers, and reducing time to market so that as our customers come back and ask for new features and products, we're able to drive agility and produce those products quickly.

The LCH journey to AWS began in 2020 with initial planning and regulatory engagement. 2022 was a pivotal year for us as we launched our cloud program, mobilized teams, and moved our first application to AWS. In 2023, we moved our Portal and Reporting application, and this application acts as a central access point for all LCH web applications. Q2 of 2025 marked a major milestone with the Collateral Management going live. The Collateral Management System, or CMS, is a highly regulated application, and I'll talk a little bit more about this one later.

Navigating Organizational Challenges at LSEG

In Q3 of 2025, we modernized our observability strategy and reached out to AWS for some focus and guidance. Looking ahead to 2026 and beyond, we have a number of migration and modernization efforts, including some EKS migrations that are well underway. Any time we take on a new journey, we identify areas of improvement and adoption. Let me walk you through some of the challenges that we faced as we navigated our cloud journey.

Siloed teams—we all have them. They're a byproduct of the traditional operating model by design. Builders, developers, operations, and security all operated in their own ways. We implemented DevSecOps best practices, automating the platform and moving to infrastructure as code in order to reduce friction for our developers. We also had prioritization challenges around balancing the day-to-day operations with cloud migration activities, managing technical debt, especially around legacy application dependencies, application architectures, refactoring, and complex data migrations.

We have a lot of priorities, and we need to help lower the barrier for our application teams. To help with this, we leveraged a risk-based prioritization framework, moving smaller, less critical workloads first so our application teams can get used to working in the cloud and working in this new way. We built on those frameworks and those skills to enable us to drive deeper patterns and more complex workloads.

But some of our biggest hurdles were not technical. They're organizational or people-related. We had siloed teams with competing priorities working in different ways. We established a cloud operating model and a center of excellence. We also introduced a product-led approach with a defined engagement model for our business. And all this change required fundamental shifts in the way we operate, moving to a more DevSecOps way of working. The EBA was one of those mechanisms that helped us navigate some of those challenges.

First EBA Success: Migrating Consent Controller Beyond Expectations

Our first EBA was a critical learning experience for us at LSEG. It was this particular team's first EBA and their first cloud migration, and they were looking for a way to help them migrate this application. We were trying to move an application called Consent Controller, which is part of the service that clears and manages risk for our FX trades.

We were asking for help and reached out to get some feasibility studies. We were met with a lot of opinions, PowerPoints, and Zoom calls, but our application was still on-premises. It wasn't until one of our distinguished engineers came across this EBA mechanism that AWS has that things changed. It sounded like something that may work for us, like it may be the right partner that we needed to help us move this first application.

We reached out to our AWS partners and got a deeper understanding of what this EBA mechanism is. What we initially liked about it was its outcome-based approach. So we decided to just do it, just move the application, and we planned our first EBA with the AWS team. In the initial EBA, we were just looking to lift and shift our application. That was a success for us over three days, except we did that in the first day.

With every EBA, there are some stretch goals, and our stretch goals were around containerizing the application, which we were able to do. We leveraged Kubernetes and were able to deploy the application to containerized pods. Some of the other highlights of this EBA were that we were able to convert Oracle databases to Postgres, integrate back to our private cloud, and deploy and run Cucumber tests on EC2.

As our sponsor David Gavini said, the real value in this EBA came not only from moving that first application, because that was awesome and we were able to even containerize it even better, but from the patterns that developed from it, the lessons learned, and the process improvements. All of those were rolled into our migration process. This team in particular went on to run three more EBAs in the near future, so the big wins are more about what comes in the future and the processes that you're able to identify.

Testing Critical Infrastructure: Chaos Engineering Meets EBA for Collateral Management Service

In a typical organization, you submit a ticket for something, that ticket goes off, and you context switch and move to your next activity. Here in the EBA, the right people are in the room, including security, so you're able to remove blockers quickly and identify those processes to automate in the future. As we got more and more familiar with the EBA methodology, we applied it to more critical workloads and different solutions that were facing us.

The Collateral Management Service, or CMS, migration represents one of the most technically critical aspects of the LCH journey so far. The Collateral Management Service provides key foundational capabilities that underpin the core clearing products for LCH. CMS is formally classified as a critical important business service by our regulators and is managed by over 40 regulators globally, including the Bank of England. It's a pretty important application.

Given that CMS is such a highly critical application, LCH needed to recover from any incident within two hours, an RTO of two hours, and a recovery point objective of zero data loss. That's a tight window and a high bar. In order to achieve the RTO and RPO objectives, we implemented a multi-region architecture with three availability zones in each region. We implemented on-premise connectivity back via AWS Direct Connect, containerized cluster pods running on Amazon EC2 for scalability, and multi-AZ RDS for improved resiliency.

The application architecture was robust, but how do you test this? How do we test this level of resiliency for our regulators? That's the problem that we were faced with.

So we thought about it for a bit and thought maybe we'll couple an Experience-Based Acceleration with some chaos engineering. We reached out to AWS to see what they had to say about it, and they said that sounds great, we've never done that before. So they were happy to join us and dive deep here.

We launched this EBA, and the EBA conducted was over three days. We launched over ten chaos engineering experiments leveraging AWS Fault Injection Simulator. Fault Injection Simulator simulates experiments in your environment to tear down some of your infrastructure and watch your organization recover. Through those experiments, we were able to gather the evidence that we needed. Some of those experiments included EC2 instance failover and reboot, RDS failovers, network latency and severe network degradation, and EBS volume failures.

This EBA was slightly different from the last one in the sense that it was focused on a specific outcome. Being able to leverage the EBA mechanism gave us the ability to focus in on our non-production environment and run these experiments to gather the evidence that we needed. With every EBA, there is a bit of a party theme that Bob and I had mentioned earlier. This one they chose a summer theme, so the team kind of got into the summer theme, got into their costumes and outfits.

To dive into that a little bit, Bob mentioned the Star Wars theme and Darth Vader. You'd be surprised at who comes in and what the most outrageous costume is. It's a real good way of sort of breaking down those barriers between teams and bringing people together on a common level.

Continuous Modernization: Observability EBA and Building an Internal Center of Excellence

Continuous improvement and modernization is critical. As we all know, moving to the cloud is great, but modernizing is equally as important. As we were optimizing and enhancing our observability strategy, we knew that CloudWatch had come a long way in recent years and reached out to AWS to see how they could help. So we started with some deep dive sessions. We did a working backwards session, reviewed our strategy, and came up with a couple of ideas and ran some immersion days.

We were thinking, how do we get outside of an immersion day and actually get our hands dirty with what we've learned? And so an EBA was the answer. We learned over those three days this EBA was a bit different, as the goal was not to move an application. It was to discover the art of the possible here. We got off to a great start with some planning, and application teams were in on it.

As we were moving through the planning process, our application teams had their own conflicts, and so they had to pull out. Just in typical fashion, agile fashion, we pivoted, got two more teams up to speed, moved the date out, and kept going. Having the right people in the room and removing those blockers became really important for this EBA. As we were kicking the EBA off, there was an issue that was identified that would have completely put a blocker on the whole three-day process. But we had the right people in the room, and as it was being kicked off by our sponsor, we were fixing an issue in the background and moved forward.

The outcomes of this EBA were real for us. We were able to deploy comprehensive CloudWatch agents across infrastructure, developed real-time business metrics, and created some custom metrics and filters, as well as automated alerting using CloudWatch agents and SNS.

Some of our stretch goals for this EBA were centered around real user monitoring and CloudWatch Synthetics. What was great was watching two teams who had previously not worked too closely together and didn't really know each other. They were sitting on opposite sides of the room on day one. By the end of day one, they started to collaborate, and what they did was realize that if we want to tackle some of these stretch goals, we're going to have to divide and conquer. So they divided and conquered. One team took real user monitoring, the other team took CloudWatch Synthetics. They deployed them both, taught each other what they had learned, and scripted their process so everybody was able to achieve everything as an outcome. That's the power of the EBA: getting people together in the same room, looking at the same goal with the right resources. That's the magnifier here.

We've run a number of EBAs to date, and there's a lot of metrics that go along with this. We've had over 200 participants and migrated, had 215 migration celebrations, so that's a lot of cowbells. We've had over 11 EBA parties, involved over 13 teams with 12 applications and 5 migration plans. But the two most important metrics on this slide are the 26 process improvements and over 50 critical blockers removed. Those 26 process improvements are processes that have now been improved for everybody across the organization. Those processes have been automated and improved. They are things that we wouldn't normally see in a day-to-day operation but require people to move faster now.

Those 50 critical blockers that we identified are now gone. These are blockers that could have stalled projects for days or weeks, had engineers context switch, move back to whatever else they were doing, and context switch again. Every time we context switch, we lose 20 to 30% of efficiency across the board. So those are the two big metrics that come out of these EBA parties that we've been running.

We at LSEG are big proponents of the EBA. With over 11 that we've run so far, we've actually stood up our own EBA Center of Excellence inside our organization. The observability EBA that I just talked about was their first EBA that they shadowed AWS on. They worked through the planning phase, the build phase, and then the post-EBA phase, and so that team is now running their own EBAs. They do have a pretty robust calendar for 2026. They ran their first EKS migration just a few weeks ago. It goes to show you the importance of how we've embraced EBAs at LSEG. And as Bhavna mentioned earlier, leadership alignment, I can't stress this enough, is really, really important to have that top-down leadership embedded in the EBA process.

We're really lucky to have leadership across the board embedded, but Rob is our CIO of LSEG Markets and Risk Intelligence, and he was the CIO for all of these EBAs that we just ran and I just talked about. He's been a huge proponent of the EBA process, and he doesn't just give us the air cover that we need. He's always involved, and he's there for the final demo and giving feedback, and that really energizes the teams to do this more. I can't stress enough the importance of leadership in this process.

Laying the Foundations: Executive Sponsorship and Experimentation Mindset

So to wrap up, I went over three completely different EBAs that we ran at LSEG: an easy Java Spring Boot application we were migrating onto a more complex CMS application, and the observability EBA to dive deep into the art of the possible.

And now I'm going to hand it over to Magnus Schoeman, who will discuss with us how to accelerate your own transformation journey.

Thanks, Brian. As the AWS program director that was involved in a lot of the activity over the last three years, it's amazing to hear those stories, and congrats to the LCH team on those critical migrations. So at this point you could be sitting in the audience thinking, that's all great, but how does it apply to me? How can I actually apply what I'm hearing today in my organization? And in the final part of this talk, we're going to give you some hints and tips that you can directly apply to the people dimension in your transformation.

Now, we've spoken quite a lot about migration and modernization so far. A lot of the insights I'll share are equally applicable to generative AI projects that you might be running. And we're going to cover three phases: lay the foundations, deliver seamlessly, and enable scaling. You've got to build your program on a solid foundation, and that starts with strong executive sponsorship, as we just heard there from Brian. Your executive sponsors at the most basic level support you in getting the resources you need to be successful and to deliver your program. But what they also do is get directly involved and reach out to stakeholders and unblock when you hit barriers. They work across those silos and help you resolve some of those blockers.

We saw a really nice example of this recently in a generative AI delivery. The team had got stuck because they needed a new AWS service allow listing. The executive sponsor got directly involved, talked to the cloud security team, explained what we were trying to do, an experience-based accelerator in a dev environment, and offered some time with one of our security specialists and offered some time to go through our service approval documentation, which explained the security controls we had in place. The result was we got the service approved and the team could proceed.

But if you really want to set your program up for success, you need to partner with your senior leadership to create that environment where teams can learn and grow. And that starts with an experimentation mindset. And there's some really interesting research coming out of the International Business School in INSEAD that indicates that this is probably the most important determinant of team success in digital transformations. And let me explain why it's so important for your cloud transformation.

To realize the full benefits of cloud, your teams need to adopt new ways of working. They need to learn new skills, they need to learn about new AWS services, but they need to know that senior leadership has got their back and is going to support them if something goes wrong. I saw a nice example of this in one of my customers. The head of engineering at the start of every kickoff or town hall goes out of his way to explain to the teams that it's okay to try something new, and it's okay to fail if you learn something new in the process. That's an experimentation mindset in action.

Delivering at Pace: Stretch Goals and Agile Project Management

Now once you have those solid foundations, it's a case of delivering at pace to make sure that you can hold up those early wins and show the value that your cloud program's delivering. A simple but super powerful approach here are stretch goals. As Brian mentioned, your teams will have core goals around their work streams and their projects, but we would advocate setting some stretch goals that feel slightly out of reach for your teams. As a rule of thumb, if your teams feel they've got a fifty-fifty chance of hitting a goal, that's about right.

And the benefits of this are twofold. Firstly, the teams will always have a backlog. They'll always have something to go after. But more importantly, stretch goals can be a great motivator. In my experience, particularly early in cloud journeys, teams underestimate just how much they can achieve. By setting and achieving stretch goals, you can give them that self-belief that convinces them they can go even further. And we heard this in some of the examples of EBAs that Brian was talking about in LSEG.

Another really important enabler of seamless delivery is an agile project management approach, and by that I mean running your project in short sprints with ideally co-located teams focused on delivering incremental value and demonstrating what they built to the organization.

I specifically call out agile project management because sometimes I see organizations fall into the trap of thinking they need the latest project management software tool in order to be agile. Getting the teams together on a daily basis in stand-ups, looking at a Kanban board of what's been done, what's in progress, and what's blocked, that can get you a long way. It's about the ways of working as much as it is about the tools and the processes.

And when you do hit those blockers on your Kanban board, we would recommend trying to address them in near real time. Rather than just raising a ticket or sending an email that might sit in an inbox or a queue, we would recommend trying to walk over to colleagues, pick up the phone, and discuss how you can resolve the blocker there and then. That will keep the momentum going in your program.

Scaling Your Transformation: Capability Building, Knowledge Sharing, and Next Steps

Now, senior leadership support and seamless delivery will only get you so far. To deliver a step change in cloud acceleration, you need to think deliberately about scaling. But how do you do that? Well, a great way to do this is in addition to your technical objectives, your core goals, and your stretch goals, we would recommend that you force yourself to also think in terms of what capabilities you're delivering in addition to your project. What is your project leaving behind after the project's delivered?

For example, in the case of a project delivering a generative AI application, you might have an explicit goal around the capability of responsible AI tools such as Amazon Bedrock Guardrails. And when you're delivering training to support that capability development, try to shift the focus from delivering training courses to actually embedding those skills in the teams. For example, think how much more impactful some training on Fault Injection Service would be if one or two weeks after the team gets that training, they have an opportunity to apply what they've learned in a chaos engineering EBA.

Now, as your teams migrate and modernize, they're going to learn a ton of stuff. The trick is to ensure that those learnings are shared with other teams throughout the organization, so you're not making the same mistake over and over again. That way you'll go up the learning curve faster.

Now, your central functions, cloud enablement, a cloud center of excellence, cloud engineering, they are in an ideal position to spot those patterns and templates that can have a disproportionate impact on your cloud transformation. And a really nice example here is generative AI. Being able to use generative AI to reduce the complexity associated with migration and modernization activities, such as code analysis, transformation planning, dependency mapping, and documentation, that's a great way of allowing the teams to do more and go faster, and your central functions are in an ideal position to spot those opportunities to apply generative AI.

And when you do get those success stories, shout them from the rooftops. Don't ignore the power of storytelling to reinforce your foundation and your story. But you're going to have to be creative here. I don't know about you, but I'm bombarded on a daily basis with email bulletins and video clips. So you need to think of effective ways of engaging your audience.

For example, maybe in your next demo, invite a slightly wider audience than you would otherwise. And ask some of your junior engineers and up-and-coming talent, let them lead the demo, take the limelight. If you do this well, you'll create your next generation of executive sponsors and workstream leads, and they'll become your change agents that ripple out change across your organization.

A last word on scaling. Don't leave thinking about this stuff until later on in your transformation. Build it in from the outset so that you can weave these activities into your program as you progress. So in summary, lay the foundations, deliver seamlessly, and enable scaling.

I'm going to wrap up with some next steps and some resources for you to take away, so get your cameras ready.

As an immediate next step, we'd recommend you reach out to your AWS account team. Share the objectives you're trying to achieve with your program, ideally as early as possible, and ask them directly to recommend AWS services and programs that can help accelerate the business outcome you're trying to achieve. Also, ask them to be introduced to those customers that have gone through similar challenges.

With that defined outcome, reach out to your stakeholders, and if you haven't done so already, we'd recommend having a kickoff meeting with your executive sponsor to explain the expectations you have of them and where you need support. And armed with that commitment, get the right people in the room to make your cloud initiative a success. Make it real by setting a date for your next EBA and put some weekly cadence in place to keep that team on track so they don't get distracted.

And then once you're done, we'd recommend having a retro, document the findings, make it your own, and then repeat. Here's a couple of resources for you to take away as you go through those steps. So the EBA website is a great source of customer stories where customers across a number of industries have applied the methodology. Go here if you want some inspiration about what other customers in your sector have done. It's a great resource.

And remember what I was saying about the tremendous opportunity offered by generative AI to reduce the complexity of migration and modernization. Well, if you haven't done so already, please do take a look at AWS Mainframe Modernization. We're seeing some absolutely amazing results with some of our customers with this service.

A final word. If you take one thing away from today, it's get started. Pick a team, pick an application, set a date, and start today. We'd love to keep the conversation going. We will be outside afterwards, so we'd love to keep the conversation going. If you don't have a chance to speak to us, please do reach out to us on LinkedIn. Feel free to take a picture of our LinkedIn contacts. Do visit the Migration and Modernization Activation Zone in the expo. Brian's going to be there tomorrow morning, so you'll be able to speak to Brian directly there as well. And last but not least, we'd love to get your feedback. Please do provide that by the mobile app, ideally before you leave today. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.