All right, we are live. Welcome everyone. It is 12 noon here in the east coast, but to wherever you are around the world, whatever time of day. Hope it's going great. We are here to talk about a very interesting subject, which are Sitecore upgrades at scale, as we jokingly call it here, 10 dot x growth. So we're going to allow Lukasz and Kamruz Here to talk about that in just a moment. But we also do want to look out towards next week, there's going to be a whole lot of site core activity happening. The three of us will all be on location there in Nashville, probably doing some Honky Tonk as well as learning about all of site cores, great new features and upgrades of their own. We would really look forward. Anybody who's watching this right now let us know if you'll be there in the comments. It's going to be a really good full week of Sitecore’s future, but a big part here of Sitecore is present and past and carrying over. Are the need to do Sitecore upgrades when we have versions, when we have on prem. Now it's going a little bit hybrid, bringing in elements of the new, new world from the old but there are still a lot of on premise, site core customers and a lot of need for upgrades. So I think at Konabos, we've done the math. We've done about 500 plus 500 site upgrades within Sitecore. Some customers have many, many, many sites, and that's the one we're going to talk about here, because doing one side core upgrade is probably difficult and enough, and doing up to 200 at a time takes a lot of planning and forward thinking, strategic thought, and Kamruz and Lukasz here my two of my other site, core MVP compadres here at Konabos are going to walk through this. So guys, thanks so much for coming on and doing this and tell us about 10x growth after you introduce yourselves. 

Thanks, Matt, yeah, great to have everyone join us today. Really looking forward to meeting everybody at symposium next week. It's just telling these guys, a few months ago, it's actually my 10 year anniversary for Sitecore symposium, my first symposium, MVP summit as well, was that I attended. Was in 2014 in Barcelona when we had those European events. But looking forward to catching up with everyone next week, including Lucas himself, who will be joining as well. So and I never been to Nashville, so always like to go visit New Towns and new cities and go to go check out some of the history and some of the music scene there, of course, today, of course we we're headed to website for upgrades. I myself have done many, many upgrades. And I'm sure Lucas you as well, probably have done a huge number yourself. Oh yeah. And I recall doing this, thinking about doing those first upgrades, and you think, you know, it's just an upgrade. Who cares? It's going to be easy. It'll be done very, very quickly. And then experience gives you a good kick. And here we are, right. And that experience, of course, does help with these upgrades and the knowledge and future upgrades. And you learn what to look for, what not to look for, where you can skip and where you can jump, and how those things become easier with us on so a little bit about myself. I'm Kamruz Jaman. A lot of you might know me from the community as JammyKam. I've been in the CMS and dxp space for over 15 years now, been in the IT industry for 2025 years almost now. 25 years actually started as an intern back in 1999 and I'm a 12 type Sitecore, MVP, and I'm also a Kontent.ai MVP, and my name is Lukasz. Yeah. I also work with Sitecore for 13 years, or something like that, eight time Sitecore MVP, and when it comes to the CMS and the XP space, more than 15 years. To be honest, it's closer to 20 right now, but yeah, we are still counting. Yeah, I think I've done some homegrown CMSs before Sitecore. Yeah, don't have it's amazing how much experience people have in the CMS world. And when you start off in it, you think it's just very simple website builders, right? But then. You get into what you can do with it and some of the complexity. It really is an amazing tool. And a little bit about Konabos, we've been we were formed back in 20, 2017 by myself, and Akshay Sura, who was to be everybody's friends. So hopefully, you know, well, we are a dedicated and small team that it's focused in the dxp, CMS and dxp space. We're well known within the Sitecore space that we've been doing headless for quite some number of years now, before headless became the big buzzwords. And we love the composable, composable era. We love working with all the composable products. And Sitecore obviously has an extremely great offering within XM cloud, CDP, personalized OrderCloud search. For example, our team is fully remote, so we're located around the globe, but we love working with community. Community has been just part of our DNA. Those of you that will know us from the community for well over a decade now. So let's get into upgrades we've obviously gone through. Those of you that have been in the Sitecore space for a little while would have, would have gone through these Sitecore of upgrades. You know some of the history. Those of you that have been in the industry for a long time, like Luca and myself, will know some of the hurdles that you had to go through in the earlier phase, earlier software version to go through upgrades. You'll know the differences between XM XP in terms of upgrades, but hopefully you also will know some of the more recent history and how upgrades have come to be much easier these days. But why? Let's start with the why. And this is, this is actually a really strange quarter for every year this happens, this, this final quarter, everybody's everybody. Lot of our customers are looking at the site core upgrades. Site core 10.4 was released back in April, just after we were there at SUGCON, right around the date for sure. Yeah, yeah. I don't know what happened with my camera. 

Hopefully I'll come back in a second, but it was around that date that it got released. We know we had actually done a webinar back then as well telling people of the benefits of the software version, what some of the new features are, why they should upgrade, and those were a little bit more proactive, or had been waiting and pushed things off a little bit, were starting the upgrade process much earlier in this week, or at least starting this of this year, whereas planning, planning those upgrade phases. But then what happens is that final quarter rolls around and people like, Oh no, the you know, we're getting to the end of support, so we have a bit of an urgency to hit towards the end of the year. Some others are actually planning for the end of the year specifically because they know they have a, essentially a shutdown throughout their organization for some things like that for especially the second half of December over the Christmas spirit. So they want to hit that as their cut over, the rollover, the switch over, if you like, to the to the latest version. We know there's a lot of security enhancements, and we'll go, we'll discuss that a little bit. But you know, there's, there's been, obviously a number of patches and things like that throughout the year or the years, and then just security enhancements in third party libraries at Sitecore users within its own instance, there's always performance and stability improvements. This is just part of the course where Sitecore is making a lot of improvements from feedback they're getting, or new technology that they're introducing, or, you know, just removing old bits of code, which allows them to improve, improve their current code base and just remove some technical debt, if you like. There's obviously a lot of new features over the years, some big, some much smaller, but they they're always just making our lives as developers, allies, as content marketers, allies, as dxp users, much, much quicker. And of course, you want to take advantage of those features for your own against your own competition, and even just to streamline your own workforce, your own teams and your content teams. Yeah, on that slide, we want you to focus first on the definitions that are on the right side before you take a look at the table. So this is the data that is shared by Sitecore on the Sitecore product support life Sitecore page. And on the right you have the definition of the mind. Mainstream support, which gives you a false support, basically extended support that gives you security patches when they are released. And there are at least few every single year that you want to apply to your site for solutions. And the last one, which is sustaining support, gives you only a chance to ask for questions related to the Sitecore upgrade. Right after that, you have to pay for any support you need if Sitecore find people that can actually help you, right? Because the longer you wait, the biggest problem it is to get any support from anyone. So now, when we are on the same page when it comes to the definition, please take a look at the table. So the Red Square shows when and for which version the support ends, right? So on the right side, we've got sustaining support, and it shows that for site for input to you won't be able even ask for upgrade related questions with the end of this year right for the extended support, you can see that 9.1 will be supported to end of this year, and with this security patches, right so after that date, if you're on a on an older version there, will be no like Sitecore packages or sidecar patches provided to you, and that's a huge security risk, and for a 10.2 the main mainstream support who ends Also this year, right? So those are the important dates for those specific versions. If you want to check your particle version, you can always find that on Sitecore website and like, make sure that you are in a safe spot. All right, let's move on to the next slide come Yeah. So here is the example of the of the list of security patches provided by Sitecore. The list that you see here is like five or six for the latest Sitecore versions. I think that we those patches were released in last year or around that time, so you can easily find that on the right you also see the filtering options. So if with your particle version, you can filter it out and see what patches were provided for your version. And if you can double check if you have all of the all of that applied to your instance, to be sure that you are on a safe side. All right, let's move on to the next thing come Yes. So we did a like a quick review of the latest releases. You probably know that sidecar within all of the versions provides also release notes. 

So we went through those release notes to see how many improvements actually Sitecore released during those latest releases. And as you can see right the latest one provides more than 100 improvements. Provides also new tools for then 10.3 in total, there are again, more than 100 improvements, and also some new tools for SSA and new components we support, supporting next js. So in total, if you are on 10.2 it gives you more than 250 improvements, and also increase you your like or increase the chance to use the newest cutting edge tools that Sitecore provides. And, yeah, that's basically it. I think we can move to the next slide, and here we have some of the features that we listed out based on our experience, based on the release notes, features that you may be missing in your instance if you stayed behind, right, if you didn't do the upgrade sometime. So you can see here like configuration roles, for instance, that allows you to better organize the configuration changes that you are doing. You can see here as xa, right, that helps you to build websites faster and within the industry standards, standards, you can see GDPR or PI data support, right? So those really important things, or what else actually? CLI, for instance, right? This is a big thing. That allows you to use new and still support the sterilization features that and if we, if you remember, probably you remember those older tools like TDs or unicorn, they are no longer supported by anyone, right? So if you want to be on top, if you want to have the use the latest toolset, then you have to be updated, upgraded to the to the latest Sitecore versions. Kam, do you want to add anything to this? Yeah, I think the Sitecore serialization is a great tool. I think unicorn is still supported by the community, by Mike Cassidy specifically. But if you want official support from Sitecore, this is a great tool, and that hooks directly into the CLI and we have, I think, some of the things that we've been doing, specifically, we've been seeing that people take great advantage of when they're upgrading, is the move to content serialization Sitecore. Content serialization, the use of the configuration roles, especially from the older version. It just makes the setup and the setup of the instances much, much easier, and makes configuration as you're developing your own features much easier, dynamic placeholders. I know it came out a little while ago, but depends on which version you're coming from, has been really, really great to have official support for that. I know that was, I know there was some community versions of this around. But some of them worked well, some of them not so well. And then you're kind of battling against the official one versus the old one, and migrating and things like that. 

The other ones that we've seen people moving heavily into is the use of the identity server for single sign on, connecting those up into their Azure Active Directory instances, so you're not having to have separate logins for the different users, and everything's a much more seamless experience for them. And PaaS support, again, pre I think in the much older versions, it wasn't officially supported in, I think, nine onwards, they had the Sitecore, official Sitecore support, full Sitecore support for this, which, which have been great for people to migrate off of virtual machines and on prem, fully on prem data centers, moving into Cloud instances, which, which makes it much, much more scalable for them. And then in the much newer versions, it's the web hooks and the APIs or the management that they released really, really opened up the instance to make it much more API driven, much more cloud, much more you know, it fits much more seamlessly with the headless features. What we'd expect with headless, headless features, and you can take advantage of it from other systems, iPad systems, or just using some little Azure functions to offload some work off your of your service. But there's a lot of advantages that you can be take, that can be taken. They can take in terms of the features, but it's also a good opportunity to improve some of your own processes. So let's get into planning your upgrade, because that this is obviously a big challenge that, like I mentioned before running into my first upgrade, I was like, yeah, it's, you know, I've read the documentation. This seems, this seems pretty easy, and just gotta, I just gotta go and install this package and update this few files here and there. But we know that it's, it's much more of a multi faceted task that is involved, especially so when you're dealing with instances at scale, as I mentioned earlier, we've been, we've been working on some upgrades with hundreds of sites on that on that one instance, it spans multiple different environments. You're talking about development team spanning 10s, 10s, you know, sometimes 50 team members, globally distributed. And you're talking about, you know, so many different people involved at so many different levels. And there's, obviously during this time, obviously there's constant development. But you're talking about, you know, the data itself. Which integrations Do we have the code base? What version are we going from, or what version of site, where are we going to? What does the code base look like in terms of how it's set up, the architecture, what release strategies and processes do they have in place? There's been a lot. Well, here we go in and there is no release, no automated releases, so everything is done manually. And that itself is obviously painful from a release perspective, but it's also painful from what you're dealing with in terms of the different states of the different code bases of the different environments. And a lot of times things are done. Manually on each different environment, so that that's another task that you need to tackle, figuring out who your upgrade team is. Sometimes that's a different team from the Bau the business as usual team, the team that's actually continuing to provide features and enhancements to the to the current platform. 

You need to figure out who all the stakeholders are, get them involved, get them onto the time timeline, get there and figure out what their products are. Because different stakeholders, especially that scale, are going to have different priorities and different deadlines, sometimes different regulatory deadlines that they're trying to hit and trying to aim for. And sometimes that might that may clash or coincide with the timelines and the timeframes that you're trying to hit at the same time. And then we'll also do talk about a little bit about infrastructure, because that that that can be a whole another set and set of issues, depending on how much infrastructure you have, who the infrastructure team is and what infrastructure they're dealing with. If it's just a couple of servers here and there, it's different. It's an entire server farm that you're going to spin up, and they're also spinning up multiple other environments and multiple other projects. You're going to need to deal with all of those as well. So planning your journey really is a big key aspect to success. Start off with mapping your current landscape. So where are we right now? What version are we on? Figure out where you obviously you're going to want to get up to 10.4 there probably isn't any reason not to get up to the latest version, unless there's something which is extremely critical that you know causes a big conflicts. I do occasionally see people saying, Hey, we're operating from 9.0 to 9.2 or 9.3 and they obviously have the reasons, but I always, always wonder, Why are you only upgraded 9.3 instead of 10.4 they're typically like we have seen in a long time ago. I'm talking like a decade ago now, just to show some, some of my Asian experience with this, some of these things we used to it used to be very difficult to upgrade. So upgrading was a multi, multi, multi step process. So if you are on a 6.0 and you want to get up to a 6.6 for example, you'd have to go from 6.0 to 6.1 to 6.1 dot b4, to six or two, and then maybe you could jump to 6.4 and then maybe you can skip five and go to go to 6.6 and then, you know, there was a lot of similar stories between the sevens as well as zeros, one, one and twos and the early phases of the eights as well. You had to go through these multiple steps to do an upgrade that has been gone for a long time. And I think the sub Sitecore kind of suffers a little bit from some of that legacy, historical kind of pain fast when you're at the time there, you can be on eight or zero and eight or two, and you can jump straight up to a 10.4 and if you if you can't jump straight up, there are, there are definitely techniques that you can use to jump between the version. So even from a six or zero to it and a 6.6 to give you some examples, we know we've been talking to some customers that are on these early versions, you can jump to a 10.4 and there are some ways to do that. 

We'll talk about that. You'll obviously want to figure out where you are, and that does involve looking at your current code base, understanding what modules you're currently using or not using as a case may be, and what integrations you have, and specifically understanding that code base to understand, to figure out how those integrations have been made, those integrations that have historically be been introduced into Sitecore because it's such a extensible platform. How those integrations were made is a large part of how quickly you can upgrade, and that's nothing. And unfortunately, that's nothing to do with Sitecore zone code base, and again, it suffers from that, from a bad rep as a result. It's just people have made integrations in a way which might not have followed the best practices or following Sitecore of patterns for making those integrations. And then if you're on XP, you're going to want to figure out what you want to do with your XDB and the analytics data, because that is a separate upgrade step much, much easier these days than it has been historically. But you just need to figure out the plan and the roadmap for doing that as a and from that determine what does my new environment look like, what do I have right now and what does my new environment look like? Can I keep essentially, can I keep the same environment right? Now, do I need to spin up a new set of environments? Is it going to scale from this set of web apps to this other set of web apps? And then map all of this to your target platform, which should be, like I said, 10.4 but, you know, map those and that. How those features are going to go from those old, old things to the new things. How, what are we going to do with the analytics data? Do we? Are we going to upgrade it? Are we not going to upgrade it? If you're in a much older version with web forms or markers, for example, which was, you know, widely used on the 6788, versions of Sitecore, and you need to move to the new Sitecore forms. What does that mean and how you're going to get fit. One more thing Tom before we move on. On that point about the XDP and analytics data. Right from what we see, very often customers decide to just drop the data, leave it behind because it's some on low quality and not worth of time investment, but if you like, properly configured all of that, and you store a high quality data with 10, 10.4 right now, Sitecore provides the tools to grade it, even to CDP if you want, right. So this is another reason why wait. It's worth to think about moving to the newest versions of Sitecore. Yeah, just wanted to add that, yeah, the strategy. I mean the strategy, or the ways the update can be handled, right? So the first one probably not so popular, but it's still possible. So in place upgrade. What does it mean? It means that you try to use the existing environments. You do this, the upgrade in a way like a release of a new feature, right? So you just upgrade the solution, upgrade code, install the required packages, whatever is needed, whatever steps are required, and documented by Sitecore. Well, it's important to do that in place. You probably need to be very aware of your solution. State. You should be trust. 

You should have trust in your solution, in the code, and probably also have some high test coverage to identify all possible issues that can show up after the upgrade. Right? It may not work. The in place upgrade may not work for like larger solutions, when some of the libraries are deprecated, because you obviously need to rewrite some of the code that you have, and when you have multiple stakeholders, right? Because when you do this in place, you do the upgrade all of one. I mean, all of the sites, all of the applications or solutions or websites are upgraded at once, and it may not work with the stakeholders expectations. All right, so let's move on to the next slide. This is the more popular case that we see, which is upgrade on a new infrastructure. And it's probably more popular because it's safe. It gives you some time to see what is happening. Yeah. So what? What are the steps, right? So it starts with the with the clean a green foot setup, so you have new infrastructure, possibly also a more efficient one, or simply adjusted or prepared for your new architecture. If you if you plan to do some changes during the upgrade, it seems to be a better strategy if you want to clean up the sites, so you have a chance to actually clean up the code, clean up the databases, and set it up from the from scratch. So it also builds your awareness of what is inside your Sitecore solution. It's more secure also because of the reason that you already mentioned, right? But you build that trust in a solution because you know what is inside, right? You move those pieces carefully. You do you did the upgrade in a way that you have a full control over everything that you're moving. That's why it's more secure. It also a better, better way of dealing with the average when you host hundreds of sites, and we've seen cases like that, because when you have multiple stakeholders, they can, they can have some, some changes in process, right? So they're been. New sites, or maybe they are applying changes to existing sites. So you cannot just interrupt the process of release for stakeholders, for the business requirements by the upgrade, right? So with the upgrade on a new infrastructure, you upgrade what you can, and then when the rest of the changes are ready, when the rest of the sites that were in progress were released. We're moving those after the main shift. Yeah, it's probably worth to mention that it might be or usually it's, it is more expensive because of the infrastructure cost, but it is what it is, what happens when you work with really complex and large, scalable solutions, right? So this is a price for security, I guess, and flexibility that you're you have with that approach. I think the rollback, the switchback, as you said, is usually the biggest factor here, right? Yes, yeah. So if something goes wrong, you can always switch the DNS configuration and be, be again online with the site that was that was working okay, right? Yeah. I think we can move on to the next slide, which is upgrading from a very old version. Do you want to start with that one come? Yeah, sure. I mean, the specific use case here is we have actually been speaking with a customer that's still on Sitecore six, which is one of the, actually one of the first versions that I started working with. This is how old it is, and the upgrades from that older version is more tricky, right? Because it's not a this one package that it can just update and everything is, is good. 

The crazy thing, the good thing, crazy thing is you can actually still use that exact same code base from the Sitecore six instance on a 10.4 and we're talking about old technology, obviously, Sitecore. It'll be Microsoft Web Forms, asp.net, web forms, and Sitecore even supported XSLT, if some of you would call way back then, and those will actually still work on the Sitecore platform, on a 10.4 which is just a testament to the to the platform. It's backwards compatibility and the support it provides. But if you are coming up from such an old version, I think then you need to start considering your strategy. What you know, do we just want to? Want to take that existing code based and put it on for do we want to, actually, if we're going to do this upgrade, how, what are we just taking the content? Are we taking the code base? If we're doing both, then how do we do it? Because you don't want to go through all those upgrade steps. And this is where you can start thinking about, do we just migrate the templates and the content to the latest version? Think about what platform you were on, if you were on even a seven for example, if you're on an XP and you're moving if you haven't been using those XP features, then do we do what we deem the side grade right, and move across the site called XM? We know that's a that platform. It has all of those core CMS features or the page editing capabilities. It does have some personalization capabilities built in, and you can actually hook some of those personalization capabilities. Personalization capabilities into your own rules engine, custom rules engine code as well. So you don't get that longer running analytics personalization, but you do get in session and customer personalization that you can add in. So it has a lot of those great, great features in there. So you do really consider, do I go to XM, to the XM platform at that point? But also consider, do I, do I, at this point, make the shift and move over to a to a headless platform like Excel cloud, and we know that Sitecore again, to Sitecore testament and original, great architecture. In my opinion, you can take content and templates from a site called Six instance and actually migrate it up into XM cloud, and the content and the templates and everything will be there still a good opportunity to review those things, but you're not going to have to go through all of the all of that pain of the content migration and scripts and things like that. But this is just an option you don't have, right? You can stay on sector as long as you really need to or want to. No, yeah. So the upgrade obviously not always a challenge. There are also opportunities, but we will go through all of that right now. 

So one of the challenges is comp immigration. So here, based on experience, we can, like, make you think about things like, distinguish types of the content, right? So you will, you will use different approach to migrate your content for. The pages, when the content is related to the pages, when it's related to the data, sources, media items, or forms. All of those needs a little bit different approach and some awareness. And that awareness is related, for instance, to the environment specific data. So some of the forms, for instance, or some of the configuration items might be different on dev QA environments and different production. So you can just take, take it from your local and install on every single environment, right? So all of that has to be documented. You need to be aware of those changes that has to be made the thing that is very often missed are the safe actions on the forms level. So people just taking forms like a standard data, standard page, where everything should look exactly the same, and, you know, forms looks exactly the same, but the Save actions work different, right? Because they have very often some configuration on the level of the save action. They can have a different recipients defined, for instance, right? So those things happen, and there those things are very often mistakes of the teams that are working on the configuration during the upgrade. It is also worth to remember that the serialization is there to support us, right? So with, if you don't have serialization, you should have it. That's sure thing, because it will help you to maintain the templates and all of that. So the things that should be exactly the same on every single environment, right? We've seen cases also when serialization was there but wasn't used for years, or was like outdated in a way that wasn't any no longer usable, right? So fix that and then move to the average step I wouldn't probably start, sorry, upgrade process without having properly saturation. You can also use the packages to increase the control level of your migration. So instead of getting, I don't know, a backup of the database and putting that on a separate server. You can use the con packages to move side by side or piece by piece, to know exactly what you are moving to from one environment to another, or from all the environment to the new one. And it will increase your security, it will increase your awareness, and at the end of the day, will make it work, right? 

The last point from the list is some kind of trick that we use during one of the upgrades. So we had an SPE so Sitecore PowerShell extension, yes, Sitecore PowerShell extension with some a power script in it that was connected to two databases and was comparing two databases from all the new environment to show us differences. And we did that because of the like, because of the fact that there were, like many stakeholders, applying some changes on the old environment, and we wanted to keep up with those changes on the new one. And it wouldn't be possible when you when you have globally distributed teams that very often do not communicate with you to be up to date with everything, right? So to be sure that we know about all of the changes, we had that SPE script to help us with it, right? So that's kind of trick, all right. I think we can move on to the next one, which is about the integrations. So here we start again with the with configuration and the environment specific things, configuration files and configuration items. So the items we already discussed on the level of the forms actually from the previous slide, but the configuration files right? So what we very often observe is the configuration being applied directly on the servers, for instance, right? Or configuration prepared without the roles that are available on the newer versions of Sitecore, right? So we can have roles, role specific configuration added to the to the same file, and just filter out by the role of the or the environment on the file level, so you keep everything well organized, easily manageable in a single file, even for specific website, which may which gives you control. Over it and again, gives you security, because you understand what you're doing. You don't have multiple files spread across multiple folders. You have everything in one place well organized. So if you have that set up correctly, everything will go fine, probably, yeah, the next thing is also very, very often case. So when we, you do the upgrade, and you, you decided to use a new infrastructure for it, so that the most popular case, right? We very often observe that connections are closed, ports are blocked, infrastructure team doesn't know what to do, right? So you will be in the middle of all of that. So make sure that you inform people what you expect, right? You should be aware actually, of the of the all of the connections that are that should be open between the side kernels, like CD, you know, X, connect, cm, and so on and so on, even on the database level. And the same applies to the integrations, right? Because if you set up a new infrastructure, there is a high chance that integrations that were working just fine on the old environment will not work on the new one, because connections are blocked. And yeah, the external the last point is about, purely about the networking. So something that I already mentioned, right? So make sure that connections are possible. 

Yes, the code base and modules come do you want to start that one? Yeah, sounds good. So we mentioned, obviously, take a look at the current state of the code base. Some code base is a lot better than others. Some are more equal than others equally. Again, it's a good opportunity to create some clean architecture and design around the solutions. Some of the a lot of the projects we've seen have been using helix architecture, which there's very good implementations of the helix architecture and there's very bad implementations of the helix architecture. We've had some code bases with over 303 50 projects within, within the single solution. It's just, it's just, it's a nightmare to work with, it's slow, it's cumbersome. Everybody is just doing things everywhere. That alone actually does make the upgrades much, much harder, because you now have to upgrade potentially 350 different projects. So if you can take the opportunity to clean some of those up, take a look at what site core modules you're using, which and what third party modules you're using, which ones are still supported, which ones are not still supported on both fronts, web forms for matters, was the obvious one. What we mentioned, from a Sitecore perspective. But there's, there's a number of others that have, you know, that are no longer supported, for example, and as same with the third party modules, I've worked with a lot myself, where, over time, they work, you know, maybe as a redirect module, with this module, that module, and if anyone remembers that old marketplace, that Sitecore had modules would just not get updated for a number of years. Now, I and we have refused to actually work with any third party modules that are not where the source code is not openly shared. For these very reasons, at least if it's an open source or openly available module, you can go and make those updates or make the switch and to understand the code the types of serialization use. So if you, if you are using TDs, like a lot of older projects, were then good, good opportunity to make the switch over to Sitecore content serialization. If you're on unicorn, then it is still supported. So again, just figure out if you want to make the switch now or in the future, but it is a good opportunity to make those changes, but it will depend on the size of the current project and the solutions, and if, as Luca said, serialization has been used and if it has been kept up to date, and figure out what other customizations you have within the within the solution, how They were done, as I mentioned earlier, and try and determine what the breaking changes are between the versions of Sitecore. 

Sometimes that's easier said than done, and sometimes this is where the experience comes in. And you know that, you know, oh, I've got some code that does this. I know I'm gonna I know this is going to come and bite me and cause some headaches during the upgrade to the point of serialization. One, one more thing, right? Because even when unicorn is still supported, right, it won't be supported by XM cloud. So by staying on it, you're closing yourself to for an option that is out there. But it again, it depends on your. Strategy on your plan. If you want to be like fully supported, or you have you want to use solutions that fully support, also by the by the Sitecore SaaS offering then Sitecore CLI, Sitecoreization. Way to go. Yeah. So multiple stakeholders, partially, I already discussed that, right? So we, what we very often see is the that. I mean, everyone is aware of that, right? So business has their own requirements, and you can have your own plan, but then business comes and say, says that guys, we have to do that differently, or we need to change an order, right? So this is one of the challenges that you probably will need to deal with. So if you even plan the comment freeze or code freeze, what we really recommend to do when you when you plan also the upgrade process, it might be changed. And for that particular purpose, it's probably better to go that the upgrade strategy, or choose the upgrade strategy with the new environment, because you will be less it will be less problematic actually, to change the plans, change the strategy of releases, when the stakeholders decide that there is a need to release samhi, which is critical for the company, for instance, yeah, but after challenges at the end of the day, there are also opportunities. So it's not always a problematic thing, right? So let's say, let's look at on the brightest side of the upgrade. So it's a chance for you and the company actually to improve the governance. If you use the rules or the suggestions that we shared with you. You can improve your security, general awareness of everything that you're doing. You can improve the processes, right? Because every member of your team will know what is happening, where it can be the process improved. You can document all of that and share that across your team and as also teams, external teams that you're working with. You can improve your development standards, because it's a great chance to tidy up your solution right, tidy up serialization that we also mentioned, and you can reduce the piece of depth, which means that you're getting rid of old things that are still in your solution but weren't needed anymore. And upgrade actually opens you a chance to do that, especially because you will be running the tests anyway, right? So with small additional effort, you can actually do a great job on the different levels too. 

So the new real strategies, again, this is something one of the real, really, really important opportunities, right? Because we very often observe that companies, and it's really hard to believe in that, but still do deployments manually, right? And with the new infrastructure, you can also set up the CICD pipelines. You can start doing those things automatically. You can have optimized artifact prepared so instead of doing or deploying everything you can have, like art, artifacts prepared just for you with all of the data, or just this data that you really need to release, which makes the races quicker and easier to maintain. With that all being said, you can also leverage the blue green deployments. We'll not get into the details of it. I hope you know it. If not, you should and at the end, last but not least, decentralized package management is something which, with relatively small effort, gives you really great performance, because all of the bills even locally, and also for CICD, will be done significantly quicker, so it saves your time. And also with that, you will have a better control over the nugget packages that are used across your solution, which you will value the most when you have really large solution with multiple sites, and you'll also value when it comes to the next upgrade, of course, right? Because, yes, because then you just, just change the number and it's, it's out there, right? Yeah, overall stability, right? So once again, perform. Us on every single level, from development to the release to the website itself, if you will. If, let's say, let's assume that you have a large site with multiple sites, you will be doing tests right for every single site, and especially for the integrations, things like that, you will see or you for sure identify missed issues, right? So something that you are thinking that is working, you will find out that it doesn't work anymore, right? But no one was actually looking at it, because that was something released many months or years ago, right? So it helps you to identify those and fix those, improve the team member on boarding. So it's camp. 

Can you support me this one? And so one thing we have noticed is we walk into these projects, we walk into this upgrades, and they have no documentation, right? So that when there's a new developer, it's like, hey, go set yourself up and nothing is nothing is nothing is in place. You can definitely improve your team member onboarding, just through this process. Improve through this process. You can improve your own processes. Get proper documentation in there, set up, sift scripts, if that's a local instance that you're setting up, we have been for the vast majority of our projects, at the very minimum, setting up Docker scripts or development come on come on board and just use containers on their local development. At the minimum, a lot of customers are still not ready to go into containers and Kubernetes for production infrastructure. But it does give you a quick way of having a repeatable, local onboarding and setup process for developers, and then obviously, just at the same time you're you're modernizing your entire platform up to the latest version, with all the different features. There is just inherent, inherent stability built in with the latest versions of Sitecore, with a huge number of bug fixes, stability fixes, COVID refactoring that they've done in the back end for forks, for making the the platform more responsive and performing. And with that, we're kind of heading towards the end. So I would say, you know, if you haven't done upgrades before, work with a site called partner, it does hugely help reduce the risk, the risk, and to remove uncertainty, you remove the cockiness that I had when I was first starting up with these upgrades, thinking it can just be done. And I've seen this throughout my career with a lot of other developers, and they come into it, they're like, oh, okay, having that, that experience and that knowledge going into upgrades, now we know what we're going to get into. We know what to look at before the upgrade even begins to plan this. And actually, having done some of the upgrades, our future upgrades are actually so much more easier because we've set those and we set those processes up in place. We've set we've cleaned up the code base as much as we could at that time. 

We set up some of the CICD pipelines. We've refactored pieces of code where we're like, if you did it this way, it's actually going to be done in the correct site core, using the correct site for practices, and that alone will just make future upgrades a lot easier. Some of the upgrades, some of the projects that we've done recently, where they are smaller projects, but you're talking about upgrades, talking about days, rather than weeks and months. Some of the bigger projects, which were taken several months, can be done now within weeks, because we've done that work in the background. We've done that work previously to the stage. That alone gives you that long term stability, those patterns for the growth, for the development, for changes that you make into the platform, and especially if you're setting up some of those CICD pipelines that's just going to make your everyday life just way, way easier. There's a couple of resources that you can you can look into. We do have a white paper available that talks about some of the issues at scale, some of the issues we've discussed here and more. And we did host a webinar a few, few months back when 10.4 was released, talking about specific features of 10.4 and we've done this previously for 10.3 and earlier versions of Sitecore as well. You can find that on our on our LinkedIn page and our YouTube channels, but here, the QR codes for links to those specifically. And with that, we'll head into questions, and I'll give you some contact Inc, talk, wow, lot of considerations. Guys, one question coming up from this, so upgrades are still a very important thing. For the last couple of years, we've been hearing about this very pure, headless thing, right? And. Sitecore does have a lot of composable, headless products. Why are upgrades still something so prominent and also to that end, how should a customer, maybe on a somewhat newer version? Maybe, I don't know what that would be considered. I don't know eight or nine plus. How do they assess let's do the upgrade, or let's, let's, let's look at going composable, because it'll come down to need. A lot of customers are happy with where they are with the platform, what they've built. They're happy with the site called on prem install. Some customers actually do require on prem installations, whether that's regulatory or just internal reasons. Sometimes Excel cloud actually isn't available in the region that you need it to host it. We have customers in Canada that need hosting in Canada, and you can argue that whichever way you want, but that's a requirement. That's what they want. So they do require something that's installed essentially within their cloud instance. Sometimes customers don't have a need for headless capabilities, really, because we talk about omnichannel, but a lot of customers are still web only. 

Maybe they need something in the future, but they're not sure, not even that. They're not sure they know they're not going to need it for a very, very very long time. So they can still stay on prem. They can still and they can still get those headless capabilities. You can still be on prem on site called GSS, and if you need some scalability, you can buy the experience edge. People have inherent assets built up over time. They have teams built up over time with specific skill sets, and they're not quite ready for that jump to headless and XM cloud, or they don't see the requirement for for that capability right now, SAS is great like we love the upgrades and the updates and feature enhancements that come inherently with SAS. But you know, there's that's not the only consideration that you've got to make. I would add one more thing to this right sidecar is still one of the best products on the market when it comes to the dxp space. So if you are on the older version, it really makes sense to upgrade, use the newest tools that Sitecore provides instead of doing wrap up for me, because it's almost impossible to find something better right now. Yeah, and obviously, within Sitecore, own space map, we talked about this with the XM Cloud Plus talk that we did previously. Sitecore Cloud products are extremely well integrated. So the point there's still separate products, but they're they almost act like a single product when you need it, right? Because it's just a feature that you just enable and you have it in within that same system. We've seen with a lot of the issues with the composable, headless spaces, it's lots of separate products that are kind of a little bit disjointed, and we've been seeing within the industry at large that people are actually moving towards what we call the race to the middle. We talked about this recently. And the headless vendors are saying that, you know what? Customers do want a visual pay editor. They do want to be able to personalize from within the same toolset and Sitecore on their platform, the XP, their XP system, has had this since a decade. 

They are as and as Lucasz said, they are the leaders within the space. And with that, it gives you 100% autonomy to go and customize exactly what you want it to do you want it to customize based on a criteria from some obscure CRM system that no one's heard of, or some database that you have internally. You can do that with Sitecore, Sitecore XP and the rules engine that is built in. Well, that was great. I think it's a good, good primer heading into Sitecore week here symposium, MVP Summit, Partner Summit. Look forward to seeing you guys there, and we look forward to seeing the community at large. Yeah, I'm looking forward to seeing what the announcements that Sitecore make it I know there's a lot of enhancements around AI, and we do know that they've been making, and we've seen this over the previous releases of Sitecore 10, especially, they've been making this platform more and more open, more and more extensible, and yeah, hopefully I'm looking forward to it, to seeing what integrations become available from the X and XP platform into those composable spaces. Luke has mentioned that you can actually migrate cyclo XP analytics data into CDP, for example. So you can now start to really mix and match on prem capabilities with Cloud SaaS based capabilities. So look forward to hearing some announcements, and if you're going to be there, as we mentioned earlier, people give us a shout. Send us a message. We're looking to meeting up with the community. All right. Lucas, thank you as well. Thank you. Thank you guys. You.