[Music] [Lizeth Almaguer] Hello, everyone. This is A Progressive Approach to Modernizing Your Adobe Commerce Implementation. My name is Lizeth Almaguer. I am a Solution Architect on the Professional Services team, and I'm here with-- [Muhammed Vatansever] Muhammed Vatansever. I'm a Principal Technical Architect with Professional Services. I will try to help you understand a few tools and concepts that you may need with your modernization journey today. And Lizeth will touch on the approach.
Perfect. So let's start with the key takeaways. So why are we here? Maybe some of you saw an announcement yesterday, a very exciting announcement yesterday on the roadmap, Adobe Commerce Roadmap...
Or you have performance issues, or you want to innovate, you have limitations and you want to know more about App Builder. So the first key takeaway is that we have a way to have an out of process...
From the Adobe Commerce platform. We're also going to talk about progressive approach so a phased approach. So start small and scale smart. And then we're going to introduce you to some of the tools to get there. So those are the three key takeaways. Cool? Anything else? All good. Okay. All right. So the way we're going to do this is we're going to start with just getting a little bit of the history of Adobe Commerce, how we got here and the evolution. Then we're going to talk about the modernization, what we mean by modernization. Then Mu is going to talk about the technology that we have available, App Builder, the Commerce Storefront powered by Edge Delivery Services, and the tools available from the product team for the modernization.
Then we're going to talk about the approach and then just some actionable next steps.
Okay. So let's talk about the evolution of Adobe Commerce. So there was a beautiful acquisition happened in 2018. And so the first goal of Adobe was to make a platform that was scalable, that was available for enterprise customers. We focused on B2B, multi-region, multi-brand capabilities, and we were focusing on having a platform that was ready to scale.
Then we focused on being API-First. Now API-First, but not API only. That means Adobe was still committed to make capabilities that were available for you, so it's not only like giving you access to APIs, but also focusing on the capabilities needed for an e-commerce platform.
And then now there's the introduction of-- For continuous innovation, there's this cloud-native extensibility. So we have cloud-native apps available for you, cloud-native services, and as announced yesterday, cloud-native platform. So the important thing here, so you saw this exact same slide yesterday on the roadmap if you went to the roadmap session. But the important thing here is that these are options for you. So it's an evolution of the platform, so we're making the platform better. So there's an evolution of how we find better ways for you to implement your platform. So obviously we spend a lot of years having the traditional e-commerce platform, and now we're going into an evolution that can scale and catch up with all of your needs and the needs of the market. So if we go one by one, we have the traditional architecture. So just like historically or probably most of you are in this architecture. So just so we know who is a current customer, Adobe Commerce customer.
Okay. Who is on Adobe Cloud? Okay. And who has App Builder right now? - Okay, great. - Nice. So the ones that have Adobe Cloud have access to App Builder today. So everything that we talk about today, you can implement it on your next release. You're able to start today. So the traditional architecture was basically having customizations within the platform, and you could do whatever you want. You could do it on the front-end, on the back-end, on database, everything can be customizable, and this model allowed very deep customizations via PHP modules. So this is the platform that we all know, love, we're proud of, but now there's an evolution of it.
So now what happened? There was a few challenges with it. So why is this lady sweating? So we basically gave you power. We gave you code, open source code, and you could do whatever you wanted with it. So you took the code and then you went to the marketplace and you said marketing is asking for this and merchandise is asking for this, and then you started adding a lot of customizations to your platform. And then when Adobe came with a new version of it, you had to look at what you had and let me see where it fits and sometimes there was upgrade that didn't fit, there wasn't compatibility.
Or you had issues with performance already, so it didn't fit. So there was a lot of issues, a lot of challenges that were considered tech debt...
And then maintaining the customizations were very expensive and stuff like that. Adobe also focusing on the experience and the experience cloud, we also saw the challenge that data sharing was very, very difficult for existing customers. So we had to create a way to get out of that pattern, and so we have now the ideal model or architecture that will be better for our customers. So the ideal way is to have the-- Or the ideal North Star will be to have your Adobe Commerce foundation untouched, right? So the only thing that can touch it will be the version upgrade. So start with a clean modular foundation that will make it easier for your upgrades. You can improve the performance that way and also just...
Decoupling the operational load.
And then we have the next layer, which is the merchandising services. So these are available to you, so now Adobe created cloud-native services that are available to you. You can use it, you cannot use it. It's up to you as well.
There's a catalog service, there's live search...
For recommendations and so on. So that is also something that is available to you.
And then now the customization layer. So now we decouple the customizations...
Through App Builder, API Mesh, Adobe I/O. So this way is a different way of extensibility. Obviously, this session we're going to focus on that portion, but we also wanted to touch on the experience on the front-end. So Adobe has been focusing for years on an experienced product, which is Adobe Experience Manager. So they have a lot of experience on what is needed for the front-end, for the storefront. So it was only a matter of time to use the same storefront or the same capabilities in storefront as AEM. So now we have a united strategy for the experience on the front-end. So we have the Commerce Storefront. It doesn't necessarily mean that you need AEM. Now the Commerce Storefront will be powered by Edge Delivery Services, which is something that is also available in AEM. So depending on the front-end needs that you have, you can have AEM or just the commerce storefront. For the announcement from yesterday, this is the ideal architecture that you will need to move to Adobe Commerce Cloud Services, which is AKA the SaaS platform.
But we can call it ACCS. And so this will be the ideal North Star to get there. Now what does this mean to you? So you most likely have all of your customizations on the foundation currently. So you have hundreds of modules on the platform. So the good news with this modernization/announcement is that this time we're not coming up with a new version of commerce that is 0.3 for some people that know the versions where you just have to move completely to the new platform. This is just an evolution of how to decouple the experiences. So you can actually have your modules, so if you have 500 modules, you could have moved 10 to App Builder while you still have your foundation. So within the past foundation, you can still have a hybrid of both. So like I said, if you have cloud license, you have access to App Builder today. So you could start implementing some modernization steps to get to that decoupling and have this architecture in mind.
So these are the three things that you will need to consider if you are looking at the North Star to move to ACCS.
So the experience is decoupling of that we also are going to introduce something called the Commerce Optimizer that you probably heard about. So the Commerce Optimizer basically can be on top of any other commerce platform. I know you guys all have Adobe Commerce, but just in case if you have an experience that doesn't require a transactional portion of the site that just need like the experience and the catalog, then it will be basically, if you see it this way, obviously, this is a way, way simplified version of it. But if you see the number one and number three, it would be like the power of number one and three. It would be Commerce Optimizer. If you want to know more about Commerce Optimizer, there is a session today at 4pm. So they're going to introduce Commerce Optimizer, how you can use it and the power of it. And if you want to know more about Edge Delivery Services, so both for AEM and Commerce, they will be both included in the session. There's a session tomorrow at? - I think it's 11am. - 11am. It's a lab, and I heard that the lab is full. But there is no unenroll button on these labs, and I'm sure some folks will not arrive. So I would suggest you, if you're interested in, definitely go there you will find a seat.
Just maybe give my name. Olena will take you in.
- Right. - Perfect. All right. So before we go into App Builder, so let's just mention a few of the benefits of the modernization. So to start with, cost efficiencies, right? So I know, not you because you have perfect code, but the clients that had a lot of customizations and had bad upgrades and they're very expensive. To start with, upgrades are out of the-- Now you don't have to worry about the cost of the upgrade, so that can save a lot of money. Maybe you can bring a colleague next year for Summit.
Faster innovation. So it's easier to...
Get more innovation faster when you have decouple experiences. You don't have a lot of dependencies and you don't have a lot of risk.
And then on the last two, minimal disruption and risk mitigation, that will be both on the disruption of the architecture. Now the deployments are separate as an example. So you can have deployments on App Builder. You can have deployments on Edge Delivery Service. You don't have to have all of the deployments on the platform anymore, so minimal disruption. Also, in the case of the context of a phased approach, minimal disruption will be that you can still continue with your operations every day. And what we are proposing is that you can still continue with the marketing request and everything that you have in your backlog while you modernize to App Builder.
And now we're going to go into now a little bit of App Builder and EDS. So Mu has some examples of the technology and what's the difference between what you have right now in traditional versus just the App Builder. All right. Welcome again. So before we dive into this, I just want to have a deep breath and give it back because I spoke with some of you. I see some of my clients here, Isaac, from Jomashop.
I see my other clients on the other side.
The enterprise edition is not going anywhere. The cloud is not going anywhere because there's a cloud as a service, right? So all of three different version of implementations will be there. That's why it doesn't say you have to move to App Builder, right? There's no "have to" here. It is to modernize for your extensions. It's a way to modernize.
I want to start with that because you should understand that there is no "have to" here. Do this if it works for you, and do it if it benefits to your use cases. And I will try to show some examples here. I will try to stay on the surface, right? If you have deep technical questions, we will have a Q&A session. We will try to make it as long as possible. So I will be here. I'm a commerce technical architect. I will be here to answer any of your technical questions. But without further ado, let's jump into it. So why move to App Builder, right? It is a cloud workspace. It is somewhere that you can put your custom applications. I know a few of that. There's AWS Lambda that I can use for this purpose, or Cloudflare Workers. Why would I use this thing? First of all, this is not a new product introduction, right? This has been with Adobe for a while now. For commerce people like us, it is a new concept. Maybe it's been a year or so that we knew about this, but Adobe was using this for other products. AEM architects were using this for years now, right? So because I have some folks here that may ask to me like, "Hey, are we going to have an uptime guarantee here?" Or, Carey will ask me, "Is it working with HIPAA restrictions?" It does, right? So normally, when you get a new infrastructure like this, you don't get these things all at once. But this is not new. This has been there for a while. We just connected it to commerce. Now why this environment, right? It is very close to Adobe products. It has been working with any Adobe products that you can name today in the community pavilion, right? If there's any API that you want to get data from analytics or you want to subscribe to an event from any other application, you have it on App Builder. So that expands your capabilities with commerce, right? Any customization that you would need to do an integration with an Adobe service, now we have a direct connectivity. And it is also in the same network with Adobe Commerce Cloud as a service. I'm not saying that you have to go SaaS, but that's just one reason because you're on the same network. The proximity is very close, right? Beside this connected, any customization you move to App Builder will be one less module or maybe two or maybe five removed from your Adobe Commerce PHP extensions or modules. So next time you upgrade, like Ron did-- I mean, you won't need to check if your module is compatible with 8.3, PHP 8.3, or if your module is compatible with 2.4.7 of the Adobe Commerce, right? You have to go through all of those when you are doing an upgrade. It takes time. It takes a lot of testing. And if you have less modules, less extensions, you would be upgrading much faster. So take this as a progressive approach, right? You don't have to be on SaaS on day one, which, it's very hard for some of you to be there, but take that as your North Star.
So...
App Builder is an event-based platform. You have some events coming in and you do some actions based on those events. All of our customizations have been like that before. When you were creating a plug-in in Adobe Commerce, it was based on an event observer or some other method that you were overriding, right? Oh, you want to send some order data to your ERP, like standard use case, right? When you do it? When there's an order placed. So there's an event and you have an action. You send that data to your ERP. So that's how it works and it's a very low code environment. You do use JavaScript. So let's say the state codes require not two letters but three letters for some reason on your ERP. Do you need a full redeployment on your Adobe Commerce Cloud and have a 10 minutes downtime maybe or 2 depending on your deployment speeds? If you're doing that with App Builder, you don't need to do that anymore. Well, you can just deploy that piece or maybe test it in a separate place using your production environments and have two separate applications working with your production at the same time and then release it. It's that easy. You don't have any downtimes because of that.
But I have some examples here on the diagram. I'm showing a real-time integration, and also an asynchronous integration with the order example. But I will dive into those a bit more deeper.
Let's say that you had that use case, the order integration with the ERP system. What would you do in a traditional architecture? You would create a custom module, right? This custom module would check some observers in your code base and it would cache the new order data. It would send it to your ERP system. You would need to create a client for the ERP APIs, right? You would need to have that library created in your Adobe Commerce. And then next time you upgrade, you would want to make sure that works in the new version, right? And then maybe the Loyalty App would also ask for the same order just to update the customer profile, right? And you would maybe need another custom module to send the same data whenever an order is placed. That is just another module to take care of when you are doing an upgrade.
It could be working on the App Builder like this. First of all, the order event, like you have seen on the previous slide, is already there. You don't need to push that event to Adobe I/O. We have eventing module that you can install to Adobe Commerce. It's part of the core code base, right? And it will send more than 700 native events of Adobe Commerce to App Builder with just one simple configuration in your admin panel. You don't do any code for that, right? And then you would create a custom application on Adobe App Builder so this would synchronize with your ERP and loyalty application automatically. You have your login, you have your monitoring, you have your data storage, you have your development tools, everything ready in App Builder to create this application. We have more, a bit more than just providing a clean space that you can create an application. We have some blueprints also that I will share in a bit. But let's take a look to another use case, right? Let's say that you are running a real-time inventory check with your warehouse management system right when you're placing an order. So that's a little different than what we have shared before, right? It is not asynchronous. You're not sending the order after some event happened. You want to do something while that event is happening, while that order is being placed. So that is also possible with App Builder. So what happens is let's say there is that old-school PHP process, that is running your code and at one point it is checking the inventory.
Let's say your customer is waiting in those milliseconds. Let's say we slowed the time and it takes 200 milliseconds to load this order success page. While it is being loaded, you're checking that inventory if it's available, so you want to place this order. And if you want to have a real-time check-- As an architect, I wouldn't suggest that because if that API is down, your order placement is down. But let's say that you have a use case. You have to use this. You have to have a real-time integration. Then you can create a webhook with App Builder and have an App Builder serve that inventory check back to Adobe Commerce so it can continue with the process and return the response to end user. This is also possible. This is one of the use cases that is being missed mostly. When we say App Builder, we think that it's just for asynchronous, but it also works for synchronous processes. The same way we were creating a plug-in, if there are any developers amongst us, this is what you normally do in di.xml file.
So let's wrap this up, right? We have more than 700 native events for any entity that you may think of, any action that you may think of in Adobe Commerce. So in addition to that, you have...
A synchronous way and asynchronous way to-- Sorry, a asynchronous way and a synchronous way to create this integration. You can connect with any application, right? It is natively connected to AWS EventBridge also. That opens up a lot of doors for you. It even makes some integrations drag and drop, to be honest if you use that.
But I'm not going to leave it there. Hey, there's a place that you can create an application. Go ahead and create. No. We have some starter kits for you because that's the hardest thing for an engineer to know where to start. It's not that we don't know this application, but we want to make sure we create the correct architecture that will be future-proof when we are creating this custom application on our empty workspace. That's why we created the starter kit. It is not a plug and plating. It is a suggestion for you where you can put your ERP integration or any kind of back office integration, when a certain event happens. You want to update your CRM application when a customer created Adobe Commerce. We had the code ready up until to validating your data, transforming it for your CRM application, and sending it. You just need to add one small client library for your CRM and you can use the rest of it pretty easily. There's logging attached to it. There's monitoring attached to it. So it's a great place to start and makes life very easy for your developers.
We have the same thing-- Sorry, I was on the wrong slide. This is the Integration Starter Kit. So let's take a look at what kind of entities we have. I mean, I see product, I see inventory, I see pricing, I see customer, I see orders, right? But this is not just it. You have also your capability to add any custom entity. Let's say you have a gift card entity that is not out of the box but a custom one in Adobe Commerce. You can attach to it here and have custom actions managed within this architecture.
You also have some example ones. You have SAP HANA that we have built.
SAP HANA integration that we have built on top of this. So even though you are not using SAP HANA, you can take that App Builder application and take that as an example and see what you can build similar to that. We have Microsoft Dynamics Financial Operations also integrated using starter kit. So definitely check those two. The Financial Operation one is freely available in our app marketplace, which we will share the link at the end of our slide.
Now it's not just the asynchronous integrations like I mentioned. We also have some tools available for you for synchronous ones where you have some payment options or shipping here your integrations, in your checkout, which is a bit complicated when you just think about it with the earlier diagrams. So that's what we realized. We created some out-of-the-box extensibility modules, actual PHP modules. So we allow Adobe Commerce to work...
A bit more closely with App Builder for these extensibility purposes. We have examples there for how to create a shipping carrier integration, shipping rules, payment rules, payment gateway integrations. So you can take that as an example and start from there. It's also an architectural blueprint to use with App Builder.
A common one was the tax services integration. We also had a sample there too.
Now obviously, if the goal is to move to SaaS...
Moving your custom applications to App Builder is not just going to cut it, right? You would need some third-parties that you are already using today, meaning they are PHP extensions to be on App Builder. So these are the brands that you may have seen on the roadmaps session yesterday, but if you have missed it, these are the brands that are committed to deliver extensions or applications on our marketplace to be used within your Adobe App Builder platform.
Right. I see some pictures taken, so go ahead. We will share the slides later, but this is a good slide. It took some time to get all of these brands approved.
So on top of this, we have some tools available. These are not the ones that you need to take care of their code base, but these are just some configurable applications also within App Builder, right? This one is called API Mesh. You may have heard this before. This is to orchestrate your APIs and there are some use cases where we create a module and that module is only bringing data from a certain API endpoint but it's actually a clutter in our codebase. You could do that with if you had an API orchestration tool, that's where API Mesh kicks in. I have a use case here that I want to show you guys. I know it may sound very simple but it's just for you to understand the way it works. Let's say we have a reviews service, right? You're bringing product reviews into your product details page and you want to keep them in Adobe Commerce and you want to pull them from an API endpoint.
Like the order example, you would pull this using a custom module, right? That could be one way to do that. I see most of the product review providers though, they provide a library. So you put that library into your front-end application. That is also possible, but that's just another thing to track on your front-end application, especially if you're headless. It's extra code in your front-end code base.
Now the way it works is that API Mesh can pull data from any source of API. You name it, REST API, GraphQL, SOAP. Even if it's an unstructured schema like any JSON response. You can put it in API Mesh. You don't need to code anything. It's just a configuration. It will mesh it together like magic with your existing Adobe Commerce API and give you one single unified GraphQL endpoint so your storefront can use it.
Why would you need this? Storefront layers are just for presentation, right? If you want to run business logic on your storefront layer, then how are you going to separate where you are keeping these business logics? Is it going to be on your back-end? Is it going to be on your front-end? Who's going to be responsible of developing these things? And when you add more and more business logic to your storefront, it just becomes heavier and slower on your storefront at some point. So that's why API Mesh may help you with the API orchestration.
All right. So I will jump to Edge Delivery Services real quick. I know Olena has a lab session tomorrow and we have some other sessions about this, but I just want to touch on this because it is one of the tools that you may need during your modernization.
Now I will give you the standard pitch, right? This is where we have commerce experiences and content meeting together. You have experience manager based authoring or you can have document based authoring. It is pretty awesome actually. If you haven't tested it, please go into the Commerce booth in the Community Pavilion. You can test it over there. You put some words into a SharePoint document and then save it and use SharePoint for your permissions and authoring, right? Then you save it and it just pops up on your storefront, all styled and everything. So I mean, I don't know if you are in love with Page Builder or any other editor, but I'm not. It feels much easier for me to use this. I know Kevin also loves that.
EDS is where your commerce and content experience meet. But now for every storefront technology that we have provided until so far, you would need a full big migration to it. Remember PWA Studio times or if you are moving to AEM, let's say, you would need to leave your Luma front-end and move to the new platform.
That's why I wanted to touch into this because you don't need to do that with drop-ins that we provide here. There are multiple drop-ins. You have cart, checkout, PDP. Any part of your commerce experience is a separate drop-in, and these are modular pieces. Remember those product widgets that we would put on our website? Could be from like a recommendation provider, right? You would put a library, a simple library, and you would put where you want to see your product recommendation widget, it would pop up the products there. It works in a similar way. Not exactly the same technology because those things were slow maybe like 10 years ago. But these drop-ins, let's say you want to have a product detail page somewhere in your website. You just load the library, put it in, and it allows you to...
Show the product detail page there. What's the benefit of it? You have a future-proof drop-in that you can extend. You cannot touch or you should not touch the core of it, but you have a lot of extensibility points, what we call slots, right? Using these slots, you add your customization, and when the technology of that storefront gets old, Adobe will replace it for you. Currently, all the drop-ins are built with Preact, right? But you didn't need to know that, right? You just need to know what customization you would need to do there. Let's say when a customer clicks on the Add to Cart button, you need to show a protection plan to sell them, right? That's your customization to put in the Add to Cart slot. But let's say in the future, in three years, Preact is yesterday's news and Adobe needs to put another library there, your slot will still be valid. This is the difference with the previous front-end technologies that we were providing you.
Now these are also...
Compatible with any source of front-end technology. You have a Next.js framework on your storefront today. You can put your drop-in. And you don't have to put all of them all at once, right? You can start with your, let's say, landing page being on Edge Delivery, right? And the rest of your experience can stay on their existing-- Sorry, existing storefront.
In the next phase, if you like it, you can add your PDP or PLP into it, right? And keep checkout and cart in your existing storefront. That's how Visual Comfort works today. We have them with us right now. Go ahead and check their website. You have homepage and PLP working with Edge Delivery, while the rest of the experience is with Luma team.
Now this applies if you have any source of front-end. But if you are specifically on Luma team today, we have a tool called Luma Bridge, where you can have some of the pages like content page, category page, and product page on Edge while you have the rest of the experience on Luma. And Luma Bridge allows you to connect this experience because if you think about it, if I'm logging in one application and I'm going to cart, how does that cart know who am I? So there is a bridge that will help you to connect this context.
This is where I give the mic to Liz to wrap it up. I may have confused you with a few technologies or deep dives, but we will have more to talk on Q&A. - Go ahead. - All right. So now we know the technology. We talked about some tools on how to get there.
But now reality check, it sounds like a lot and I want the technology, but where do we start, right? So the options that we will have will be a full migration. So get all of your 500 modules and then a big bang release.
We've had some projects like that. We wouldn't recommend to do that. There is no technical reason to do that. So let's just be clear. If your business is pushing you because they gave you the budget and you want to have a team doing that, we will still not recommend it. But if the business team is pushing you to do that, that's one thing.
But there's no technical reason for you to have a big bang migration to App Builder in this modernization. I think even if you want to move to the ACCS or SaaS, I think there's still a way to do it without a lot of risk, with smaller releases and rather than everything at once shift, right? So this way we can test it live. Again, you can have your current technology. You can have your modules that you have right now, and you can have App Builder at the same time. So that's the beauty of this modernization. So in terms of steps, I guess step zero will be for those that have Adobe Cloud, ask for App Builder to be provisioned, you can play with it and decide what to do from there. But in terms of-- Okay, I have-- And I keep saying 500 because one of my clients has 500. But 500 modules and so what do we do? So if there's partners in the room, please don't just go to the module by module and then just do a like-for-like. I think, if they have a lot of modules, it means that there's years and years of valuable customizations that they put the effort in it. But it means that because it was a lot of years ago, there's time to do a check with the business requirements. So always start with the feature matrix. So we call it feature matrix because it's basically the list of all the features that Adobe Commerce has and then plus the customizations that you will need. And that way you map first your requirements to the features that we currently have and then you find the ones that need to be customized. And then you do need to map them to the inventory that you have on your current customizations. Actually, I'll touch that later. But then you need to prioritize them, and then we'll go into development, and then how we will release that. So let's go step by step.
So like I said, you create your feature matrix with your business requirements. You tag the ones that are more valuable for the business, the ones that work for you, the ones that have big impact. And then you map those requirements to the inventory of your current customizations. I'll tell you why you need that in step three. But then you map those customizations also by functional area. That way you can find dependencies. So if you're going to release something that is going to touch your PDP, then you know which modules touch the PDP, and you understand the complexity and the dependencies of everything. So that's your first step, planning and design. And then you move into the prioritization. So you can do it different ways. If your code is perfect and you want to go into a just functional way, then like Mu said, you can start with content, then cart checkout later, and stuff like that. Edge Delivery Service, it's very easy to move just your content first and then you focus on where the drop-ins are and stuff like that. So you could prioritize that way. Every business is different, so depending on how you want to do it. Now since we know that a lot of customers have upgrade pain points, again maybe it's not you, maybe the ones that didn't get to this room, but what are the dependencies to get the complexities that are limiting you to go to the next version. So maybe start with that. If you have performance issues, if you have dependencies, the word re-indexing happening a lot of as a problem. So identify where do you want to start and so see that as an impact in value in every release. Now we're not asking you to stop your business. So then also prioritization on your current flow or your current development will be to start using App Builder. So every new requirements that you get, try and start to move it to App Builder. So that's a way to see it. Also finding the quick wins, right? So we have integration starter kits. So all your integrations, maybe you can start with your integrations as well. Maybe you can start with one, see how it works, and stuff like that. So prioritize it depending on your technical debt, on your limitations to innovation. And again, every business is different, so you can prioritize. So we don't really have a prescribed way to prioritize, but obviously, if there's either an upgrade that coming that you're really behind, then prioritize that and using the tools will be a way to go. Now that you are in development, again, use the tools available. With the Luma Bridge, it is just four-phased approach. We still want you to, at the end of the day as a North Star, to completely move to if you're considering Edge Delivery Services. For ACCS, so just to clarify, you don't require Edge Delivery Services or Commerce Storefront powered by Edge Delivery Service, because marketing might be in the room. But you don't require to have Edge Delivery Services. So ACCS supports any headless, so any head that you have is supporting ACCS. So again, the Luma Bridge is just a tool for you to get faster there, so you have to accelerate, but it doesn't mean that you have to use it and it's just something that is available. The integration, the checkout, and all of the starter kits that the product team will be releasing, obviously, it's an accelerator for you to get faster to this model. And then something important to understand is that not every module means an app, right? So if you have 500 modules, that doesn't mean you're going to have 500 apps. And that is why it is very important to have a list of your current modules in your inventory. Because at the end of the day, even though once you're in App Builder, then the releases are separate. But when you're starting in the modernization, there's a step where you're releasing an app that you have the module as well. If you don't really have a way to just turn it off, then consider in development that you create the app and then you have to detach the module that you have and stuff like that.
Obviously, in App Builder, it will be once-- You're in App Builder, then it will be easier. But for modernization, consider that you don't want to have duplication and production to have any issues.
And then, how do we release that? So again, you prioritize, find value in every release. We have some examples and I added the word example in every step so you remember that it's just an example. So we're not being prescriptive on how or which apps you start with. So some of the things that we've heard with our customers are like, "Okay, let's do Edge Delivery Service first." We have the example that is in my head for Edge Delivery. They do have 500 modules, but 100 of them or plus 100 and something are dependent on the-- They're for the front-end. So sorting or things that they created a module for the front-end. Therefore, if they move to Edge Delivery Service first, then out of the 500 modules, they have only 400 to migrate to App Builder. So that's why they decided to go with Edge Delivery Service first because they have a lot of modules that are for the front-end. Then there's a lot of customers that are like, "I don't know your technology, I don't know App Builder, so I don't know what that is, and maybe it's not going to work for me." So you can test it. So ask for provisioning, you can just deploy one app, one functionality capability, and you can test it. So that could be a release. So anything that can give you value, that would be the way to prioritize your releases. You can release it with your schedule again, like with the hybrid approach because we want to be really clear that we're not forcing you to go to App Builder, but it also works with your current module. So you can do PHP and App Builder at the same time in the PaaS environment. Obviously, at the end of the day, if you do want to move to ACCS, AKA the SaaS platform, then you do have to migrate all of your-- You have to be headless and you need to migrate all of your PHP modules to App Builder.
And with that, those are the steps. So just to summarize. So App Builder is the way to reduce your tech debt, have better and faster innovation with out of process applications, and then consider a phased approach, less risks. You can have multiple deployments, and consider we have tools available, our product team is committed to create accelerators for you to go into this modernization.
And of course, the ACS lady. So we're here to help. So if you want to know-- I do have performance issues, but I don't know which modules are giving me performance issues, then we're here to help. So we are professional services. We have health checks that can help you prioritize which are the modules that have performance issues or if you have upgrade issues on compatibility and things like that. So we are here to help. We also have technical advisory. So for partners here, we can help the partners or customers that have partners, we can help as well. We're not trying to compete with partners here. Just to clarify.
All of these things are new to most commerce folks. And if you need any architectural advice, even if you have your in-house development team or your partner working with you, but you want someone to take a closer look from Adobe, we can do that. We are working with some-- I see some of my clients here. We are working with them, and they have their partners, but we just help them to map their journey. Yeah. We have no capacity to do everyone that wants to modernize. So of course, we just want every customer to be successful. So this is the best time to partner with partners. So if you're a partner, we're open to help you. So we just want the customers to have a successful modernization. Picture of this one, I know is not clickable, but if you want, there's some resources available. You have the app marketplace link? It's the hardest one to find, to be honest. Because most of the time when you say Adobe Commerce Extensions, you go to the existing one, but this is where you have the App Builder applications. So definitely take a picture of it, but we will share the slides later. Or send us an email, we'll send it to you.
Thank you everyone for attending. Thank you very much.
[Music]
