Adobe Commerce 2.4 Upgrade Workshop

Transcript

All right. All right, hi everyone again, and welcome to the Adobe Commerce Upgrade Workshop in partnership with Merkle. I see we have a lot of people on the line today and more joining as we speak. We have a very full and informative session planned for today. So I’m gonna jump right in and get us started. This session is designed to be interactive, so we encourage you to ask questions in the question box on the GoToWebinar control panel throughout the presentation. Just type them in there, and we will do our best to answer as many of those for you when we reach Q&A. I wanna make a quick couple of mentions for housekeeping items before we get started.

We will be recording this webinar to be viewed on demand and shared with other members of your teams that may not be able to attend today. Audio is routed through your computer. Please ensure that your speakers are not muted. If you can hear me, you know you’re good to go. Our participants are in listen only mode, so please submit your questions by typing them in the chat box on the far right of your screen. We’ll have a couple of polling questions throughout the session. We encourage you all to participate as these will help drive future learning series. And as mentioned, we’ll also have a Q&A today. So please feel free to start asking throughout the presentation. If your question is not answered, please follow up with your customer success manager.

And lastly, at the end of the webinar, please complete the one question survey that will pop up on your screen so we can continue to deliver the best and most relevant information to you at these events. All right, next slide, please.

All right, so let’s jump into the agenda. The goal of this workshop is to help you with the planning, preparation, and executions of a commerce upgrade, understanding the importance of the UCT tool and how to leverage, tips, tricks, and best practices for upgrading. Next slide, please.

All right, onto introductions. We’ll start with the supporting facilitators who are here to answer your questions in the question pod throughout the session. My name is Yol-Ling Cort. I’ve worked in managed and cloud hosted services for over a decade in both technical and account management roles. After three years as a customer success manager for Adobe Commerce, I’m now Adobe Commerce’s strategy and operations manager who focuses on initiatives to improve merchant experience and satisfaction. Michelle Su is a product marketing manager on the Adobe Commerce team who has focused on customer adoption and success over the last year. She has over seven years of marketing and communications experience and previously worked in the health industry before joining Adobe.

Igor Satorenko is a lead technical architect for Adobe Consulting Services in EMEA. He’s been with Adobe Commerce for over 10 years and has curated and managed a variety of projects for merchants. He is passionate about pushing the boundaries and raising the technical bar for both his teams and his clients’ teams.

Sandra Gonzalez-Mangana is a senior product manager who has over 15 years of experience working in product. She focuses on initiatives that reduce total cost of ownership for Adobe Commerce merchants. She is passionate about innovative and optimizing and is always looking for ways to iterate and improve upon products and their associated programs.

All right, so onto the star of this workshop, your main speaker, Ryan Street. Ryan is an Adobe Commerce architect with over 10 years of experience with the platform. He holds certifications across both generations of the platform and has launched dozens of Adobe Commerce sites. He currently works as a technical architect for Merkle, helping clients launch complex solutions on the Adobe Commerce and Adobe Commerce Cloud platforms. All right, so let’s kick this off. I’ll now hand this over to Ryan.

Thank you very much, I appreciate it. So welcome, everyone. Glad you could all join us today. Just as a quick reminder, may feel free to put any questions into the questions box for the QA at the end. But let’s go ahead and start into our upgrade workshop. So first of all, we’re gonna start off with a poll question. You’ll see that pop up on your screen here, and it’s, do you feel prepared to upgrade to 2.4.4? So just quickly select one of those options, really appreciate it. We’re gonna leave it up here for about 10 seconds or so, and then we’re gonna jump in here.

Okay, so thank you very much for those. Let’s go ahead and get into this. So first of all, all right, so why upgrade to 2.4.4? Depending on where you are, or if you’re considering the platform, you might be asking yourself this question, and sometimes the first thing that kind of pops into mind is well, you know, maybe I wanna get some more functionality or maybe I just wanna stay PCI compliant, but there’s actually a lot more to it that you wanna consider when you’re thinking about upgrading to the latest version of the platform. So when we think about this, you wanna think about this in three main pillars. We’re talking about future proofing, innovation and scalability. So with future proofing, we’re talking about leaning more on independent services versus core updates with the 2.4.4 version. This means fewer upgrade cycles. So now you’re not gonna have to worry and focus so much on upgrading all the time, so much as focusing on innovating for your platform, which comes into the second pillar, which is innovation. 2.4.4 has all kinds of great new innovations for commerce, including B2B commerce capabilities, merchandising, experience management, payment, cloud functionality, expanded GraphQL coverage and PWA studio enhancements. And then finally scalability. So there are new features available in 2.4.4 that help your site run faster. They handle things like larger catalogs and handle greater transactions through scale. Digging into this a little bit deeper, we have our future proofing, our innovation and our scalability. So when we’re talking about future proofing, we’re talking about upgrading less and innovating faster. There’s gonna be less frequent upgrades moving forward as of 2.4.4 and onward. They’re gonna be opting for more service-based features to keep your site secure, scalable and compliant. We’re also gonna be talking about innovating faster. So updates and new features will be delivered by a SaaS so your features will be available to you faster than through the normal upgrade process alone. So now instead of having to try and weigh, well, I wanna get this new feature that comes out, but I’m kind of far back in my upgrade process. Am I gonna have to try and balance, figure out whether or not I wanna go through the upgrade just to get to that new feature? With 2.4.4 and onward, most of the new updates and stuff will come mostly via the core. And all of the extra features and the innovations will come via SaaS. So you’ll be able to flip those proverbial switches, if you will, and get those innovations a lot faster than having to go through what can be sometimes be considered an arduous upgrade process. Then we talk about innovation. So we’re talking about better experiences. This is things like AI-powered product recommendations for personalized customer experience. GraphQL coverage for more admin and B2B functionality in the latest versions. PWA studio personalizations and promotions coverage. Now for all those people that are on headless out there. Also operational improvements. Asset and inventory management improvements, purchase approval workflow improvements, payment services. And then platform help. The SWOT tool or the Site-Wide Analysis tool and the Performance Monitoring Dashboard are also available to you. That you can get a quick holistic overview and a snapshot of exactly what the health of your site is, which will really help you decide and make business decisions going forward on how you want to maintain the health of your platform. Scalable and fast. So optimizing site performance and then also the benefits of PHP 8.1. And not just from a developer perspective. The developer features are great, but also the speed and stability that comes with PHP 8.1. More scalable and more stable. That’s what we want from our performance enhancements. So we are more scalable now in 2.4.4. You can process over five times the transaction volumes with our asynchronous order processing, which is a big increase. And then managing complex catalogs up to 10 times larger, excuse me, compared to previous versions. This is especially relevant to those with very large catalogs out there. Maybe you’re a B2B merchant or you’re a vendor helping out B2B. And you have catalogs that can range maybe in the millions. And sometimes you have to make certain sacrifices in order to facilitate a large catalog such as that while not sacrificing performance at the same time. Now we have the ability to leverage more features because you can have more complex catalogs over the previous versions. And then of course, more stable. You have a 32% improvement in site health index scores from our SWOT tool or a site-wide analysis tool as said before, and a 34% lower chance of experiencing site outages in 2.4 compared to 2.3. So let’s talk about planning your upgrade. Let’s talk about actually digging into what it’s gonna take for you to get from where you are to where you need to be. First of all, let’s take a look at the 2022 release calendar. There are a number of different key dates on here but there are two really important ones and those are those red dots there. September 8th of 2022 is the 2.3 EOS or end of service date, okay? As of 2.3 on September 8th, it is no longer going to be serviced or supported. Another important one is November 28th. The 240 to 243 end of service date hits on November 28th. So it’s very important to know that unless you’re on 244 right now, you started back in April or even in beta, you are going to reach an end of service date by sometime by the end of this year, okay? Now don’t get, you know, don’t get, you know, like crazy and upset or anything like, oh my gosh, I have to scramble and make all these adjustments and stuff like that. It’s not a problem because there are plenty of paths that you can take while still remaining PCI compliant and getting the latest security patches and there are plenty of options still available to you depending on your version to be able to perform this upgrade to 244, okay? So we have a couple of different recommended paths and options for you for depending on where you are to where you need to be. Now, there are different options depending upon your version, whether on your 2.3 branch or the 2.4 branch, there are pros and cons with each route and they will differ from, you know, client to client, merchant to merchant, or depending upon your specific circumstance. Having these different options available to you will help you plan out what the next year is going to look like for you, as well as level of effort, how you need to manage your teams, what kind of effort that you’re going to need to start to put together for this. So let’s talk about if you’re on 236 or lower, all right? You have two main options available to you that we recommend. You have the 236 lower, you have the ability to do two main things. So option A is you make what I call the big leap. This is when you go from one kind of major version to another major version. The big leap is basically option A where it’s where you start to work on getting to 244 right now. Essentially, you want to, you know, start to work and go through all the upgrade process necessary to just get to 244 now that it’s in general availability. Option B, depending upon certain circumstances, you might not want to take that option. So you have the ability to go to 237 patch two and then patch three and patch four. And then what you can do is offer what’s called extended support. Extended support is an additional service offered by Adobe that extends for one year beyond the end of service date. And this allows, this gives you more time to be able to plan for your upgrade. Basically, it allows you to better facilitate depending upon your market needs, your budget, your resources, your capacity, to be able to decide when you’re going to make that big leap, if you will. Like I said, there are pros and cons to this. So if you decide to go with the patch route, you’re gonna delay access to future enhancements in 244. There’s a real cost associated with extended support. So that’s gonna cost you are going to accrue as you’re going through and going on the extended support route. Don’t forget that if you’re on the two, three branch and you’re going on the extended support route, that you have to talk to vendors and people who provide your third party modules because they might also be in end of service as well. And so you might have to talk about extended support options with them on top of the extended support from Adobe. The level of effort is going to be higher since there’s gonna have more breaking changes between versions. This is what I talk about when I talk about the big leap. And so the longer you wait, the further out the versions are gonna be. So even the more effort is going to quote unquote pile up, if you will. Now, that’s not to say that this is a bad option. That’s just to say that these are the different pros and cons because there are plenty of valid reasons why you would want to go on something like the extended support route. Maybe your proverbial Christmas time is in the summer and you don’t want to do a major upgrade right in the middle of your peak season. Maybe you’ve already allocated things like budgets and efforts for the year and you don’t have any capacity left to be able to perform a major upgrade like this. That’s why the patch option and extended support option exists. This gives you flexibility to be able to choose the best time for you to get to 244.

All right, so what if you’re on 237? Okay, so 237, you follow the patch route and then you go to 244 or you have option B, which is to continue on the patch route and then go to maybe let’s say the 245 route, depending upon when you have the availability to do it. Once again, this all just goes into your budgets and your options, but basically you want to get essentially to 244 or later. Now, you might just go from a patch route as seen here with option B and then go to 245 or depending upon when you want to make the big leap, if you will, you might continue to stay on a patch route and then go through extended support. So 240 to 243, this is important because remember, the end of service date for 24 through 243 is in November of this year. So you need to start thinking about getting onto 244 and or 245 here very soon. So once again, get onto 244 now, if you have the availability, especially if this isn’t your peak season, you might want to consider going to 244 now. This isn’t going to be as big of a leap as the 23 branch to a 24 branch. If you’re on 243 and you’re going to 244, there are some services and stuff that you need to consider, which we’ll talk about a little bit later, but you don’t have as big of a leap. And then obviously you still have your option B, which is continuing to take patch routes and either going through a patch three and then to an extended support or going to a 245 branch or the 245 release in August. So once again, there is pros and cons for each of these routes and you have to decide what’s best for you. Now, what if you just upgraded to 243? You just finished the upgrade, you went through the effort, you know, you wipe the sweat off your brow, you say, finally I’m done and ah, here we are with 244, what am I supposed to do now, especially when you have a looming end of service day? Well, you still have options available to you. First of all, you continue on the patch route and get ready for the 245 release if you had just upgraded to 243. So you can go ahead and, you know, you can wait on your 243 as you’re getting ready for 245 and just go to 245. Or if you have spent a significant amount of your budget effort and time into getting to 243, you can still opt for the patch route and through on into extended support. So as you can see, there’s a lot of options available to you and depending upon the version you’re on, you still have plenty of time. So there’s no need to worry, there’s no need to panic, but you do need to start thinking about strategizing and getting ready for upgrades depending upon the version that you’re on. So let’s talk about that. Let’s talk about what an upgrade strategy looks like for getting to these latest versions. So it’s into three main pillars. We have our project kickoff, we have our annual planning, and then we have our upgrade execution. So we’re talking about project kickoff, we’re talking about monitoring the release schedule to stay informed of when the latest updates are due. We saw the release calendar for 2022 that is going to continue on for each year. And so you can start to get ahead and start to make your planning for that. Set your upgrade expectations. If it’s been a while since your last upgrade, the time and the cost is going to be higher to catch up for this first time. And then once you’re up to date, the amount of impact costs, time, and effort is going to be lower to stay with the incremental upgrades. But you need to set those upgrade expectations ahead of time. If you have a lot of customizations, if it’s been a long time since your upgrade, you’re going to have to plan that capacity in a much larger aspect. And then you want to define when and how to plan for upgrades by staying up to date and putting upgrading as part of your development strategy. One thing I always like to mention to merchants and vendors and anybody out there is that upgrading is a process, not an event. It is always an ongoing thing that you need to be cognizant of. If you think of it as just an event, you’re going to find out that you’re going to start to fall behind again, because you can check that off your list and you can kind of put it in the back burner or forget about it. If you always treat it as a process, an ongoing thing that never quote unquote ends, this allows you to always stay ahead of it and to not have to worry about things like end of service dates looming when you may not feel prepared for that. And now you have something like that to be able to help facilitate it. Annual planning. So every year come together with your partners, your merchants, your stakeholders, your decision makers, and start to plan what your upgrade looks like each year. And you need to do this annually. Coordinate with your partners and merchants as well as with your vendors, because some third party modules and third party functionality may not be continued on into the latest versions. They may have adapted, they may have pivoted. You may have found a better one. Maybe there’s different things about the vendors that might make you want to switch. You need to do this as part of your annual planning. Yearly platform health. Include whether or not it’s relevant to stay on the patch path or a new version path. And there are times and circumstances when those decisions may be one or the other depending on where you are in your annual strategy. Think about your yearly goals and KPIs. Are the things that you’re measuring for success included in these new versions? Will the versions help accelerate those goals? Is one of your goals, for example, more performance, better throughput, better, higher ROI? Are there certain things that are available in these latest versions that will get there automatically that you don’t necessarily have to develop for or you have to get the IT department involved for? Can the platform’s latest version already help you meet those yearly goals? If so, you need to take that into consideration in your annual planning. And then assigning budget and release windows. You need to take into account Adobe’s release schedule and of course it’s EOS dates. And then we get into the upgrade execution. Now there are five main steps of this and we’re gonna dig into them in a little bit more detail. So the first thing I wanna talk about from an upgrade execution standpoint is your analysis. So there are a couple of things that you wanna think about when you’re analyzing the platform in its current state. And your first thing you wanna think about is the scope of your target release. Are you making the big leap now or are you doing incremental patches until you get to a big leap later when it’s a little bit more advantageous for you in your schedules? If that’s the case, you need to always be thinking about that. You should be performing analysis on each release, big or small, big leap or patch release. You should be doing these analyses on each of them. So think of the scope of the target release. What’s covered? What isn’t covered? Does it fit into your goals and workflows? Think about those things when you’re thinking of what the scope of this target release is. There might be times when the scope of the target release doesn’t quite align with what you’re trying to do in things like annual planning. And so you might go on a patch path until that time comes when you want to make your big leap. Think about the upgrade compatibility tool results. If you are unfamiliar with the upgrade compatibility tool, we’re gonna be talking about that a little bit later.

Upgrading your services to support your target version. So what are services? These are when we talk about things like PHP, MySQL, MariaDB, Redis, ElastiSearch. You need to think about what that target version is gonna be. Is it gonna be a significant effort because you have an on-premises support and going through that process leads to a lot of change management and making sure that everything is vetted and that it’s in the official support cycle of your IT department? Well, if that’s the case and it’s gonna take longer to do that, you might wanna consider something like a patch release to stay on your supported service versions until you get to a point when that kind of stuff is supported by your IT department. Extensions, third-party modules. You know, document what each module does, taking an inventory of this. If you’re doing this for the first time, it can seem a bit daunting, but you will be so happy that you did. Once you take stock of what your modules are and what they do, you get a much better snapshot of things that you have that are still needed, things that aren’t needed, and some things that could be updated, removed, or replaced, okay? Should you replace any modules that are covered natively in the target release? Because, hey, that feature’s now available in the 244 version. This module, I don’t need to support anymore. Are there any compatibility issues with the target release? Hey, they’re going to 8.1 inside of 244, and this particular custom module or this third-party module, is it covered by PHP 8.1? Are the requirements fulfilled by this module still relevant and valid? This is where I say documenting your modules is actually a huge benefit, because maybe early on in the lifecycle, you’ve created modules or you’ve used third-party modules that were needed by a business decision or a business need at one time, but those business needs have evolved over time, and that particular feature has become redundant. Well, it might behoove you to actually remove that for lower technical debt and an easier path to upgrading, and this is a perfect time to do that. During your analysis phase, you could say, actually, I can remove these things and not even have to worry about them as part of my upgrade process. So-and-so modules are, they’re out of date, and it might require a significant amount of upgrade to get to PHP 8.1, but I don’t really need them anymore, so all that effort was just automatically saved. Same thing goes with custom modules. A lot of the same questions, are they being replaced? Compatibility issues, requirements being fulfilled. Composer packages in dependencies as well. What version should you target with these dependencies? Are there any compatibility issues or conflicts that come whenever you’re working with 244? Are some packages being removed? Are you leveraging those packages that are being removed? How are you going to mitigate that? You need to think about these things when you’re performing your analysis.

This slide kind of helps you get an understanding of some of the things that you can use to document what we had just talked about with the analysis. Hey, let’s list all the services that we’re using to work this platform, the current version and the target version that we’re using. Do you have certain notes like, hey, we wanna use RabbitMQ, but it is supported, but it’s not being used currently. Do we wanna consider possibly implementing that along with this upgrade? Are there certain things that are going to cause conflicts with other things that we have? Composer 192 versus 2.0. Are there gonna be some plugin incompatibilities with some of the things that we’re using in our own deploy management or our release cycle that might cause issues? You need to take these things into account. Are you not using Elasticsearch and you’re going to a version that is using Elasticsearch? You need to account for that and you need to make sure that you’re setting up that service ahead of time. And then also with the third-party modules and the custom modules, getting these things documented and having this list here to show exactly what things are doing will help you get a really good snapshot like I mentioned earlier. The module name, the vendor who provides it, what the current version is, what is the business requirements or functionality that this module is fulfilling? Is it compatible with the latest version? Are there any issues you’ve identified, whether it be through the upgrade compatibility tool or otherwise, maybe in something like system logs or otherwise? In the latest version, is this gonna be a native feature? Has this module become redundant? You don’t need it anymore. And then an action for it. Hey, I’m gonna keep this or hey, I need to upgrade this to make sure it’s compatible. I need to replace this with something else because maybe it’s been abandoned and the project’s no longer supported and that violates something like PCI or I just might need to remove it. Hey, it’s a native feature in the latest version. I don’t need this anymore. And the same thing can be done with your custom modules as well. What are the business requirements? Is this still required? What are the actions we need to take? And then after you’ve performed all of your analysis, now it comes time for the development and QA. I love this slide because the first line defines it so perfectly. It is the easiest to describe it as the longest to execute. And we have it as one of the smallest like bullet points on the slide. I just really liked that because it is such a significant effort to do the actual development and QA of everything that you’ve been analyzing up to this point. This is the bulk of your heavy lifting here. This is where you’re actually going through and performing your upgrades, getting your compatibility down, making sure that everything is where it needs to be. All of the business requirements are still met. You’re not inadvertently breaking something by removing something, making sure that everything is compatible, going through the QA process end to end and ensuring that everything is still functioning as intended. One of the things that we do want to mention though, is that a lot of people really don’t know about the amount of tools and tests available for the platform. So using these can greatly reduce the overall effort in your dev and Q&A for the upgrades, as well as going forward, not just the upgrade and then you’re done, but your further new feature development, your maintenance and support. These types of tests and tools are huge benefits to you. And I highly recommend that you introduce your dev teams to different tests and tools that are available. We have a link here. This slide and this presentation will be available afterwards. I highly recommend you go to it. It’s the application testing guide. It includes all kinds of different features and it includes things like how to use things like the Magento functional testing framework, the API functional testing framework, integration testing, performance toolkits, static code analysis stacks, such as mess detectors, code sniffers, unit tests. You can use these not only in your upgrade process, but your ongoing development going forward. If you can catch a bug early on in the process, it saves you such a significant amount of effort later on down the line by catching it early. And these tools and these tests help you facilitate that.

So the next thing is UAT and launch prep. You have done all the development, you’ve done all the QA. Now you think the site is where it needs to be according to your upgrade. So you’re gonna review and validate the site end to end. You’re gonna decide whether or not you wanna use a maintenance page. After you’ve been performing the analysis and after you’ve gotten everything kind of defined, are you at a point where this upgrade’s only gonna take a minute? Or is this upgrade gonna take a certain semi-significant amount of time, maybe an hour or so, because you have to upgrade services and it has to go through a big process? Well, if that’s the case, you might wanna consider whether or not you wanna use a maintenance page to show whether or not you’re offline. If you’re down for maybe only a few minutes, you might not need to put in that kind of effort to have a custom maintenance page. Defining your launch steps, including things like cron processes, external services. You need to make sure that your uptime monitors go down so you don’t get pinged relentlessly while you’re actually performing your upgrades. You also wanna define what those launch steps are. Who’s responsible for what, what step in the process they’re gonna be responsible for it and what kind of mitigations and rollback plans need to be put in place. Every single instance of the platform is going to be a little bit different because there are different business needs that are required for your particular business. And defining these launch steps will help you get a much smoother actual upgrade, or I’m sorry, a launch process itself. And you want to also start testing and refining dry runs of that launch. You wanna go through a mock launch, if you will. You wanna start to say, okay, everybody get into a call and step one, so-and-so does it, and then it goes through the different steps. And then you might find holes or problems in the system. Oh, so-and-so upgrade failed throughout the process. What’s our rollback gonna be? Okay, well now you know that through a dry run and you know what that rollback or that contingency plan is going to be for when you actually go through the launch itself. So you’re gonna deploy to production using your processes defined in the previous step in your launch prep. You’re going to follow the best practices for launching, which we’re gonna talk about a little bit later in this workshop as well. And then you have your post-launch. So you’ve gone live, everything is great, everyone puts on their party hats and everyone cheers and it’s great, but you’re not done yet. So you wanna make sure that you’re checking your analytics and logging to ensure there are no unexpected issues. Are there, is there a performance issue that you didn’t foresee before? Is there something that you are seeing in the logs that you didn’t see previously and you haven’t caught in something like QA? Is that particular thing worth noting and that you should take action on or is it a follow-up item? Make sure to turn back on and monitor all of your monitoring tools, your uptimes, your new relics and stuff like that, and keep an eye on those things during your post-launch. You know, when you’re first getting into an upgraded platform, sometimes there’s gonna be situations when the cache needs to warm up in certain pages, so you might see little hits here and there, but as the cache gets warm, things should return to normal and or usually better, especially with the 244 version.

So preparing your upgrade. So let’s talk about some of the things inside of 244 that you need to account for when preparing to do this particular upgrade. Okay, platform changes in 244. So first of all, 244 is now available so you can all go out and grab it today. It includes support for PHP 8.1, which is great. It’s a great new version. There’s a lot of good features in it from a developer and a performance perspective.

Support for 73 has been removed. That is a very important thing to note because if you’re going from something like 243 or the 240 branch and going to 244, support for 73 is not there, so you are going to have to upgrade the PHP service to 8.1 in order to make sure that you’re running 244. This is an important part of this. There are updated versions of dependencies such as jQuery, Elasticsearch, Redis, MySQL, et cetera, et cetera, and depending upon what your needs are you might have to make upgrades. There’s support for a new open search suite. So in the 244 branch, you only have the choice of Elasticsearch and pretty much nothing else. On the 23, Elasticsearch was optional and 244, it’s required, but now 244, you have your option of either OpenSearch or Elasticsearch. You can choose either of those. And then also there is the removal of certain legacy and redundant libraries, such as Laminas libraries, NPM libraries, miscellaneous JavaScript libraries. It’s important to know which one of those are being removed because if you have a custom module or a third party module that is dependent upon those, you need to take that into account when you’re performing your analysis and to make sure that you have a mitigation plan for that. So a couple of the prerequisites that you want to think about when you’re talking about going to 244. You are required to use Composer 2, and you need to also, so there’s also a plugin that’s available for Magento that you also have to leverage when you’re performing your upgrades to Magento. You have your choice of OpenSearch or Elasticsearch. Like I had said previously, if you are on cloud, they will begin using OpenSearch. The on-prem installations out there will also have their choice of Elasticsearch or OpenSearch. You can use either. MariaDB 10.4 or MySQL 8.0, 8.1 like we had mentioned, RabbitMQ, Redis, Varnish, and Nginx, all at these current versions.

So a couple of prerequisites that you need to think about when you’re getting ready to perform the upgrade. So first of all, you need to make sure all of your software is up to date, all of your services are up to date, all of those types of things. Your PHP version is the latest version, your MariaDB is all correct. All of those types of things need to be up to date and ready for 244. Okay, you need to verify that your Elasticsearch and or OpenSearch is installed while you have your choice of either, they are still required for the platform. So you do have to have at least one of them. They are required still to run the platform. Just like in the previous two, four versions, you are required to use Elasticsearch. Now you have your choice to be there, but one of them still does need to be there. You need to verify all the prerequisites are fulfilled, things like your appropriate settings, things like your U limits on your servers and all those types of things. There’s a link here that documents exactly what prerequisites you need to have. Verify your cron jobs are running and then verify your appropriate system and file permissions as well.

Understanding the scope of upgrading. So read through the release notes to understand the scope of your upgrade. Are there backwards incompatible changes? Are there new things that are implemented in here that conflict with a custom module that you have written? You need to understand the scope of what the upgrade is. If it’s just a patch release, you need to understand what’s being patched, what’s being changed, what security features are being implemented. Does that conflict with anything that you have in your system? Read through those release notes and understand exactly what you are upgrading to. You need to verify, like I said, your backwards incompatible changes. Are you leveraging something that is no longer going to be available in this latest version? Now this isn’t so much in things like small patch releases, those don’t have backwards incompatible changes, but certain releases, especially if you’re going from like a 2.3 to a 2.4 branch, there are going to be a number of backward incompatible changes. So you need to understand the scope of that when you’re performing this. You’re verifying your third party module compatibility. Are there certain things that are no longer going to be compatible with the latest version in conjunction with things like the release notes and your backwards incompatible changes? So if so, you need to reach out to your vendor and understand exactly what their plan is in going forward for what their particular module is or their service is and how it’s going to ensure to be in alignment with what you’re doing with your upgrade as well. And then verify your custom modules, just like your third party modules that are all compatible as well. Backwards incompatible changes, non-API changes, things like that that do need to be working and compatible for the latest version. So a lot of these and understanding these can be a daunting task. However, there is a tool that helps you accomplish that pretty easily and that is called the UCT or the Upgrade Compatibility Tool. So I want to go into a quick poll question right now is are you familiar with the Upgrade Compatibility Tool? Let’s put that on screen and let’s just give it about 10 seconds to see and just if you could answer it real quick, it’ll help us better facilitate some stuff. But are you familiar with the Upgrade Compatibility Tool? Have you heard of it before? All right, thank you for that. So what is the Upgrade Compatibility Tool? So what the Upgrade Compatibility Tool is, a lot of these bullet points which I’ll go through here in just a second, but for just in layman’s terms, it is a tool on the command line that you can run against your code to find out if there is any issues in your current code base. So it analyzes your instance for potential upgrade issues. It checks a current version against your target version and that’s a really cool feature. You have a version that you’re on, let’s say that you’re on 243 and you want to go to 244. It checks your current version against your target version and says, hey, going from this version to this version, you’re going to run into these issues with these particular modules in your system, okay? And it lets you know what those are. It reduces the effort required to understand the scope of your upgrade. If you have a large amount of incompatible changes, that might change what your level of effort is going to look like to upgrade. It could be larger or smaller than you had originally anticipated, especially when you’re going through the analysis process of the scope of your upgrade. So this tool helps greatly reduce the effort required to understand that. It also provides a clear direction of priority to resolve compatibility issues. They give you different severities in which you should probably perform these different changes or these different issues that arise when you’re running this tool. And so you can say, oh, okay, so I have a number of different, I have XYZ critical errors, errors, and then warnings. I can do the critical issues first, so I can prioritize that. And maybe I can defer something like warnings to something maybe like another release or something like that, or maybe a fast follow. So that way you don’t have to worry about changing every single line and going through every single piece of every single line of code of maybe what could be hundreds of modules in your particular platform. You can prioritize exactly what those are. And it also offers HTML capabilities to help visualize your incompatibilities. If you have stakeholders and business leaders and decision makers that need to understand exactly what level of effort is required, these HTML capabilities can be sent to those people in a very easily digestible way. They don’t need to go through a whole lot of jargon. You don’t need to send them screenshots of your command line or anything like that. It’s very easily digestible with charts and graphs and diagrams that help you and help those people understand kind of what the scope of your upgrade looks like. So how do you use it? So first of all, you download and you install the tool. There are instructions to do it out there. It’s very straightforward. It’s basically using Composer and installing the tool in there. Run the tool against your instance. You analyze the output and you determine your priorities from there, and then you can also easily track these results on a performance monitoring dashboard that is available in the SiteWide Analysis tool, which is really great. So that’s all good and fine. Let’s actually kind of see what that looks like. So we’re actually gonna go through a small exercise where we kind of see this in action. So I’m gonna pull up my screen here, my command line, and we’re gonna kind of run through what this tool looks like. All right, so right here, I have my command line. And if I go in, I have installed the tool already locally on my system, and this is the upgrade compatibility tool in all of its glory. All right, you have a couple of different things inside of here.

But the two main ones that I want to focus on is core code changes and upgrade check. So upgrade check is kind of the one that you’re going to be using to help determine these types of things, okay? This upgrade check is what will analyze your code against the target version and help you understand exactly what needs to be changed to support the target version you’re looking to upgrade to. Core code changes is exactly what it sounds like. It analyzes the core code of what your version is and helps you determine if there’s any bad practices that are existing, excuse me, inside of your system. Has anybody made some sort of core hack not knowing how the platform works? Has somebody inadvertently applied a patch that didn’t follow officially supported methods? And are you seeing differences in there that you shouldn’t be seeing? You want to make sure you have a stable core, and if there is anything in there that is actually something that serves a business process, you need to be able to understand what that is, extrapolate that out into a module, and then reset your core back to its normal state, okay? Core code changes helps you do that. And then once you kind of get that and get that out of the way, you don’t really use core code changes in the future. But upgrade check is one that you will use, and that’s what we’re going to go over today. So we look at upgrade check. We go upgrade check, and let’s go to the help, okay? There’s a number of different options available to us from upgrade check, okay? So you specify the directory where you want to look at the modules to analyze. You can specify an individual module, or you can specify an entire namespace.

So let’s say that you have a number of different namespaces that are your custom modules, and you only want to analyze those, and you don’t want to analyze your third-party modules, you can specify that. But there’s a couple of different options available. Number one, you can specify the current version, that’s the version you are on, if you’re not in a place where it can detect it automatically. If you’re in the root of your project, it will. But if not, you can specify your current version. You can specify the target version or the coming version. So you’re saying, I’m on 243, I need to go to 244, right? So I will specify dash A, 243, coming version, or dash C, to 244. And then it’ll let you see exactly what those are. There’s a couple of other things that are inside of here as well, such as your appropriate output path, especially if you’re doing an integration with this tool. Minimum issue levels, so we have warning, error, and critical. There are things that you can do with minimum issue levels to help prioritize things, which we’ll get to here in just a second. And then ignoring current version compatibility issues. This ignores common versions for current and coming versions. That way you can help prioritize only what’s important whenever you are going to perform your upgrade. So let’s do a quick check here. So bin uct upgrade check. I’m going to go, let’s run it. So bin uct upgrade check.

I’m going to say my current version is 243, okay? My target version is 244. And then I have a module kind of sitting out here.

Cloud Commerce App Code test. All right. And so it will analyze and run and see exactly what issues might show up from this particular thing. So there’s only one out here right now, so we’re only going to display one. But we have kind of this snapshot at the end of it here that kind of shows you exactly what was performed. Hey, the current version is this, the target version’s that. The number of modules that require an update, this is the percentage of them that I found versus the ones that actually need an update. Obviously there was only one in this particular exercise. And then the files that require an update. There were 18 files in this particular module. And only three of them actually require an update. And these are the particular errors that you see and that you find within these. These are the ones that are actually here. We have a level error on line 22 extends from this and it describes what it is. That is non-API version on 244. We have a warning level here that’s on line 68, a non-declared method usage and things like that. And these are the different areas you have that you can help prioritize exactly what you need to do in the scope of your upgrade. I’m going from 243, I want to go to 244. These are the things I need to address. However, there is also another thing that is here. So there’s error 1121 and then line 22. Well, I know this isn’t the line because the line is specified here. So what is 1121? What is 1429? What are these things? These are what are called error message codes. And what you can do is you can go and look at what’s called the error message reference to get an understanding on exactly what that error is and how to fix it. So now you don’t have to just rely on just the output here and kind of hope for the best on exactly what it is. You can actually go look at the error message reference and say, oh, this is exactly why they’re addressing it. And this is how to address that. Another thing that you can do to help prioritize, especially if you have a large number of modules and you have a large number of output here, you can specify a couple of flags like I had talked about before. Then UCT upgrade check, and we’re gonna pull up the help again. Okay, so a couple of things. First of all, minimum issue level and ignore current conversion compatibility issues.

So let’s say that I specify ignore current, I do a dash I to ignore current version compatibility issues and I also specify the minimum issue level. Let’s say that I want that only at warning or higher. Okay, now you can see that, oops, yeah, that’s right.

So there was nothing, no problems found. So we went from having 10 errors and then we’ve kind of taken out the stuff that isn’t a critical issue, that isn’t an issue you need to solve right now in order or that won’t create a breaking change and the upcoming version that you’re going to. This will allow you to help better prioritize exactly what it is that you need to do to get to your upgrade.

All right, so let’s go back to our slides here. So a couple of tips here for using the upgrade compatibility tool. So use the error message reference like I had talked about earlier for more insights on their codes and solutions. If you’re lost on a particular one, go use this reference to figure out exactly how to fix the problem. Use a generator report to estimate the effort required to update your code, especially send this to things like stakeholders to understand exactly what kind of effort this is going to take, especially if they don’t have a full scope of understanding of what is going on. Continue to use the tool throughout your development to track your progress. Basically what you want to do is you want to see that list decrease with every iteration of your upgrade. It’s also valuable to use it whenever you’re just going through and developing normally. So this is a really great tool for upgrade compatibility to get to your latest version, but it’s also a very valuable tool for developers to create future proof code. So you can now understand, hey, what I’m writing right now is actually going to be a problem in say, you know, 244 and I’m writing it for 243 or 245 for example. Hey, I need to take that into account when I’m developing this new feature or performing this maintenance or whatever it might be on my currently existing code. You can use this tool to get ahead of those and kind of head them off at the pass and fix them before they become problems later.

Compare the results. So as you go through an upgrade and you fixed a lot of these issues, keep track of that initial one and then compare it against your future results. As you’re going through subsequent upgrades, maybe they’re patch upgrades or otherwise, see if there’s issues that you can see going down and see if there are issues that you’re mitigating ahead of time. And this also helps better estimate your future upgrade efforts, which is great. The tool is regularly updated with more features, update often for the latest features, that goes without saying, but every time a new release comes out, a new version of the UCT also comes out to help identify those compatibility issues. The two main flags that I was talking about in the exercise, ignore current version compatibility issues and the minimum issue level flags, help you provide with the most important issues to address. These are the ones that’ll say, hey, I need you to work on these first, if you’re talking about priorities, or this is exactly what you need to do to make sure your upgrade is successful. These other things can be a lower priority or a fast follow depending upon their severity and you should address them, but these are the important ones. These are the ones that you need to start with versus the other ones. Okay, so let’s go ahead and go into another poll question here. So, do you think the, will you use the upgrade compatibility tool for your next upgrade? Do you have any concerns? Do you not know where to start? But there’s a poll that we’re putting up right now, if you could answer that, and we’ll just leave it up for about 10 seconds, that would be great.

All right, thank you for answering that.

So let’s go into the upgrade process. So what does the upgrade process look like? So the upgrade process is, I know that we’ve talked a lot about it, but honestly, when we’re talking about the upgrade process of updating the platform itself, there’s not as many steps as I think people think there are. There’s not as many overarching, giant, monolithic things that you need to do in order to upgrade the platform to the latest version. It is essentially covered in these nine things. You need to enable maintenance mode or show the appropriate maintenance page, come back up your composer file and your lock file, just in case there’s any issues that happen with the upgrade. You install the composer update plugin and update any of its dependencies. You apply the update and apply dependencies and changes. Then you update the databases and schema. You upgrade any third-party modules and themes, any custom ones as well. You deploy your static content, clean your cache, restart any services, and then you disable your maintenance mode. That’s pretty much it. So what does that kind of look like from a coding perspective? So you run Ben Magento, maintenance enable, and now you’re in maintenance mode. You back up your composer file and you back up your lock file. Then you install your composer root update plugin if you haven’t installed it already, okay? Then you run your composer update against that to make sure you have all the latest things for it. Then you call composer require-commerce. What is require-commerce? That is from the composer root update plugin. You need to use require-commerce in order to get to the latest versions of the platform. So depending upon what version you’re in, you might have to do a couple of small additional steps in here, such as if you’re going from the open source edition to the commerce edition, you need to remove the open source edition before you require the actual enterprise slash commerce edition. You specify your version number, which is here. So you do composer require-commerce, and then the particular version and the version number, and then you do a composer update. And that’s kind of the beauty about the platform. The platform relies on these tools very heavily in order to make sure that the upgrade is as smooth as possible. You don’t have to drag and drop a ton of files, and you don’t have to perform all these system checks and all this other stuff. You make sure your services are at the right places. You do your composer require, and it will go ahead and automatically resolve those dependencies, automatically remove any redundant libraries, automatically upgrade to the latest versions, automatically get any third-party frameworks, and get that stuff in automatically. After that, you do a couple of cleanup operations, you know, any caching, page caching, any generated files. You perform a setup upgrade, and then you do a couple other miscellaneous things as well. So you upgrade your data and the database and your modules through Ben Magento setup upgrade. You might perform one or two other things. Maybe you wanna compile your static content or something like that. And then you wanna do any, you know, if you have any custom modules that require any special attention or any third-party modules that require special attention that isn’t already involved with the composer update or the setup upgrade, you can perform those there. Then you do Ben Magento maintenance enable, and if you have Varnish, you might wanna restart the Varnish service to make sure that that’s all working properly. But that’s pretty much it. These are your upgrade steps in a nutshell. They’re documented here in case you need to use them or follow them when you get a copy of this later on. But there’s not really a whole lot to it. A couple of commands and you have the latest version. You make sure your services and stuff are up to date and make sure all of your code is there, but the actual upgrade steps themselves are just these, you know, these commands that you run and everything is good from that point. So let’s go into a couple of best practices when it comes to the upgrade itself. So first of all, you wanna test in a non-production environment, goes without saying, but it’s always good to include in every one of these presentations. Make sure you’re testing in non-production environment. If something goes wrong or something fails or something happens with the network or something like that you’re not stuck with a non-functioning production environment. Perform your updates on a new server. So let’s say that you’re launching and you’re going live and you’re using cloud computing or distributed networks. You can perform your updates on the new server and ensure everything is where it needs to be. And then when you’re actually cutting over to the new service, you just point the appropriate networks to your new server and everything is already done. This ensures a minimum amount of downtime and allows you to account for issues without production being down. So you can just cut over and then your entire downtime is maybe a matter of one to two seconds versus minutes or hours. Leverage the upgrade compatibility tool like we talked about earlier, you know, go through and continue to use that. Perform your initial analysis and perform ongoing analysis as well. Automate as much testing as possible. We talked about the application testing guide and the dev and QA part of the execution process. Try to get as much of this automated as you can. You might want to take this time with upgrade to start to implement some of these tools to help you reduce the amount of QA and UAT effort required in order to launch, go live or iterate. If you have these tools, you can catch things without having to get manual or human intervention involved to actually see whether or not something is functioning as intended. Develop with upgrades in mind, okay? So we talked about the using the upgrade compatibility tool for ongoing development, but also think about other things. Are you using API when you’re developing? Are you making sure that you’re adhering to the best practice set forward by the platform? Are you adhering to the best practices set forward by the latest version of the platform? There were some things in very early versions of the platform that are no longer the best practices for the platform because they’ve been replaced with new, better, stable and easily upgradeable practices for those particular modules. So make sure you’re always developing with those in mind. Use that UCT to always make sure that you’re not putting in a feature that is going to be an upgrade compatibility issue later. Understand your third party modules. What are they doing? What do they still need to do? Are they still needed? Is there anything in the third party module that might cause compatibility later? Run the UCT against your third party modules. Identify any issues that might come up later. If you’re seeing a whole bunch of criticals that are coming from your third party modules, reach out to your vendor and say, hey, look, we’re looking to go to this version and this particular version that we want to carry your module into, it’s throwing a bunch of critical errors. So what is your plan for that? What kind of timeline are you looking for that? What is your mitigation plan for that? And be in contact with those people and have that understanding of what your third party modules are doing, impacting, and how they can help spring you forward and or might cause issues later on down the road. And then perform an annual inventory and site cleanup. So upgrading is a perfect time to delete, I’m sorry, more specifically, I should say remove a lot of the technical debt that you may have accumulated over the course of your particular version. You might have redundant business practices or services that are in there that are no longer needed. Understanding and taking out that kind of stuff lowers your technical debt, lowers your upgrade efforts, creates a more stable platform, creates a more performant platform, and then allows you to keep with that pace going forward. And it’s the perfect time to do it because you have to take an inventory of what your site is in its current spot anyway. So it’s a really good idea to do that, not only during your upgrade, but just annually as well.

Okay, so resources, we have talked about so much stuff today but there are still further resources that dive so much deeper than what we were able to cover in the timeframe that we had today. So a couple of main upgrading resources. Number one is you have the 2.4 Upgrade Guide. Make sure you go out there and read that end to end to get a full understanding of exactly what we were talking about today, as well as some more detailed steps on some of the things we talked about. There are comprehensive upgrade resources on the Adobe Experience League that allow you to walk into a lot more detail on things like the UCT, what the SWOT tool is available, and all of those different things that you can look at. Things like the release schedule, the release notes, all those different types of things. The release schedule to get an idea of what the calendar is showing for upcoming releases, so you can start planning that as part of your annual planning. And the upgrade compatibility tool as well. Very detailed and very thorough documentation on not only the tool, but how to install it, how to run it, some of the features available in it. There are message reference, all those types of things are out there. We have a couple of additional resources here. We’re not gonna actually go through each one of these individually, but we have this available because you can get a copy of this slide deck and you can use these different things for additional parts. Releasing strategy, planning, more details on the UCT, things about security that you should be aware of, security patches and releases, technical things like the release notes, DevDocs, the testing guide that I mentioned earlier, quality patches, pre-releases, backward compatible development, and then other technical things as well. And with that, we are going to go ahead and wrap this up, but not before we get into our Q&A session. So if you all have any questions out there, please go ahead and fill them in. And with that, I will hand it back over.

That’s great. So, hey, I’m Sandra Gonzalez, and I’m just gonna read out and answer some of the questions that we have already in the Q&A session. So first, I just want to highlight that we have attached on the handouts, the presentation as a PDF. So if you want to have the presentation, please feel free to download it directly from the handouts that we have on the right side of the go-to meeting. Having said that, so I’m gonna ask some of the questions that were asked already. If you have any other questions, feel free to just add them on the Q&A pod, and we will try to answer them on the go. So will the slides be available? Yes, I just answered that question. And you will be able also to see the recording of the session after this is over. So what is next question? What is going to be the general end of support time for new releases? So the question is focused on an example. If someone wants to migrate to 2.4.4, so how long will they be supported until I’m expected to migrate to the next one? So for everybody, the end of support dates moving forward will align with PHP end of support dates. So this is our life cycle policy. So for 2.4.4, we’re using PHP version 8.1. And this will reach end of support in November 2024. Next question is the extended support plan for XPR Adobe Commerce version will come with cost or will that be free? So the extended support will be made available for both 2.3.7 and all versions between 2.4.0 and 2.4.3. And it will come at a cost. So however, there are different price options that we have available for our customers. So you can work with your customer success manager and learn more about the options that will best work for you.

We have a question about the great compatibility tool and whether it is installable and usable on Linux system versus Windows due to the use of column compression. So the great compatibility tool should be available and should work properly for both. I recommend if someone is having this type of issues to reach out to the UCT team over Slack. And the Slack channel is a great compatibility tool on the Magento Slack channel. Next question, and I think probably Igor or Ryan will be great if you can help me answer these questions that you’re gonna get much better answers. So the first one is, do you have tools for syncing the production code and database for Cloud Pro? So the person that is asking this question is that they have the basic and it was easy to just sync in the banner. And now it seems to be quite complex. So probably Igor if you want to know.

Yeah, thank you, Sandra. Let me cover this question. Actually, yeah, in the panel, in the UI panel, you can sync only the quad base. So that will be putting the quad base and that’s it. However, if you want to sync code between the environments, let’s assume from production to staging and after that to integration, you need to use additional tools.

Fortunately, it’s possible to use Magento Cloud tools. For example, I mean Magento Cloud CLI tool command.

You can use Magento Cloud DB Dump to make a dump and after that you can use Magento Cloud SCP command to move the database dump or media assets from all one instance to another. And your local environment will be a separate option. There is another option if you have a big amount of data like one terabyte or 500 gigabytes, it’s possible to set up a connection between two environments. You upload the keys to the repositories to each environment and after that it’s possible to move data directly from one environment to another one. For example, from production to staging code without using your block environment as a proxy. If you need any suggestion or support in this approach, please reach me in the upgrade Slack channel and I will help.

That’s it. Thank you, that’s great. The next question is about composer required. It seems not to work and whether they should just be composer required or something else. Yes, actually I think that the issue is that you need to install a new version of Magento Composer root upgrade plugin. I think Ryan probably mentioned this on his slides and after installing a new version, new Composer commands will be available.

However, as I know it’s possible to use an alias like composer require instead. This is also possible.

Thank you. So the next question is how will we perform updates on new server as a best practice on Adobe Commerce Cloud? So I think you can get this one. Yeah, yeah, yeah.

So actually it is no best practice on this.

However, I think if you, for example, if you deploy, if you upgrade Magento like in this case, with changes in PHP, my suggestion would be ask support to set up staging tool with a new hardware setup that will be a new cluster with hardware applicable for Magento 2.4.4 and actually make an upgrade on that staging and this is the most common approach and many customers request the second stage and can do environment for this flow. There is another option to set up a second production and environment but yeah, this is very expensive and I think that this should be a unique case since I think in many cases it’s better to sync with support team, raise a ticket that you are playing an upgrade, you set up the frame that you are playing an upgrade within this frame and support will support you.

Sorry, yeah and this will be much cheaper. This leads to some downtime but for the most of clients this is applicable. For the rest I think that yeah, you can request for a second staging for only upgrade purpose and after that ask to discontinue this staging too.

Great, thanks Igor. We have a question, Ryan, I don’t know if you can show something on this one, whether we can see an example of an error resulted with UCT that is not a non-API issue.

If you can, that would be great.

If not, I recommend to go to our documentation, we have the list of all the possible error messages that you can get from the tool and all the suggested solutions for each of them.

Yeah, unfortunately I’m not gonna be able to show anything that isn’t of a sensitive nature or protected by client so I don’t have any non-client code available that I can just run against at the current time. Yeah, that makes perfect sense. So now the question is if there is any core code level changes that might make the code that is working on 243 not compatible with 244, the answer is yes and that there is a list of backward incompatible changes on DevDocs that you can have a look at and you will have all the details there.

And… Yeah, let me just in addition, let me post this link to the public chat since of my experience many developers or many people do not know about this list but this is a great reference for checking the changes in the core code base.

I posted it to the chat. Thanks Igor. There’s another question that is also related with 244 improvements and whether we are releasing any PageSpeed and web store standards specifically for mobile devices. I think there’s also a documentation on DevDocs that is close to the one that Igor is gonna be sharing where you have all the improvements that we are releasing with 244. So you have all the details on this DevDocs page.

And I think we’ve answered all the questions.

So then we can go back to you Darlene.

Awesome, yeah, I think there’s just one more question I wanted to ask here. How do merchants switch from Elasticsearch to OpenSearch on 2.4.4, especially customers that are new to OpenSearch and are used to using Elasticsearch? How different is OpenSearch from Elasticsearch? Igor or Ryan, do either of you know the answer to that one? Actually, that’s difficult to answer right now. So what I can say that if you use Elasticsearch, there is no issue. You can continue using Elasticsearch.

However, I think that the primary changes for Magento Cloud customers since, I mean, Adobe Commerce Cloud customers, yeah. If you set up a new environment on 2.4.4, you can use only OpenSearch. However, if you are old customer, you can still use Elasticsearch until you upgrade to a new version. Yeah, however, at the same time, if you’ve used on-prem solution, I do not see any reason to discontinue using Elasticsearch.

The main, your difference is in the license. But I can provide you more details after I think with support how they are planning to manage this switch on Adobe Commerce Cloud since I do not have this information right now.

Awesome, thanks, Igor, I appreciate that. All right, so thank you all for attending. We hope you have learned and enjoyed this presentation. As you’re leaving the session, you’ll see a very quick one-question survey. It’ll take you less than two minutes to complete, so we appreciate you taking a moment to answer. If you have questions specific to your account and we’re not able to address it today, just please reach out to your customer success manager. As a final reminder, you’ll receive the recording of today’s event within 24 hours via email, including an on-demand link. All right, so you guys have a good rest of your day.