Name: Agile SASE: The fast path to modernize remote access and DNS filtering
Uploaded: 2026-05-12T19:18:56.184Z
Duration: 47 min 40 s
Description: Agile SASE: The fast path to modernize remote access and DNS filtering

Transcript for "Agile SASE: The fast path to modernize remote access and DNS filtering": Hey, everyone. Thanks for joining. We're just about ready to get started. Alright. So the goal of today's webinar is to help you think through practical steps to modernize your security and networking specifically with the SASE or Secure Access Service Edge architecture. Now to do that, we first wanna learn where you are on that journey with the poll question. So take a look at the options on the slide and place your answer. While that's running, we'll introduce ourselves. So my name is James Chang. I've been a product marketer with the Cloudflare One SaaS portfolio for almost five years now, and I'm joined today by Manuel. I'll let Manuel introduce himself. Hi, everyone. My name is Manuel, practice leader of professional services. I'm specialized in in Cloud Fair one. I'm very excited to be here with all of you. So, yeah, thanks all for joining. Excellent. So thanks, Manuel. And we're gonna close that poll. Okay. So I'm seeing the results come in. And thanks for your participation first up. In general, I think that this distribution we're seeing here of responses is fairly representative of what we hear from customers. Although the industry has been talking about SaaS for some time now, the reality is that most organizations are still planning, piloting, and getting their first use cases to stability now. So let's explore why that is. The reality is that it's just hard to get rid of legacy architecture. So we've been talking about the challenges of castle and moat security, hub and spoke networking, and how they are obsolete in the faces of the risks posed by AI adoption today and hybrid work over the past few years. And yet these terms still seem to stick around. And managing several point solutions, whether on prem or in the cloud or a mix, doesn't make life any easier. That fragmented approach only compounds complexity and cost in the face of a growing attack surface. Now the promise of SASE has been to converge security and networking on a single cloud platform, and it's supposed to be simpler, more cost efficient, and more secure. But I would say that first generation SaaS providers have really struggled to deliver on that promise. They've effectively delivered a new patchwork of proxies and complex policies. And our goal with Cloudflare is to simplify that approach entirely to help unify security and modern connectivity. Cloudflare One is our SaaS platform that other providers promised but couldn't deliver. We eliminate the friction of legacy setups by providing one control plane, one data plane, and one infrastructure layer. And our second mover advantage in the space and infrastructure layer. And our second mover advantage in the space and track record of organic innovation has allowed us to focus on building SASE the right way from the ground up, enabling end to end visibility for every traffic flow, consistency for all on ramps and protections, and global scale to support distributed enterprises. Now SASE is a large scale architectural shift, so it can be challenging to know what exactly to prioritize. Based on our experiences with customers, we recommend organizations focus on five strategic areas listed here. Each one brings unique value. So for example, stopping phishing phishing attacks and augmenting your native provider's filters is a great way to neutralize a major threat vector. AI security is obviously one of the hottest topics right now, and SASE helps you control not only how humans are interacting with AI tools, but also govern how AI agents are interacting with your environments. Now on the right, adopting a coffee shop networking approach is a great way to reduce hardware and simplify network connectivity across branches, stores, other physical locations. Now today, we're gonna focus on the first two columns. So modernizing remote access and DNS filtering for web protection, which represent for us two of kind of the classic ways to get started with SaaS. So let's explore them a little bit further. Modernizing remote access, we would say is probably the foundational step to accelerate Zero Trust adoption and enforce those security best practices. Here, organizations typically deploy a Zero Trust network access or ZTNA solution to provide simple, secure access to your internal resources. Classic project is to replace a legacy VPN, which I think we all recognize to be too slow, too complex, and too inefficient for modern workforces. These VPNs obviously expand your attack surface, grant broad network access, and adopting a ZTNA approach helps you shrink that attack surface while simplifying life of your IT teams. So over time, you can extend protections to more users and contractors, developers, your entire workforce, and more environments like privileged infrastructure and AI tools. And in doing so, continuously evaluate those access controls based on identity, device posture, and other best practices. And we would argue that our because we're so easy to use, we help you make progress faster with those deployments, whether you're trying to onboard new teams that you've acquired through M and A or securing how developers access their infrastructure. Now the second use case setting up DNS filtering is one of the quickest wins we see organizations achieve by deploying Cloudflare One. As a technology, DNS filtering is obviously a pre established way to block dangerous and inappropriate content, you know, to enforce acceptable use policies, secure guest Wi Fi, and generally protect your hybrid workers on the Internet. Still, we see a lot of organizations struggle with point solutions that have been too costly or complex, deliver slow, unreliable browsing, or just don't block the threats they should be. So with Cloudflare, you can filter those threats and content with speed, reliability, and privacy backed by one of the world's largest global networks. So we're gonna go into some examples of how organizations have kind of adopted these use cases in tandem, in parallel, in stages. So before we kinda go a little bit deeper into that, of course, we recognize that with any security project, it's often easier said than done. So we're curious for your perspective on some of the top challenges you face and anticipate facing in tackling these use cases. So the poll is running right now. All these options can reflect typical concerns we hear from customers, especially in the early days of project. And while that poll is running, I'll just share a bit more ground rules for today's webinar. So first off, write questions in the chat. We'll be here to reply. And there are further resources available for download on the webinar platform about the topics we're discussing. And this webinar will be recorded and will be shared after the session. Okay. So we're gonna close that poll. Thank you again for your responses. I'm kind of seeing the distribution. I think this is kind of a perfect opportunity to reintroduce Manuel with some great guidance to help you navigate some of these challenges that, you know, you you've highlighted, in the poll. So I'm gonna turn it over to Manuel. Could you help us walk through how you start a professional services engagement with a customer? What are some critical steps you and your team take before you, start a migration project to ensure that it's delivered effectively? Yeah. Good point. Usually, when customers come to us, to professional services and engage with professional services, the main value that they want to achieve, is, that option. That option, make sure that they can adopt and modernize their environment as soon as possible, but also keeping the risk under control. These are may perhaps the main principles that they use to measure the success of, modernization SaaS modernization. Right? So, when I have to explain this to my parents, for instance, or somebody that is not from IT, I use the analogy of a plumber. Like, the plumber is gonna help customers to install the heating system or other appliances with reducing the risk of, gas explosion or or flooding. So we are not, of course, plumbers. We are consultants. But, actually, the idea is more or less the same. So we help to modernize. We help to adopt the solution. So customers can actually start implementing new security controls. We they can start reducing the complexity, but the migration must have a minimum, impact for the users. So that is the reason why, they usually engage with professional services. The customer can do it themselves, of course. Our platform is self-service. But by engaging with us, we are the expert. We know better the processes. We have a lot of experience working, in this type of, implementation with other customers. So, usually, the adoption is faster and with low risk. After this experience with customers, what we did was basically create kind of, what we call SaaS modernization program. And this modernization program is focused on those two principles, quick adoption, low risk. And usually, in a SaaS platform, we are gonna have multiple stakeholders in the customer side that they need to kind of interact with us, and we want to make sure that we understand very well the timelines, the architecture, the current architecture, the use case that they have, and also the requirements for each of the different teams. So we are gonna have most likely IT teams, security teams, network teams, other teams that will kind of give us the perspective of what are the requirements for for them. Right? So, in the initial phase of our normal project, we are gonna have usually the architecture and design phase. So we, discuss with them the timelines. We understand what are the priorities. And based on this, we are gonna create a project plan and a high level architecture document where we are gonna capture all this information. I think this to be honest, I think based on my experience with customers, it's one of the most important phases because if you don't do the right design at the beginning, then maybe everything that you do do later is gonna be wrong. So maybe the design didn't capture the right requirements. Or maybe instead of prioritizing the VPN migration, you are prioritizing the swag. So I think it's important to spend, I will say, at least, like, three, four different architecture workshops with the customers, understanding very well their environment. And based on that, then we can move on to the to the migration itself. And the migration planning and execution is based on the same principle of a plumber. Right? So I want to go fast. Yes. But reducing the risk. So, instead of migrating multiple things at the same time, let's do a lift and shift. So we want to migrate as possible with the same capabilities that we have in the previous platform. And then once the migration is completed, we optimize. And this is our principle. We first migrate lift and shift, and then we optimize at the end of the the project or during the project. Doesn't need to be at the end. But at least the migration itself of the the previous technology of the legacy technology should be done with similar capabilities. So if you if you think about from the end user perspective, end user doesn't will not notice many changes if you migrate with the same capabilities versus if you start incorporating new things, the the end user experience is gonna be completely different. So as an example, you can migrate the SWAG without TLS encryption because maybe the customer was not doing TLS encryption, or you can migrate the SWAG already with TLS encryption. If you incorporate this new functionality, the user experience is gonna be completely different because maybe there are gonna be some sites that don't support TLS decryption. You have to define the policies very careful to make sure that you don't impact those sites. So this is the principle of lift and shift to make sure that we don't incorporate many features during the migration, but after the migration. I I really have liked how you, you know, make things very concrete in terms of phasing your approach and kind of starting with lift and shift before moving on to optimization. Yes. Similarly similarly to the phase based approach, like, we don't want as well, if possible to migrate multiple solution at the same time. Usually, the customers prefer to to to go face by face, so prioritize the most important processes that they want to migrate. And then the pilot. The pilot is is the way how we are gonna evaluate if the solution that we are putting in place is working fine or not. So we have to make sure that the pilot includes multiple users from multiple departments, maybe from different roles, and make sure that, we test all the different applications from these users. So we really usually recommend between 510% of the total user count to make sure that we have enough coverage and in the testing that we are doing. And this is common sense. I think most of the organizations are doing their route deployment in a gradual fashion. So we don't want to do a big bang approach, deploying all the the devices at the same time. Of course, we want to go gradually. But I think this is a common sense. Everybody more or less is doing so. In the optimization part, usually, customers want to optimize security, but they want as well when they modernize the the platform, when they go to a SaaS platform. It's good. They want to modernize as well the way how they operate the platform. Right? So in here, we try to help customer to go to an automated or semi automated, approach. So instead of doing everything manually with the dashboard, if the customer is ready, we try to help them to go to Terraform or maybe automate some specific processes, with API orchestration as well. And the security, perhaps, is the most important part of the optimization where we help customers to move to a granular CTNA model or, implementing more DLP controls or more RBI controls on the SWEG. So these are kind of the most important areas that we try to optimize with the customers together with enablement, of course. Enablement is something super important. Customer doesn't need to be enabled just at the end of the project. They want to work with us hand by hand, understanding what is going on during the during the whole project and getting the knowledge during the whole project. Right? So this is the way how we usually work with the customers. Yeah. Thank you. Makes sense. If if somebody has any question, please put it on the chat, please. Yeah. Manuel, I I really appreciate how you've broken it down into very logical phases from planning to lifting and shifting to refining and the importance of pilots and testing along the way to mitigate risk. So I think it's a great time now to put some of those pieces of guidance and make them very concrete by looking at some real world examples and some migration stories that your team was involved in. So I wanna open with kind of the fur this first story, which is about a European manufacturer, thousands of employees around the world. They acquire dozens of companies annually and so, over time, have accumulated a pretty strong set of legacy tools. And so we started working with them, for the team specifically responsible for simplifying a lot of IT architecture. And they had specifically identified the need to replace their VPN with the Avanti poll secure and their SWIG, which was with, Zscaler. And so, actually, Manuel, I know your team invested a lot of time and effort into this. I want you to, you know, walk us through how you designed this project, which touched, you know, 45,000 users from 300 locations. Big, big project. Yeah. Quite large. Actually, quite large project and one of the largest thing in EMEA. We are very happy that we accomplished this, in the timeline that the customer had, but also the successful of the project was also the, again, the impact minimum impact. The customer was able to consolidate, all these solutions. They reduce massively the the operational overhead. The priority for them and, again, this is comes from the very beginning when we started to meet the customer and discuss the timelines and architecture. We clearly identified that priority for the customer, was the Ivanti BPM. Due to the all the vulnerabilities that Ivanti has, the customer want to that they don't want to be exposed to this vulnerability. Right? So priority one, Ivanti. As the customer in this case, they were, they collaborated very, very well with us, and they followed our approach of phase based migration. So we approached the Ivanti VPN first, and then we moved on with the rest of the migrations. The Ivanti VPN, basically, we had to install the Cloudflare one agent, just with the function of CTNA because we had, at the same time on the devices, the SWAG solution from CSCALER. This is a very common scenario for us. We are used to deploy the Clafware one agent coexisting with other agents, so no issue at all. We deployed a a pilot of approximately, like, 7% of the total user accounts, and we spent, like, two months approximately testing all the use cases, testing all the traffic flows, authentication of the users, making sure that we had a good, feedback from the users when, the Cloudflare one agent was installed there. And once this was confirmed, the Gradle rollout, it we spent, like, approximately four or five months doing the rollout. The customer didn't have a a hurry here to to kind of roll out quickly and fast. So we spent, like, five, six months rolling out, making sure that everything was a steady state before moving on to the next phase. The next phase was the SWEG. Actually, the phase two and the phase three are standard related because the use case is the same. It's replacing c scaler, the phase two on the endpoints, phase two on the branches. The phase two, basically, because the agent was already installed on the devices, we have a unique agent, a unique platform. The only thing that we had to do is migrate all the policies from Cisco to us. We automated this migration, and then we've changed the mode that the CloudFlare agent is using. So instead of using CTNA mode, we switched the agents the agents to full tunnel. So this means the agent is gonna start routing all the traffic, not only for the internal traffic, but for Internet as well. And the the the pilot, to be honest, was very, very successful. And in four months, the customer was able to, to replace c scaling all the device. Right? So, finally, as part of the phase two, we we started to optimize the security. Again, the we lift and shift first, and then we optimize. And here, we help the customer to implement the CTNA policies, more granular CTNA policy. The phase three is kind of interesting because we initially defined the solution for the branches, using Cloudflare one networks, like an IPsec tunnel between branches and Cloudflare to route all the traffic. But we found some limitations on the SD WAN of the customer that we couldn't integrate IPsec with their SD WAN platform. So we had to find an interim solution, and the interim solution was DNS filtering. As you mentioned at the beginning, DNS filtering is super effective, easy to deploy. In two months, we deploy 300 branches. And after the month four, the customer was able to replace the scaler entirely. And then now we are starting to implement Cloudflare one in all the different branches for this customer. Now thank you for walking us through that, Manuel. Obviously, a very large scale project. I wanted to get your opinion on the pacing of this project. I think it's very helpful that we've included specific timelines for how this played out. I wanted your opinion, you know, how does this is this reflective of what you recommend for companies? You know, we're trying to do a project at this scale. If I have to mention a project model, for the audience here, I will say this actually this customer, follow precisely the recommendation that we had for a large enterprise. Right? So, for a large enterprise, usually, a VPN replacement should take around between ten and twelve months. We can run faster for sure. Again, the shorter the period, the higher the risk. So that based on our experience, the recommendations will be ten to twelve months for a VPN migration in a large enterprise, six to eight months for a SWAG migration in a large enterprise. Again, we can do it faster. We have done this faster, but, potentially, the impact will be higher. So, this, in my opinion, will be and based on our experience, this will be a role model, in terms of a project timelines. Yeah. And I really like how you mentioned oftentimes, it's not really even the technology deployment that that's taking up the time. It's kind of managing the organizational change and mitigating the risk as you're moving along. So I actually wanted to give you a chance to kind of highlight a little bit about where this customer's deployment is today, kind of the scale at which it's operating? Well, in this picture, we can easily see the the global distribution of this customer. Right? So this customer replaced already the SWEG, the endpoints, the VPN as well. Now the customer is using all our platform for all all the traffic flows, including the branches as well. And here in this map, we can actually see the distribution of the customer endpoints. The bigger the blue dots, the more custom more users they have there in that location. But, also, it shows very well what is the distribution of our data centers. Every single dot is a cloud for data center where the users of this customer are connecting to. And the benefit that this customer got from this migration, it was massively improved in terms of performance and security. If the users that are located, let's say, in India, now they are breaking out to Internet in India and using all the capabilities that we have. Because we have all the security capabilities and all the features in every single data center, we don't need to route the traffic to a a bigger data center or t t one data center. All the data center have the same capability. So the customer is able to implement DLP, RBI, CASB, and all the features in the same local data center, and the user has a minimum latency when they break out Internet. So the customer right now is is very happy with this approach because they improve massively performance and security as well. Yeah. Yeah. It's great to highlight, you know, how oftentimes the initial pain point around performance and user experience helps introduce the customer to kind of the broader architectural benefits of adopting, SASE with CloudFlare. Anything else you wanna add on the slide or let's move on to the second example? We can move on to the next example. Yes. Thank you. Okay. Sounds great. So the second story is about a hospitality company that has thousands of properties and hundreds of thousands of, customers in hundreds of countries. And I'm sure many of you have stayed at, you know, this hotel before, and they had set a goal to move off of Cisco, AnyConnect, and Umbrella. They had been managing these disparate tools for remote access and web filtering, found that it was too complex and, you know, some of the stakeholders were not necessarily convinced about their long term trajectory into SASE with them. The hotel had also begun a ZTNA project with Zscaler for a subset of contractors, but had encountered some issues whether that was with a frustrating login experience for end users, some kind of frictions around the the how they were gonna scope expansion of their project. And so we started working with with this organization and over fourteen months, we're able to deprecate, these tools and kind of consolidate their approach. I know Manuel in particular poured a lot of, energy into this project. So I wanted to give you a chance to highlight what was your experience and how did this play out. Yeah. This this project resonates a lot to me because I I was the main consultant delivering this project, and I was working with the customer, for fourteen months approximately. It was a great collaboration with the customer teams. They are great. And, thanks to that, you the the success of the project as well. Because, when they came to us, actually, we they were involved already with presales with our presales team in the solution design for the main priority. For them, the main priority was umbrella decommissioning because they they wanted to reduce the cost of umbrella. They didn't want to renew umbrella, and we had only four months. So we quickly started with the solution design. We reused the solution design that came from presales, but actually started to validate all the use cases and all the requirements. Right? Make sure that the information that we had was right, meeting the different teams, as I said, network security, IT, confirming with them the requirements were right. And then is when we started the pilot. As we I was I was very, insistent in saying lift and shift. We follow the same approach here. Umbrella was doing DNS filtering. We don't want to change the behavior for the user end user. Right? So we have only four months. Let's do as well DNS filtering with CloudFlare. CloudFlare, one agent can work in different modes, and the one of them is the DNS filtering mode. So we implemented the agent in DNS filtering mode, same capabilities, similar policies. We migrated 2,000 users as a pilot. Everything was very smooth. DNS filtering is super, super transparent for the user because the routing doesn't change. It's just the DNS filtering in the background. So everything was smooth. We started the rollout. It was a gradual rollout in the next two months, and everything was okay. So we the customer was able to decommission umbrella in the the timelines that they had before the license expire. Umbrella, like, was installed at the same time as Cisco NECONNECT. So when we installed Cloudflare one agent, we make sure that the Cloudflare one agent could coexist with the Cisco NECONNECT and with the CSCALER c c c CPA. Right? Customer in the phase two approached the VPN migration. They had two VPNs, one for the, end user, for the corporate users, and another one for the contractors. So in the initial phase of the phase of the phase two, we started, modifying the configuration for CTNA. So we implemented all the policies, the best practices for CTNA. We migrated some policies from CiscoER, and then we started to do the pilot. And similar to the other, projects, we did as well at switch switch on the on the CloudFlare one agent mode. In this case, the the the agent was in DNS mode. We had to switch the agent to CloudFlare, tunnel mode. Right? So we did a pilot as well between 2,000, 4,000 users. But here, we spend a little bit more time because this customer has a lot of people traveling, hotels and different places, and the captive portal in some cases, we found some small issues. We engaged with engineering. The professional services team helped the customer to escalate this to engineering. The engineering was very active in fixing the issues. And to be honest, after the month nine, we started the rollout, and the customer was able to to replace as they had in the timelines, the Cisco AnyConnect and the Cisco LCPI. The phase three is what we call optimization. Again, following the principles. Right? So lift and shift and then optimization. We started the priority for them, optimize the security, helping them to to reach that, security model that they had in mind. We helped them to document and architect the security model, the zero trust model. And we helped them not only with the target, but also with the transition. Sometimes for the organizations, one of the most complicated processes is not only the migration itself, but also how to go to that security model that I have in mind. Right? So how I go from zero access control to a granular CTNA access control. So we help them to with this transition, building some policies that are a little a little bit more broad at the beginning and then gradually narrowing down the control to make sure that they were able to achieve the principle of least privilege. That is one of the main principle of zero trust. Right? So we help them as well, and this is still ongoing, to migrate the blue code proxies. They have blue code proxies in the regional hubs, the different, Asia, America, where the code the hotels are connected to. So the hotels are sending Internet traffic through the regional hubs, and from there, they go to Internet. And they had blue code proxies on those regional hubs, so, why we don't want to consolidate everything. Right? So they established an IPsec panel between the original hubs and CloudFlare, and now they are inspecting all the traffic on CloudFlare for the connections that come from hotels. Let's say, guest Wi Fi's, IoT devices in the hotels, or different devices in hotels that connect to Internet. And finally, and this is an integration that we perform for them, they had Palo Alto Firewall. Well, they still have Palo Alto Firewall in their data centers as, to segment the internal network. And they wanted to have, if possible, visibility of the user ID when the user is remotely connected to Cloudflare, access an application that is in the internal network. So if you have here data center and the user remote, the connection passes through the CloudFlare data center sorry, through the Palo Alto, through the customer data center. And they they didn't have this visibility, so we integrated the user ID of CloudFlare work with the Palo Alto user ID implementing a worker in our workers platform. So the worker will pull the data from CloudFlare and will send the data to the Panorama API. And now they have full visibility. And even on top of that, they can actually implement user based policies from the Palo Alto firewalls as there as well for the traffic that comes from Cloudflare. So this is it was a great project with many different processes improvements, but also, I think with some integration that we're very successful for the customer. Absolutely. I really appreciate you kept walking through those different phases. Obviously, a huge scale project and one that where you're dealing with a lot of incumbent technology. So kinda curious for your perspective. With a project of this scale, you inevitably run into frictions with integration. I'm sure that's a very top of mind concern for the organizations you're working with. Maybe could you highlight for me how you typically navigate integration challenges? The opportunities for integrations with Cloudflare are endless. So we have many, many options, to be honest, because all our platform is API based. It's fully API, completely programmable. So you can implement some logic, somewhere, and we prefer to use as well our workers platform. With workers platform, workers AI, and workers VPC. Now you have all the opportunities to do some type of logic in the worker that will consume data from Cloudflare and send data somewhere else or the other way around. Right? Consume data from somewhere else, do the logic, do the consolidation of the data, and then send the data to Cloudflare. The user ID is one example with Palo Alto, but we I remember now recently working with a customer that they wanted to integrate their radio system with Cloudflare. So to make sure that they they wanted to segment the internal network with CloudFlare. So they had a radio system in internal network authenticating the devices. And based on the the the radius authentication, they wanted to implement segmentation with CloudFlare. So we the same, built a worker that consumes the data from the radius to understand what is the ID of each of the different devices. And based on that ID, we applied security policies to the to the traffic. Right? So this is an example. Other examples that are very common as well is when we implement zero trust, one of the main principles is that we want to to know the device posture of the devices, what is the health of the different devices, to make sure that we don't allow access to internal applications to devices that are, I don't know, with the antivirus disabled or external devices. Right? So, with workers, we consume data from external systems or external MDMs or external, XDR solutions and ingest data in the device posture of Cloudflare. So we have some native integrations that work very well, but if the customer has a different MDM or a different device posture or a different XDR, we can actually use workers to consume data and ingest data in Cloudflare, and this solves most of the problems that, maybe the customer may have. Yeah. I love you sharing those very specific examples of how, you know, customers are taking advantage of the composability, the programmability of our architecture to make sure SASE meets their business logic as opposed to kind of just trying to force fit, some some policy. So thank you for sharing that. I have one other follow-up question on this project. What I love about this story is how this professional services engagement could really met the customer where their business objectives were in terms of, meeting things, meeting timelines to replace an incumbent ahead of an upcoming renewal. So I also appreciate how this company really started small in kind of designing how they went from pilot to further migrations to rollouts to this large scale deployment. So maybe could you point out what you felt this company did very well in terms of designing pilots gradually rolling out and progressing their deployment? Yeah. Totally. I I I think I repeated myself several times about the same. Right? But, but here, we had the evidence of a customer that, thanks to the pilot, we, uncover, an issue that we didn't identify at the very beginning. And this was hap this happened on the phase two when we replaced the VPN. They they had many people traveling on the globe, and they had some issues with captive portal and as well connecting to airports or the the airplane's Wi Fi. If we had tested only with the people that participated in the project or maybe some people in the IT team, sometimes from the IT organizations, and I was security engineer before, so I know very well how the organization usually, run these processes. If you run the pilot just with the people next to you in the IT organization, most likely, you will not identify all the issues because IT uses specific applications. Maybe the IT team doesn't travel much. So, is you you are gonna be an you you will uncover specific use cases related to IT, but you will not uncover, for instance, use cases related to the commercial people or to the finance or to HR. So they have different use cases, different different, applications. And the reason why in this project was very relevant, the pilot, was because thanks to that, we were able to uncover this. We fixed the issue before impacting more users. Because if we had rolled out altogether, all the user will be affected by this and the the the project will not will not be be is that successful. Mhmm. I think that's great advice. So I'm gonna kinda move forward. So far, we focused a lot on how your team collaborates with customers into planning and those initial state phases of deployment. I wanna look beyond that close engagement phase. And so how does your team set up customers to manage CloudFlare on an ongoing and stable state basis? Yeah. For the customers, as I mentioned, before, the the SASE modernization is not only the technology migration. It's migration as well of the different processes that they have internally. Zero trust is a culture culture shift. Right? It's not we are coming from, solutions that are kind of allowed by default and basically are allowing the users to connect to Internet and allowing the users to connect remotely. But now we want to make sure that everything is enforced, the security are enforced, that we have a good operational model as well for that. So when in this migration from legacy systems to VPN to SASE, sorry, We have to make sure that the for the customer, it is easy to maintain this platform. And because we are gonna have, different teams collaborating in the same platform, maybe the network team is gonna manage the the connectors, Maybe the security team is gonna manage the policies, and the IT team is gonna manage the endpoints. We want to help them as well to collaborate and and build an operating mode model that works for all of them. So, usually, we help them to transform the operational modeling at Terraform fully automated. Sometimes, they just need some help in automating some specific processes. So let's say the customer wants to automate the CTNA policies somehow or giving them some, easy way to automate the CTNA policies. Or for instance, integrating IOCs from external parties, from external partners with Cloudflare. So we can automate as well this process. So this is an example and similarly on the security model. So as I mentioned before, for them, it's a hard transition from a zero access control to a full access control. We have seen customers with more than 5,000 applications or 10,000 applications internally. How you are gonna build policies for 5,000 applications if you don't know the application. Right? So sometimes customers struggle to understand this, how to start building, the transition from, again, the zero access control to a full CTNA model with granular control at least privileged access. Yeah. And it is quite a journey. So I'm kind of curious how do you help your customers maintain momentum as the project progresses? I think one of the you know, there's obviously a technical component. There are other organizational and interpersonal components as well. Yeah. Yes. This is a very good point. This the these projects and all the the migrations in general in IT sometimes generates some frictions in terms of prioritization. So I remember, like, two months ago working a project, with one of my colleagues, and the the security team wanted to force TLS decryption, from the very beginning, right, during the migration. But the previous customer the customer had Palo Alto before, and they they didn't have TLS encryption implemented in Palo Alto. So, and they we had only three months to migrate all the solutions to CloudFlare because, again, they didn't want to replace, the to pay the the license of Palo Alto. My my proposal was don't do that. Let's go lift and shift. Because if we incorporate new features and this was kind of some friction between the security team and the network team. So we try to, based on our experience, explain the pros and cons of doing this phase based approach. Like, first, we do the migration and then maybe we of course, we want the customer to achieve all their goals in terms of security, but we can do that just after the migration. Right? So and, precisely, this customer now, they finished the transition to Cloudflare, and now we are working with them to make sure that they can implement TLS decryption, DLP, and RBI, all these capabilities. Similarly, in the helping them as well to define role based approach for maintaining the platform. So, the IT team maybe doesn't need access to the security policies, and the network team maybe doesn't need access to the distribution of the Cloudflare one agent. Right? So we help the customer as well to find a role based model access control to make sure that they have limited access to their specific sections so they can conduct collaborate and contribute to the management of the platform with, with minimum risks as well. Yeah. Mhmm. And so finally, I wanna talk about how your professional services team transitions off an engagement. What does that transition look like? What are some key resources you share to help customers manage things on their ongoing basis? Yeah. As you as you mentioned, we don't want to leave the customer, alone with zero, kind of documentation or so we what we usually do is, first of all, we like to work with the customer from the very beginning to the end, hand by hand. Right? So altogether, from the very beginning when we do architecture, during the implementation of the configuration, during the migration, during the testing, or the troubleshooting, All of these, usually, we have weekly basis calls with the customers, make sure that we transfer the knowledge rapidly to make sure that they don't have to just receive the knowledge at the very end. But on top of that, of course, we deliver to the customer user a high level design document, during the architecture phase. So the customer has a picture of what is the solution, and this solution is gonna this document is gonna drive the whole solution. This document is gonna be updated along the project following the standards. And and then we give the customer as well a configuration as build document. We send a snapshot of all the different configurations, including if the customer implemented Terraform, we help we help the customer to build a Terraform code, and we give the customer as well the Terraform code for them to integrate with their CICD pipeline. Additionally, sometimes, for instance, for the IT team, they want to have, troubleshooting guides for work. More or less tense, troubleshooting guides are the ones that we have in the developer docs. So we create for them some troubleshooting guides. We create maybe some videos that you can share with the cast with the end user, I mean, how to troubleshoot WARP or how to how to take the the the the normal actions of the Cloudflare one agent. So these are some of the resources, but at the end, what we want is the customer to to feel comfortable handling the whole solution themselves. So the enablement, I think, is super important. So, that is the reason why I like the idea of working, together with the customer, for instance, as I we did doing with the with the hotel company, in the previous, slides. Yeah. And thank you so much, Manuel, for joining this webinar and kind of sharing, you know, your best practices and how you navigate these specific engagements. I think being able to zoom in on specific examples and have your battle scars and get, working with these customers has been really, fascinating for me. So I appreciate it. And so, you know, we we had the opportunity to zoom in on some specific examples and kind of look at how to structure specific projects. I wanna kind of wrap up by zooming out a bit further. So today, we focused a lot on modernized remote access and enforcing web protection with DNS filtering. But what does the road ahead look like beyond these priority use cases? And so longer term, we see and recommend customers follow a journey like this. It's typically three phases and 10 or so individual steps. Now the top row in white are steps focused on consolidating infrastructure and tooling. In the bottom row, organizations are focused on improving their security posture, enforcing zero trust. And each phase can incorporate to some of the use cases we talked about just on a kind of wider scale and time horizon. So in that first phase, modernizing remote access by adopting z t and a. We talked about this a lot today. Phase two is modernizing workspace security with one unified platform. So that includes deploying DNS filtering. Certainly one part of this, but we see organizations go further, whether that is deploying email security or enforcing AI usage controls and guardrails. And phase three is around modernizing network connectivity and how, physical locations are often connected so that they can consolidate within a single vendor SaaSy approach. Now this often includes adopting coffee shop networking to simplify end user experiences and reduce hardware at branches, stores, and so forth. And with each phase, organizations are progressively extending more granular visibility and controls across more environments. But of course, ultimately, the exact order of operations is up to you. Right? I think Manuel highlighted how we can help you meet where your business priorities are on your timelines. And so if you wanna go deeper, we recommend certainly the SaaSy reference architecture, which includes a lot of technical steps and best practices as you would adopt CloudFlare. There are also a number of different ways to engage with us, whether that's through an architectural workshop where you can think through some of the phasing that Manuel highlighted earlier. We also have a new test drive workshop where in a session, you can get into the Cloudflare platform and start tackling specific use cases. So thank you so much for joining today, and we really appreciate your attention. And thank you, Manuel, of course, for for your perspectives.