[music] [Wilson Faure] Good morning, everybody. So I bet you guys are still recovering from the bash. Plenty of coffee. It's probably the most difficult sessions are after the bash, but I'm looking for quality, not quantity. So who is not here is going to miss, but they have a chance to look at it after. So yesterday when we did the rehearsal, I was going to say here, but I just decided to not go on the stage to realize his dream. So I'm going to be here. So they're closer to you and we're going to have a good time here. And then, the other thing is, I'm between you and lunch. So let's hang in here that you can have your good meal, and then fully recover. And another thing is probably this is going to be one of the last sessions for many of you on the Summit. If your first one was good and if this one is good, you can say your Summit was good from the beginning to the end. So that's my goal here. So we're going to talk about migration insights, some of the experience that we had during our migration recently, and then on the agenda that I have here today, we're going to talk about the planning and preparation phase, which is very important for you to walk through. Migration. The challenges that we have during the migration, plus some tips on how we overcome them.

Some feedback that we got from other conversations is what you do after you do the migration? And we're going to be talking about some tasks and some items that you need to do after you migrate and open for Q&A like Will mentioned. So a little bit about me. First, I made sure that I wear this shirt here to match the picture there. And actually, I realized this morning that I'm wearing the same shirt, but is just to keep the style like a Shantanu, like a quarter zipper shirt. So I got the memo, wear that, he didn't. So he mentioned I am an AEM Champion, which is a part of the Adobe Advocacy Program. I encourage any of you to join and apply for. This is open for everybody. I've been working the past few years with the product feedback with Adobe, helping, talking, making webinars, videos on Experience League, and brought me to be selecting these very, very prestigious group of about 30 AEM practitioners across the globe that we talk almost every day and we share ideas, we share product recommendations. We have a vision with Adobe. Adobe share with us what is ahead on their roadmap before many people see that we can provide feedback, so Adobe can deliver the best products for us. So as part of this whole engagement with Adobe, participating, sharing our knowledge with what I've been doing at Cox and in the industry. So I was very honored to be top three for the Experience Maker Award this year. So the Gala on Monday was fantastic, one of the best experience of my life and it was the first time I wear a tuxedo. So it was great. So again, this is another category, another program that Adobe has that is open to everybody. So if you have a good project, a good team, and a good individual that you want to nominate or apply, it's a unique experience and then it's something that we need to do just to make sure we recognize good people out there. I've been working on the Adobe Ecosystem for about ten years in our company, I'll talk a little bit more of what we have within the company. I have experience in Telecom, Automotive, Consulting and Retail space with focus on management and technology expertise.

A fun fact about me. So he said he does not have jokes. So when I was in college, I used to do stand-up comedy. As you can see my face is here, not at the MGM. So I'm not that good. So I'm not going to start talking too many jokes that people start leaving. So it's better to be here. Trust me. So a little bit about our company. So Cox Communication is part of Cox Enterprise. We're based in Atlanta. It's a company that just recently completed 125 years of history. Cox Enterprises has few divisions. I'm going to highlight two here. Cox Communications is the division that I work for. And we are about in about 30 states in the US serving some tech. We are in the telecom industry. We are one of the largest Internet and cable TV provider in the country. And we have Cox Automotive also. That is many of you may know AutoTrader, Kelley Blue Book, Manheim, and recently we had a stake at Rivian truck in pickups. So it's a big company, about 55,000 people around the globe, very good company to work. And we are always looking for the size of family company, for the size of that, and then we need to have the best products and the best technology that we can provide, the best we can for our customers. So with Adobe, I'm sorry, with those products and the company, I'll talk about the Cox Communications and I will highlight here a couple items, a couple products that we have, just to give you an idea of where, how we need Adobe or the Adobe Experience Cloud Platform to use on our products. And then you have an idea, the complexity or the simplicity of it. So we have an Internet and Wi-Fi product provider for commercial and residential services. We have the hotels, the Allegiant Stadium here. The Las Vegas Raiders Stadium is where the Super Bowl was. It was fully, Internet was fully provided by Cox. We have Cox Mobile. It was one of the products that we launched last year. Very successful. We had some good experience with Adobe and the tools that we use to launch this product very quickly, we use dynamic media. And we have a TV service, cable streaming and a Smart Home with devices and services. And believe it or not, people still have landline. So that's a big part of the business.

We recently, last year we renewed a multi-year contract with Adobe. We have pretty much the full stack divided in two groups. I work on the technology side, we have some partners here from the marketing sales. So I brought, those guys are here. They will, if I say something wrong, they're going to raise a hand and say that's wrong. So please keep me in line. So the entire Adobe Experience Cloud that we have, we have Experience Management, Assets and Sites on the technology side and when I say technology side, we manage the infrastructure, custom code and configuration, the user management, et cetera. We have Adobe Stock, Workfront. We recently enabled and started using this, very recent that we started piloting this. And the Creative Cloud, we have about 7000 users on Creative Cloud that's all handled and managed by the technology teams. But the Marketing and Sales organizations uses the other piece of the puzzle, part of the products, and then those are products that we use day in and day out very heavily. Adobe Campaign, Target, Audience Manager and Adobe Analytics. So all of these combined provide us the chance to give our customers and site visitors the best experience they can have, and then the tools that we have from Analytics, Target, we combine all of this to help the business make the right decision and deliver the right content for our teams. So we do have also AEP, CJA and Joint Optimization. But we are in early stage, we have some work that we need to do in data mapping. So we are not fully utilizing those three products, but it is in the roadmap to start applying and get the use there. So just to give an idea of the whole experience, we've been working with AEM, with Adobe for about ten years, when we migrated. So a little quick overview of our journey from where we were ten years ago and where we are today and what we're planning to do in the next few years. So 2015, we did our first launch, we did a 6.0 on-premises. We engaged with Adobe Consulting Services. They help us to prepare our infrastructure code and navigate through the entire launch process. We had at the beginning some performance issues that we had to retain Adobe to help us resize our infrastructure. We pretty much double the servers, double memory, everything, because we were having some performance issues, but we focused on system stabilization after we went live. 2017, we did our first upgrade on-prem, was smooth. We got some support from Adobe, but we did by ourselves. So it was a good one. Some introduction of new features, etcetera. Until 2018, we did an internal, we call Flex Components. We redesigned our entire system, our entire component library. We used to have 63 components and then we reduced to 23, 24. And then we gave the content authors the ability to really use the atomic design and a level of flexibility to create the experiences. That was remarkable. Four years ago, I think 2019, there was a presentation about this project during Summit and it was well received. We had some issues because at that point with level flexibility, we opened some doors for content authors in the business to do some CSI overwrites, but we fixed that and then we're evolving. 2022, we did our migration. That's where we talk about based on the experience we had. Like I said, we engaged Adobe Consulting Service for that. People can use as many, many people there on the pavilion that do that type of service. We just decided to bring the people that know and build the product, they have the knowledge, and what we're doing currently, we are moving towards a Headless CMS and then we are redesigning our entire UI framework using React. We are using more core components and having a very strict style guide and a design system that will allow us to just limit the number of components, have variations and then we can start a better go-to-market and still give the authors a good flexibility. And as everybody else, also, we have some AI projects. We are evaluating some integration with Express, Firefly, and other GenAI opportunities there. We are all in pilot, but we will keep going there.

Another feedback questions that I get before this is, how big is your team? So I know companies that they have to manage Cloud or Experience on-prem, that they think that you need to have a team of 100, 200 people, and then that can be a higher cost, plus it's not enough for Adobe. Our team is very, very lean but extremely efficient. So we have, the structure we have is a typical DevOps organization. We have a AEM Architect, a Dev Lead, a Technical Analyst, two Operations, that is a part of that you need to keep in mind when you move to the cloud, your operation folks will need to shift what they do because they don't need to manage servers anymore. They don't need to be worried about network. The Adobe Cloud is pretty much a blackbox for you. But the good thing is you can have those resources be thinking on what's next and thinking more, working on more reliability aspect and more monitoring alerts. We'll talk more about that. We have a Site Reliability Engineer with us and the team of developers in QA. They are all spread across US and India. That gives us, like I mentioned, the level of efficiency that is really good because I get about 20 hours per day between US and offshore in India that we can have work done in a very efficient pace. And the team is phenomenal and probably I am here and everything I do, I learned from every single person on this team.

Now we're going to talk about the planning for the migration. I have a question here. Who is on-premises now from this group? Okay. Anybody on managed services? Okay, Who likes fishing? Like fishing, go fishing. The fishing Summit is at the MGM, so you can go there. After this, you can go there because they have it there. I need to crack a joke sometime. College time, remember? Plus bash last night, so. And then, he asked me to play my walking song, Welcome to the Jungle, and I almost went to the stage thinking it was my time to talk, but then they hold me up, "No, not now." So let's go back here. So planning and preparation. So like Benjamin Franklin said, if you fail to plan, you're planning to fail. So what I'm going to talk here is not everything you're going to be doing. If you engage Adobe to help you and work for you with your migration, there is a plan, we're going to go through. It's very detailed and then any project management group can help. You have many others. What I'm highlighting here are very important points that you need to do that you should not forget that will guarantee a more smooth. There's plenty of other topics, and probably this can be a Experience League or a webinar based on feedback that I get from you guys, they need more information so that we can go through it.

The first one, and again, those milestones are not necessarily in this order. Maybe I should have called it another thing, topic one, two, whatever. But it's just milestones on your overall project that you need to pay attention because it's very important. So the first one is performance benchmark. So when you're moving from on-prem to cloud, one very in beginning discussion that you have with whoever's going to help you with Adobe, you need to decide what are your success criteria. And then one thing that is very important is you don't want to move from one platform to the other, that your page will load slower, your system will be slower. You need to have that criteria. We put, as a success criteria, performance. My page has to be loading faster or at least the same. And then this is a non-negotiable criteria. So you need to start preparing that. So one point you need to do is define the methodology that how we're going to measure the performance. There are stuff that the technology can control, others like third-party tags and things that happen after the page load, how Google measure with Lighthouse. You need to define that. Make sure everybody is in agreement, your team, whoever is implementing and your business partners that we know are measuring this. Those are the metrics and KPIs that we need to stick to it. And you run the first test as a benchmark on your on-premises. Select the relevant pages. Some people can be the pages with more traffic, others will be select your top ten pages or select all your landing pages to make sure that those pages will perform well after you migrate. So pick the pages that is important to you, that you can have a same comparison when we move to the cloud. Document the results where everybody can see, share with everybody. So when you finish, we're going to talk about it, you do a validation after the cloud migration. You will say, here's what was before, here's what's now. Review Dashboards. So this is important because some tools that we have there with dashboards, they typically retain data for 90 days. And then if you, when you go live, that might take probably more than 90 days. It's good to have a dashboard that you can take snapshots and you have history. And then once it is based on the criteria methodology that you use, you refine your dashboard, get this, and this is going to be your benchmark, your starting point. The next one is identify blockers. There is no project that I've seen and talk to people that will not have a problem, that will not have a blocker. So first one is your code compatibility. So Adobe has on their toolbox the best practice analyzer and the cloud acceleration manager. This is the step number one that will pretty much dictate the level of work and level of effort that you need to distribute across your development team because there's going to be, the concept of the cloud completely changed, the repository structure, the design that you're going to have. You still have the dispatcher and the publisher, etcetera. But it separates code from assets. And then you will need to change and make sure your code is compatible, your content is compatible when you run those utilities that Adobe provide you. So it gives you, I would say, probably 80% of the work you need to do. Identify code, which components you need to change, which utility that you need to do to refactor to be workable on the cloud. The earlier you do this, it probably going to be the first week that we have the report and then that will start helping you with the rest of the plan.

For the whole thing we talk here, this is one of the most important. Security can and will stop your launch if they don't approve. Adobe Cloud it's outside your network, it's outside of infrastructure. They need to get access from, a connectivity from other applications into AEM and then internal applications need to get AEM outside a network. Security needs to be involved early in the process so they can review the documentation, they can do tests as if they need to. Adobe does a very good job, and again, independent if you engage with Adobe or not, but Adobe as part of the contract, they do a very good job to provide us a documentation that we had that we used to our security to approve. So they provide all their disaster recovery, the disaster recovery process that they have. They provide penetration testing, and then they even provide a third-party attestation letter to tell that the cloud is secure, how they do to validate that. So that helps, but you need to do that at the beginning because I've heard stories that a few weeks before some companies go live, there's a missing item on the security that they can block your launch. Work on project conflicts. If your company has a campaign that's coming up live or you have a hard deadline with the authors to create a new page or new content, there's a period at the end that you're going to have a content freeze so that people will not work. I'm going to talk a little bit more, but identify all the project conflicts where you see that projects on your company, it will collide. That you need to work around early on that planning. One big thing on your team, you will need to support two infrastructure. This migration is not like a week thing, is several months and then during that time, your business show must go on, your business as usual. You will have new requests, you will have new components. So especially your operation dev team will need to support two infrastructures until you go live.

Stakeholders Engagement. So get the team that you serve, content authors, your business, all your stakeholders involved very early in the stage make them as part of the system because the interface will change, right? The interface will change. It's a different way when you go to the site, you go to open a site. So open assets. The visual, the UI is totally different. So get the team at the beginning because they will serve and provide you a lot of good input for it during the process. They will help you through the testing. But important to do some training sessions. The earlier you start promoting and having webinars, and having one one-on-ones, prepare documentation, start training the stakeholders they're going to use, the adoption and the level of resistance because nobody likes change. And then if you say you're going to change the way you do your job, you're going to change the way you do your pages. You do that, those training sessions, you'll have lot better acceptance for this. Document the processes. There's some processes on user creation or how to manipulate page and content, some stuff will change. So make sure you document it and have that information out there, and treat everybody as one team. There's no-- If it fails, my migration is not a fault from the business partners or stakeholders, it's not a fault from your team. It's one team. You do that, I can guarantee that you're going to be successful. The last one on this topic is Assets and Utilities Documentation. So imagine if you are moving to a house, you have boxes in the attic for five years that you don't use. It's the same thing. If you're going to move to a new platform, a new repository of your assets, make sure you clean that. There's a lot of images and pages that are not relevant. They are stale. So just clean it. That is better and will help you when you start doing the content migration per se if you move it clean. You go to a new house, you want a new furniture, you want new pictures, you don't want to have a lot of clutter there. That help not only performance, but help you start fresh. Organize your taxonomy. There's a good opportunity to do that. Get a damn librarian that can help you organize your folder structures. We did not do that. So we did not do that. And then there's a price you pay because it gets the content a little bit confusing. But do that cleaning before. Document your custom utilities. You have utilities either to get data from outside or data we communicate out. Identify dependencies. You have upstream and downstream dependencies that might need to do some code change as well. They need to refactor the code to use the cloud. So if you have that identified earlier, it's much better. And start preparing your content migration. Not only that cleanup. You start talking with your content authors and your teams to say, here's the time that we're going to have a content freeze and then start planning that. So let's start talking about some of the challenges that we face, the methodologies and some tips that we used to overcome those challenges. It's naive for you to think that your upgrade is, your migration is going to be easy. It's not an easy process. There's a lot of work on the code. There's a lot of work on security. There's a lot of work in connectivity. So you need to be sure that you will have problems. But what I want to reinforce is we did our migration end of 2022. Since then, we saw a very good evolution of Adobe products and in the cloud, several new updates, code updates that they did. We will talk about some of that process, because that's another thing for people on the operation side. Your deployment process, your release process will change significantly, some better, some a little more process-oriented. But what I want to say is, what I'm showing here is probably you will not face, but if you do, you know how to fix that. And the other thing I want to say is we used and leveraged Adobe Support and Adobe Team on this. And then, every challenge that we had, we worked together to find a solution. So the first one is content migration and authoring. You will need to probably a week depending on the size of your repository. We didn't have a gigantic repository compared to other companies, but you need to at least a week do a content freeze and then you're going to use the CTT, the content transfer tool that Adobe provide. But you need to negotiate that with the content authors. The importance to have that negotiation with them is they're not going to be able to touch it because the intention is you want to have your on-prem content, you're going to move everything to the new infrastructure and you want to make sure they are at sync. In case you need a rollback, you have a way to do without a lot of cherry-picking on content. And there's another thing, once you move to the cloud, I'm 99.9% sure that you cannot move content from the cloud to the on-prem. So when you do that migration, you cannot go, oh, I need to go back on my on-premises infrastructure, and do it. You cannot do that. And then you will block content authors while the content transfer tool is running. So how we do it? Use the Content Transfer Tool in batches, so we had problems when we tried to pull and then like I said, our repository was not gigantic and we tried to run the CTT tool in one shot. And after two or three days of the system running either connectivity or some corrupted file, it crashes. So we had to stop and then reset everything and start it again. We tried twice, it failed. And what we did and then that delays my authors because I had to extend my freeze period. So what we did is we used the CTT tool in batches. We get chunks of content, pick, transfer, and then that works perfectly. So it's much faster in pieces and be ready for one-offs. There's always, always, because we as a technology team, we need to be always ready to support the business. And then there are business initiatives, there are a page that needs to be, there's a regulatory that you need to update, there's going to be a urgent notification to put on the page. Maybe the authors will need to make a modification, but those are one-off. You need to make sure that you have that covered.

User permissions. To me, this was one of the biggest change in terms of operational aspects. The user permissions challenges are related to the process to create new users. Adobe and our security team and I believe that all you guys security teams will ask the same. You need to be using a Federated ID to access the Adobe Console, to access the AEM Sites, Assets and everything. Everything needs to be federated. You need to have a user ID on your company or federated to other company, but you need to have that, that process will change. What we recommend is, and then talk about the user permissions. The way that you do permissions for folders or you give permissions for publishing, it changes. On-prem, typically you get the rows and have the type of folders you have, you just put write, read, write, read, write, and you just save, it's there. This one, the way we have, that Adobe has for us is a lot safer and a lot easier after you get used to the process. But it's fully active directory that your provisioning team will provide, is fully active directory that is integrated with Adobe IMS that you can manage instead of going individual and see, you can access here, you can read them right here. You give all the permissions, you set groups and then once you set groups, the system sync with your LDAP to Adobe IMS and then all the permissions and access is available there. So this is a little bit changed, how we fix this. Test those permissions on lab, Start asking users, end users to test this, you have your own operations, your team, your dev teams, test those in labs before, so you'll be able to see if it's missing a group, if a group is missing a little configuration. So you do that and communicate the new process. So before, to get a new user, it used to be an email or a team's message, hey, I need so and so to have access to this folder, to publish something or to upload an asset. Now they need to go to our provisional team, open a ticket and say, I need access to Adobe. And then as a matter of fact, in about a month, we're going to have that per lab and per type of user group. That will be like a significant improvement on the operation side. And like I said, owned by team, we can do improvements that will help overall instead of be looking, what is the server broken? Because in the cloud you don't need to do that anymore.

Security, I said before, is one of the most important point, security and connectivity. You will have connectivity problems with third-party applications. You will have connectivity problems with your internal applications. When you get security reviews, you start asking either upstream or downstream applications that you need to reach out to AEM and then start asking IP ranges, egress IPs that you can communicate to your firewall teams, to your security teams to review those and start working. At some companies, it may take weeks, if not months to get that into the pipeline to make it work. So the earlier you do that process, the better you have a chance to have all those changes done by your launch date because you do not want to go live without important application that cannot access your assets, cannot open your page, or most importantly cannot provide data that most of the pages either pricing or product information. If your outside application does not have that information because it does not have access, your page will be with open or broken content. How do you do? Like I said, early security review. Those are, you need to keep those guys on check because they, I will not be tired to repeat, they will block your go live. They will. And then in any serious company, they have the authority to do that. So don't think that, I don't want to deal with security team. You have to. And the earlier you do, they will be helping you because at the end of the day we want to make sure that we are not open a list of IPs or whitelist those IPs that the company changes. And the other thing is services like AWS, they have a practice to change IP ranges. If you go to AWS CDN or Cloudfront, they change IP ranges almost daily. So if you don't update that even after, you will lose access to some of those CDN configurations. So you need to have firewall and security team on a speed dial as an urgency P1 open, I need you to whitelist this. If you have a good documentation, show what they will do for you. But this is something very important that you need to work on.

For operational folks here, visibility monitoring. You will have restricted access to logging, period. If on-prem, you can put your logging level to info, you can put to warning, nothing. You have errors, Adobe will not open this for you. They have access but you will not have visibility. So you need to revamp your dashboards to make sure that you do Adobe providers access to their new relic instance, but it's more visual for APM and the server to see performance, we see CPU performance, but you need to, you don't have access to create alerts or create anomaly detection or create synthetics on their new relic. So you need to go to your operational dashboards and start creating on page level and then start to find ways that you can detect anomalies that can prevent and allow you to be more proactive to fix a problem before that happened. So what I say is adjust your monitoring alerts. Like I said, you will lose that ability to go deep on every server and get data from it. You have access to those logs. We upload all the Adobe logs daily. It goes to Splunk. But one, is not real time, and then two, it's limited because when we launched, there was a problem we had. When we launched, we had the logging level to, I believe, error and then the servers could not support the amount of a logging to do. We have to remove just to info and then that's it. But the important is when you go to the cloud, their support system, the cloud is good, has room for improvement. I've been working directly with the support team to improve this. That's part of the feedback program and we've been providing some feedback. Things are getting better, but in this case, leverage the Adobe team because they will have access to all the logs and they will help you to troubleshoot and get details. And then if they find a wire exception happen, they can give that exception and then you can get your team and fix that.

The last challenge that we have is cache problems.

There are changes on your CDN configuration, you have an option to either use the CDN that Adobe provides. Adobe has a CDN that they provide, but you can bring your own. We decided to bring our own because, and then it is a case by case. There's no right or wrong. In our case, we use AWS Cloudfront because it's the level of complexity for our caching mechanisms, our caching policies, the out-of-the-box solution that is not Adobe. There is a third-party CDN. So the complexity level that we had, they didn't have out-of-the-box. But you need to make sure you have configurations, X-Header, and I'm not going technical here, but you need to make sure your policies are correct and then you might have some content issues if that is not right, because you will need to change policies and your caching mechanism if you're going to be based on a cookie or based on several criteria that each business individual will have. And what we did is you confirm your cash policies. You will need to validate every scenario either if it's, and again, so many cases. But if you have a content for a prospect or a content that is different for a customer, or a content for one region is different than the other region. And if you don't test because your cache, the cache is if it's out there on your CDN or in Adobe, if you don't have the policies, make sure they invalidate the content correctly or you don't leave stale content there because you don't have this configuration correctly. So what we recommend is leverage the heck out of your automation testing to make sure you cover all the variations that on top of your functional testing team. So get them to have your script to know what the variation that you do, that you are sure that if your content has to be for prospect, the customer will not see and vice versa. You don't want a customer content to be displayed because for some reason your caching policies are not well configured. And then you will have some. There's some configuration you need to set on AEM that needs to match the CDN. You need to have one of those utilities I mentioned earlier that invalidate caches when the author click and publish a page or publish an asset. You need to have that like a well-oiled machine that you press a button and it will validate the cache. You go across all the distributions and in AWS, it goes all across all the edges. Take a couple minutes until everything is refreshed, but do the automation test in that you can easily catch some of the different content that you might have there. So how we are we on time? No, we're good on time. Post-migration tasks. Support process, it will not change. You will confirm your support model. Normally, the only thing that would change in your support model, you're going to add the Adobe Aspect because it's a cloud service, as a service, typically if you manage your application, we, your support team will get a call, hey, this is a problem. Now you have Adobe Layer that will do that. Set up a quick response team. So the day of you will have a bridge, 24 hours, maybe two or three days for everybody with problems, access, caching, have that team ready to jump on a call and then they will be on the bridge and then solve those problems because you have a few hours or probably a few days until you can make a rollback. And one thing I forgot, so this part of the migration plan is I divided this in two pieces. A task that you need to do days off after you migrate and then others are going to be weeks or months after the migration. And they have a good tracking system, either Jira or SharePoint, whatever you have that works for you and your team, that people can go to your if they have issues, they can open and you track and you don't forget anything. You take care of your customers. Backup instances. This is important. Everybody is happy. We migrated. Don't pull the plug yet. Don't pull the plug yet because somebody will have, I forgot this content that's still in the cloud. So you will have people or some content that I need this because the content tool missed folder or something like that. So keep the servers up for a while because that you might need this, for a few weeks. A few weeks, everything is stable. I will talk about a little bit more on this. Have a rollback plan. The rollback is fairly simple. It's a CDN change that you change your IPs egress and it's just a five-minute rollback. What you do is you just divert traffic from either the cloud or your on-prem, very simple rollback plan. That's why your content needs to be fresh and same on both instances. And then content authors will not be able to do any content change in the first few days. In case you need to rollback, you don't have the content mismatch. About a rollback plan or rollback. We did actually before go live and I should have mentioned here, but I'm saying, we did several processes on the rollback. The rollback with Adobe is better, but we had some problems, so we recommended everybody to do, and you can take notes on that one. You do a rollback for your code, your custom code, you do want that, but you do a whole thing. Push a new code, rollback to the previous version, and then you do a full backup and restore. You get your entire content, erased, or make a backup, and restore and see how that works. And then you're going to do AEM Cloud code. Push a new code, rollback to the next one. We had problems too. That thing crashed during the lab. The whole thing crashed. They need to fix, and then you need to do a full disaster recovery. It's like, if everything crashed, how long would it take for me to restore? And then the way the cloud works is all the pods and the way the infrastructure works is a fairly simple process, and then it runs smooth.

Performance, first slide in the back. Now at this point, you need to run some performance tests just to make sure. The same pages, the same criteria, the same metrics that you used. You're going to run this, and then you're going to tweak your dashboards if you need to, just to make sure everything is matching that you compare apples to apples. At that point, you're not changing your pages. The pages should be the same. You don't need to change content for the cloud. You change the backend. So tweak that and review the results. Review the results with your shareholders, with your team, and with the company that you implemented, just to confirm that everybody is in agreement. Is this better or worse? If it's better, everybody's happy. If it's worse, what can we do to do? And then you get the quick response team that I mentioned that they will go there based on feedback. And then I start reviewing this.

Very important thing, stop the release orchestration. Adobe Cloud has an automatic process to publish new code on their instance. If we had it, we didn't do it. And then they will push to production. And if you are not fully aware of how the process goes, and then if the versions that they have is not compatible to your custom code, it will break. And then if you don't pause the automatic, that they call release orchestration, they will push it. They will tell you when, but they will push it. And then you break things on your production. So we recommend you to freeze orchestration, open a ticket until you stop the automatic upgrade.

Get used to the deployment process. The deployment process is long, is in on-prem. You typically three, five minutes, you push code, your system is there, right? It's updated. It's getting better. When we did, it took an hour, One hour to push a code. There's no more push a code, five minutes, check now. No, it is one hour. You go one hour. From when we launched to now, Adobe had to me a significant, and now it's about 30 minutes, but still, it's completely different than before. But it's not because the system is low. It's every time they push a new release, they kill that pod and they rebuild everything and they get the content and put in that pod. Depending on your design or infrastructure, if you have ten pods, that will happen ten times. But the beauty of it, which is much better than on-prem, is you don't have downtime because it's one pod at a time that goes slowly rebuilding, and then your customer will not have impact. We still do releases during the night for other reasons, but with the cloud, you can do a release in the middle of the day that you have no performance problem. So this is one huge advantage. But get used to the deployment process.

Start reviewing and getting the notifications from Adobe of the release notes, what's coming, so that you can see, oh, I need that. Oh, sorry. I need that feature that it's coming. And then you're going to go push that code manually. There's a new feature, a new security thing just you can do, you need to get used to it because the pipeline will push to the labs, will go to staging, and then after that you go to production, so then you have more control.

Weeks after the migration.

First few weeks, your only focus is system stabilization. Is the system working? Performance is good? We fix the critical items, we fix the content problems. That you need to keep focus on, reliability, stability of the system. Run few AEM upgrades. If you know what's coming, just so you get familiar with the process, with the pipeline, how it works, how the approval process, the workflow works. And then when you get familiar and everything is working, you can start decommissioning your old servers. With your old servers, it leave you there for a while. There's no traffic coming, but your infrastructure might need that range of IP to use for other applications. So at that point, a few months later, two months, I would say you can start pulling the plug. And the important thing is you're going to work with your network team to remove those IPs from your load balancer. And then at that point, you should be able to go and start talking to Adobe to unfreeze the automation process, because you already have your automation testing in place. You have all these scripts well organized that you can unfreeze. And then that's the beauty. If you have a process in place to test in the labs when Adobe is ready to push, you don't need to do anything. You're going to get the latest updates.

I know that what stays in Vegas, what happens in Vegas, stays in Vegas. But what I want, you take those things home. So a few key takeaways is document, plan, and organize your assets and your infrastructure. Two, deep dive on architecture and design is a fantastic opportunity for you to redesign how your things work because you're going to refactor, you're going to redo a lot of code, you go deep to that, you may need to do some changes. Use all the tools available. And again, those tools are available for any user, regardless if you hire Adobe Consulting Service or not. Adobe provide you all the tools and needs that you have for you to be successful. Redesign the monitoring alerts. Like I said, you lose some visibility, but you have the way that you can redesign those. Test, test, test. Automation test is going to be your friend. Invest money on those scripts. Invest money on good people that knows how to do that, because that will help you, especially on the automation process.

We normally took about three or four days to validate the Adobe version in one environment. We started leveraging the automation test, we do in 3 hours. That in five days, we test the whole thing and we say, Adobe are good, they pushed the code, we're good to go. And then your users, they are the primary benefactor of this. Make sure that you give all the details, you give all the information they need and support that they can use, the tool, at its full capacity, and use all the features that they provide. So anything that they have come with the problems those few days, a few weeks and few months go right, go fast because you have a happy customer, you have less tickets to fix stuff. That's it. So this is how you can connect with me on LinkedIn. I have my other friend here that we lead the AEM User Group, Mary Alice Orr, that she just did a presentation here. So for whoever is on the southeast of US, we have those meetings once a quarter to talk about this or any other topic that you might want. And leverage, also, when I say Adobe support, go to Experience League. There is a lot of good information. We participate in the feedback program for the new version, so it's much better than how it was before. So there's plenty of information for certification, documentation, blogs and information. So this is like three videos. On this link, you may find three videos here that I did about this. I didn't publish this before. It's live. But I didn't want to give a sneak preview. So if you want to listen to my boring voice again so you can go there and then see it.