hello and welcome everybody um Welcome to our 32nd I believe platform Academy in this setting uh thank you everybody for joining us and making it across the daylight saving time hump that out of the way um I am very glad today to be joined by my three colleagues from our product success team and just a quick shout out before we head into things I love that all of you have the knowledge background so for everybody who has not signed up yet or is not joining us as a speaker a Creator con our knowledge be sure to make sure if there's budget and you can travel to come join us in Las Vegas May 14th through 18th this year we'll have our first big in-person knowledge again since the pandemic started and I'm so so excited to be there hope to see all of you there um I will be doing such about pattern playbooks and also flows workflows decisions all all these good topics and before we had too far into it I guess I should introduce myself my name is Lisa hobenstein I'm an outbound product manager for the now platform my main focus is you may have guessed from the topics that I cover at knowledge is workflow automation so uh I am very uh happy to have you all here um I'll hand over the introductions to Paige uh hello Paige Duffy as Lisa stated I am a product success manager here at servicenow I primarily work in the Creator workflow space but we often cross lines uh between kind of the side I work on and the side that Jerry and I got to work on for platform um plus I just really like to talk about upgrades in fact if you Google me you will find a session from last year that I did at knowledge on upgrades so it's just a passion topic of mine uh yeah I will go ahead and turn it over to who whoever is next I don't actually know which of you are next so let's go with Miguel hey it's me again Miguel Miguel daenery uh like Paige I am also a product success manager I'm part of her team but Meyer is more the platform happy to be here again and thank you for your time appreciate you coming out here and spending time with us awesome and Jared hey I'm Jared Mont another product success manager here on the platform team so looking forward to talking about one of the newer editions in the platform Suites upgrade plans here today you've probably hopefully all seen this before um since we're talking about upgrades we may be talking about coming features uh in future releases of cersnap on the now platform and just to be sure if we do make any forward-looking statements uh please don't make any purchasing decisions based on them yes so uh this session is part of a webinar series uh this platform Academy runs every other week um we usually cover uh platform topics workflow topics and all kinds of things that are relevant to developers and admins we are part of a larger set of academies now so if you follow that link that you also follow to come here there are other academies led by my amazing colleagues covering next Experience mobile virtual agent conversational interfaces AI platform analytics and all kinds of other amazing topics so be sure to check their academies out as well so with that I will hand this session over to my lovely co-hosts yeah thank you uh today we'll talk a little bit about the what upgrades have looked like historically and what some of the problems that upgrade plans are here to solve uh go over some of the components of upgrade plans uh the order of operations how you can get it set up in your environment and then also go over some of the frequently asked questions that we've seen out there in the world so far on this topic and then once we get past all that if there's something still specific to your your particular use case uh we'll have a a couple of slides at the end for uh q a and let's take a look into some of the history and and how upgrades have worked in the past already so um you know we're starting with kind of a basic timeline there are a variety of versions of this out in the servicenow ecosystem but this is just kind of your simple um you know Dev to test a prod timeline it should be pretty recognizable you should really always start with reviewing the release notes um you know some of these points change with the upgrade plans that particular one does not um next you know make sure that you clone down your uh production instance over to your Dev instance before you start this process you will see an asterisk there and we'll cover it a little bit more in the next slide but that should be a full odd like I should include all of your audit data and all of your attachments from your production instance you basically want that instance to be as close to production as you could possibly get it um then kind of the normal upgrade your Dev environment do your review of skipped records I I will be honest when I started this which was what 13 years ago now um we did not do that we did not know we were supposed to do that there's not a lot of documentation out there uh so don't forget that because otherwise your three three versions away and you have a ton of them and things aren't working properly so fun fact I did that but I had very very few uat testers in my company I I've had that too I was the uat all right so we review those um in this timeline in in you know kind of the upgrades past the upgrades that we've done up until this point when you're reviewing those you're doing that review in an update set um those reviews are captured within the update set any changes that you make are captured within the update set typically you've got probably five or six or seven or eight update sets hopefully you know update set batching and you're batching them all together but you have an update set for each scope that you're touching um so you have a lot of them uh then you kind of move on to the next step you clone down to your next non-prods you move those update sets up um you review just to make sure that once again you don't have any additional skipped records hopefully you don't hopefully you're not doing anything in those non-prods that aren't that isn't coming up from Dev but it happens and then once that's all done you start doing your normal uat hopefully hopefully you have people to do testing um and your automated testing from there we repair any defects um usually you're doing that down in your Dev environment and promoting it up again and then you start scheduling your production upgrade uh update your pro your production instance and then of course move all of your skipped record update sets and your defect update starts into production um I did not include it on this because it feels like it didn't belong but also somewhere in there you're communicating all of this with your uh with your stakeholders and your business so no communication that's crazy yeah you don't want them to walk in and be like why does everything look different um especially for that San Diego upgrade when you're going to uh next experience at some point yeah yeah to communicate that yep um so that was kind of the the upgrades past timeline this is more just recommended practices I'll be honest most these practices they will still be valid just as valid if you're using up upgrade plans as they are today um so and a lot of these are things that I have learned over my many many many many many many many many many upgrades so uh first off try to resist the urge to activate new plugins or applications as part of your upgrade I know we all want the new shiny things um when when you're you're getting that new instance and you want to play with the new things try not to do that um this helps to reduce the risk of defects and then it really allows you to focus on delivering that nice upgrade experience so you're not cluttering things up with with additional stuff you're just focusing on your upgrade um and then that kind of leads into the next one which is split your regular release from your upgrade so at the same time that you're not activating a bunch of new plugins don't throw a whole bunch of new stuff into production too while you're doing your upgrade wait a couple days even a couple of days will give you a little bit of leeway and help you ensure that like the defects you're getting in are actually related to the upgrade and it just it makes a much smoother experience um this kind of leads back to something I mentioned in the last slide but clone prod to sub prod just prior oh sorry that's a different one but um if you can and I do realize that this is a nice to have and not every customer can do it but if you can clone your production instance down to your sub production instance just prior to your upgrade not everyone has an instance that they can leave sitting there for two weeks with an old version of their production on it um but it's really nice to have so if you have someone that reports an issue in your production instance you can go back and look at your sub production instance and see whether or not that issue existed in that that sub production pre-upgrade version of the instance and it really helps you to kind of figure out what issues were caused by the upgrade and what what issues are just issues doesn't change that you need to fix it but it might change how you prioritize it and it it changes the perception of the upgrade for your audience for your users and then the last one is um using the upgrade of your Dev instance to make kind of an educated estimation of how long your upgrade's going to take so since you did that clone that I apparently forgot to put on this list but we mentioned in the last slide but since you did that that clone down that had all the audit data and all the attachments and it was as close to production as you can get for a clone when you upgrade it it should be fairly similar to how long it's going to take to upgrade your production instance and for me I have found that this has been a really useful way to go why is my upgrade suddenly taking six hours when in the past it's taken three that changes my my change window that I have to put in it changes a lot of stuff that I have to worry about um but it also gave me an opportunity to look for ways to shorten that upgrade okay so now I know it's taking six hours why is it taking six hours and I was able to use the upgrade monitor there's some stuff down at the bottom where you can kind of see um you know how long different plugins took to to activate or um upgrade as part of that plug-in and you can even potentially go ahead and do some of those things well before your upgrade to shorten your upgrade window I was able to do that to go again from like a six hour upgrade to closer to a three hour upgrade which is what we were used to let's move into upgrade plans which I believe Miguel you're going to take us I am taking this all right so what is an upgrade plan right so an upgrade plan something new that came out in Tokyo uh but nobody's really had a chance to use the app because obviously Tokyo Utah so Utah's coming out um so we want to cover this real quick all right so basically what is an upgrade or what is a what it is and what it does for you so the best way I can describe what it is upgrade plan versus the human error component upgrades right so it's really just the consistency of the deployment right so upgrade plans right what they do is they capture all all your posts upgrade tasks uh your your any changes you make to your skip records like you're fixing them any plugins you have to turn on as part of the upgrade it captures that any changes you do to your custom applications or your custom store apps right those customization to your store apps so it basically captures all those for you all those all those tasking and changing and then it encapsulizes them and it makes a deployment to your other instances a lot better the upgrade plan um components right so it's components of the upgrade plan so the really the the the ones you want to highlight the most is the app repo um upgrade plan is really tied to agreeable it's dependent on I repo so you need that repo for this to work if you have a builder instance which will go into a little bit more detail what that means you have a consumer instances the upgrade plan and the plan items right so the Builder instance the Builder instance is real the designated Dev for your upgrades right it doesn't mean it has to be a Dev instance it can be any instance you want to do to for your for development of your upgrades and I've seen a lot of people a lot of customers have a regular Dev instance where you're continually doing your devs and then you have a clone of your prod and you're fixing your your upgrades there right and then or or you know clone the latest version of whatever it is but there's always like two development instances so whatever you decide your development instance is that's going to be your designated build developer and we'll we'll teach you how to how to um set that in there your system property but one caveat I want to I want to mention here is that once you designate you have that to be your Builder you're kind of stuck with it right you you can't really change that um and if you want to change it you have to put a high support ticket and and basically what your Builder does is it tracks it builds it and it publishes that upgrade plan right so it tracks all the changes you do it creates that upgrade plan it builds it and then it publishes it to the app repo your consumer instance right you can have more than one consumer instance and that's just the people consuming the upgrade plan or your instances consuming the upgrade panel right so it's going to retrieve the upload update plans get a process it for you in the background it's got to go ahead and apply those changes uh and and result like it'll show you right so it was all those things so those are the kind of key Concepts you want to want to look at now when it comes to the the sorry when it comes to the upgrade planning upgrade upgrade plan items this is really more of of how you track things like an app repo thing so when you go to apparepo you'll see these in there um and it's kind of like a hierarchy system right so you have a a one upgrade plan for all your changes and and there's only one you only allowed one per version or patch right so if you have Utah patch zero right the first guitar release you're only going to see that upgrade plan for Utah right you can make another one it's only one uh and it'll block it off later on when we walk you through it you'll there's a little button that says build it kind of Grays it out so you can only have one um so you have Utah patched one it'll come out with another one right so you can have another repo for that um and then under that to upgrade items and those are where your changes get captured in and there's a this is kind of a layout what it looks like on the screen so you can kind of see what it looks like on real time all right so the flow of operations after this is all config so we we've simplified the various steps on this on this flow and and so the we'll start at the top left and we'll go down over to the right and then back up so we will first upgrade in this case it's our Dev instance that is marked as the Builder we will upgrade that to whatever release we're going to in this example use top hatch one and then we'll go through that exercise of confirming the skips reverting to out of box whatever whatever action we're going to take on those skipped records if if we do have any um new features new plugins new store apps or upgraded store apps we can do that at this time as well but as we mentioned earlier uh it's probably better to move new functionality in a separate add a separate change window after we get all of our things skipped and everything settled we will build the upgrade plan from the upgrade plan console and then hit publish which will throw all those records over into your customer app repo and then from then this next process is the same whether it's on tests QA pre-prod and then eventually prod where we will go into that instance and install the upgrade plan from the repo then there Step number seven uh is is kind of a catch-all where it's it the system will do some processing of the upgrade plan uh that is tied in with step eight so when we actually kick off the upgrade for in this example the test instance uh will will do the upgrade and also consume the various records inside of the upgrade plan and then at the end of the day we will have a very consistent way of processing that upgrade uh all of the same steps will be run in all of the same Order each time we run through this like Miguel said at the top of the show we're taking some of that human error out of the equation and and making it extra consistent you know I just realized one thing before we move on um and I don't think we put it anywhere in the stack but it is important that you can't do this unless you're currently on Tokyo um yes sorry yeah you have to be on Tokyo in order to use upgrade plans as you're upgrading to Utah yeah it came out in Tokyo so you absolutely need Tokyo yep so this this release is actually on Premiere because yeah when on Tokyo you were already on Tokyo so you couldn't use it for the upgrade to Tokyo but it's available now yeah cool now let's get started so what do we do to get this started so the first thing you want to do is obviously locate it right so on Tokyo and above it's going to be on your your upgrade Management Center menu item so it should pop up um upgrade plan um if it's not there there is a plug-in uh it's called upgrade to customized uh and you know it should be out of there but most time it's there but if not just check that plugin make sure it's installed all right first thing you need to do we talked about it earlier is you need to designate your Builder instance right and and how you do that is in the same upgrade Center there's an Administration right menu option and then a property in the property all the way at the bottom as you see upgrade Prime um properties and you just switch it so I can do is switch to build but you got to keep in mind that the moment you set whatever instance it is to build it's stuck on build right so if you if you made a mistake and you could change it you have to put a now support ticket in for them to go in there and change it for you now this is a general overview again of the process we're going to walk through each one of these steps but just real quick it's it's the same process that Jared just went through kind of simplified right the upgrade the uh skip process of the skip records the building Health grade plan and then the publisher that great plan and then you install it or you retrieve that a pre-plan um it processes it automatically and then you upgrade your instance right and the last part you get to do multiple times in a different instance the top part you're gonna do just once when you do the dev instance I am going to kind of walk you through what this process is like I know we've we've shown you a diagram and we've shown you the steps but now we're just going to kind of actually show you what that looks like um so Step One is obviously to upgrade your Dev instance that is as is normal you should recognize the screen if you've ever done an upgrade before um should not be surprising uh next again still perfectly normal go through and start processing your skipped records oh well hopefully perfectly normal [Laughter] um this this again is is everything you've normally done but this is where things start to change so now we've not built any update sets so I guess that part of the script records is technically different you did not create any updates that's when you started that process instead after you're done with all of your skipped records you're going to go to upgrade plan and then you will click the button that says build you can kind of see it right up there in red you guys can't see my mouse circling around it but it's the one that's in red that says build and once you click that you'll see the the um the second screen where it's talking about are you ready to publish your app and then you click build upgrade plan when that happens that's when it's going to go create an app for your upgrade plan this is the shell for it right so it's making that shell um so this is actually inside your upgrade plan when you go into that upgrade plan that you just created you'll see the upgrade plan items at the bottom basically you'll get an item for each scope and that's each scope that you actually had something that you addressed within your skipped record so as you can see here we have data certification because we had made a change prior to our upgrade when the upgrade came through it showed that as a skipped record we skip record and so we got a new uh item for that skipped record well I see something kind of cool on this page yeah was was the the export button that I see here so we have publish which sends all of these things into the app repo but but I want to call out that hidden kind of in plain sight export button before we move to the next slide yeah so it's it's a it's a little misleading um I when I first clicked it I thought it was going to do something like you know export it to an update set kind of like you get with your apps what it actually does is it exports a Json file and if you were to open that up you would see um a Json package that's basically something you could use if you ever use integration Hub there's some spokes to install plugins you could take that Json package that it provides and it's got all of the app information that you need here to actually install that automatically um so a little misleading but kind of cool if you ever have the desire to do some sort of automation outside of what we provide very cool and I think that overlaps with the next slide that we're looking at here too yes were you actually going to install it you've built that upgrade plan you go and you click publish which we kind of get past that but there was an arrow you go you click publish that actually charges everything together um I did want to make one point because you're right Miguel I misspoke I said data certification was a skipped record that is not that is where we activated a plug-in um and I believe we did mention that if you activate plugins while you're in this process it will capture that activation in your upgrade plan so for the people who like to I don't know upgrade their instance and turn on some plugins to play with them but don't actually want them to go into prod yet be aware yeah and it will move it with it yeah I just wanted to call it out just just know that it does get captured but separately right so if you're worried about where is it at it shows up separately but if you also want to upgrade your instance and upgrade CSM and SEC Ops and hrsd and everything else to the current versions and do a holistic test of all those updated versions this will capture that and make sure that nothing is getting forgotten about on any test instance or production instance all right go back to this one I'll do it publish once you hit publish it goes to your repo um at this point you go over to your sub production instances next to your line you have not upgraded the sub-production instance yet it is still on the previous version in this case some sort of Tokyo so you'll go into my company's applications you'll find your upgrade plan it'll look just like it does here um obviously with whatever patch and version you're upgrading to and you will install it and you want to make sure you do that before you ever upgrade the instance but once you've done before before there's some uh there's some fancy automation that happens but it has to be there in order for the automation to happen exactly yeah yes or if you're using that CI CD spoke and you want to virtually press this button with the API you can take that exported Json payload uh load that into your CI CD um it and push this button all of your instances all right so now that we have our upgrade plan installed in our next Target instance you can go to your upgrade preview and that upgrade preview is going to show you your upgrade plan as well as some information around the things that you've already skipped um and it generates this quite quickly because technically you've already done an upgrade and you've already got your upgrade plan it's feeding in that information so if we then move to the next step we're going to go upgrade our subprod so now you're going to upgrade that that well it's a prod or prod instance um one setup creates complete it's going to actually automatically apply everything from your upgrade plan so it's a little bit of a different process than what you're used to with your update sets because you're applying that before your upgrade but because you're applying it before your upgrade it's automatically applying everything in your upgrade plan you don't have to go hit any more buttons once the upgrade is complete it can add a little time to your upgrade because it's doing those things extra on the end so that's something to be aware of but it's probably time that you would have taken anyway it's just taking that manual piece out of it no more no more following a guide like deploy patch one before patch four years yeah we get KB articles and releases that would tell us you know what to do yeah yeah skip don't worry about this this issue to skip it right yeah exactly maybe uh we can address some of the questions while we're heading into the FAQ part um we've had a good question in uh chat if the export functionality only available is available via integration Hub As I understood you just now is the export button will be there for anyone but the Json file that you get from it is only usable if you do have the CID CI CD spoke right um not necessarily it's really it's really just what the API needs so you could use it technically outside of that spoke as long as you're connecting the same API it's expecting that that same package um because you're in within the same instance it's not an integration Hub thing because it's not an outbound call and then uh we have something is there anything that is currently not captured by the app upgrade plan or app repo are you aware of any limitations defects so if you are if in the middle of your testing you find a defect and you go back and fix it that is still something that you would have to manage with an update set well and and that we have another question that is very similar to that where um regarding a defect push and so if if you are remediating that defect and and promoting that fix through a scope or Global scope that is being pushed to the app repo then yes the new version of that repo can be deployed as part of the upgrade plan uh but if your current process for fixing defects is not involving a global scope or a scope in the app repo if you're doing update sets then yes that would have to be a separate uh a separate process outside of the upgrade plan awesome thank you all right so keep keep sending in those questions to the Q a console we do have a couple pre-loaded ones that we have been hearing prior to this session uh so the first ones if a plug-in gets captured in Dev and gets caught up in an upgrade plan but it does not have a production license what happens when you go to upgrade your prod instance and the answer to that is basically it's going to skip over it so it's not going to install that plug-in in production if you're not licensed for it it'll just skip over and go to the next section yeah no no worries about accidentally buying something yeah very good and next up what happens if I want to remove something from the other plan that is let's say I've already done one instance and I've tested it and I no longer want some part of my upgrade plan is that possible can I get in and disable that I want to say yes there's a there's an option to inactivate certain items yes quick next on the slide and yes there is an option to make individual parts of the upgrade plan inactive so just update it publish it again it will increment the version in the app repo and then your next test will include that updated version uh similar another similar question um oh sorry yeah yeah if I if I start this and I determine that may I'm running out of time uh maybe I want to use this in a future release can I just abandon uh the the upgrade plan for the current patch that I'm working on and and yes in addition to disabling that it's um the the individual items you can inactivate the entire plan yeah I mean you can also delete the plan so if you delete the plan and then you go to recreate it it will just regenerate well just yep you can see you'll see it too it'll gone and it'll populate anywhere very good I like this question what if there's a newer version of the app that already got promoted up to prod so let's say you have a custom app that's on 3.1 um that's in your upgrade plan you're testing in test pre-prod and but then you have an emergency change and you have to push 3.2 up to prod real quick but your upgrade plan yeah so so 3.2 just goes straight to prod and then 3.1 is part of your upgrade plan what's going to happen uh when it goes to upgrade uh the upgrade plan yes just like a plug-in um or skip over it yeah I think the important thing here is that it will gracefully skip over it and proceed with the rest of the plan and we do have one more q a coming in I think we can we think we have some time to to do one more question here yeah sure um the question is if we start building an upgrade plan and we're on upgrading to Utah patch zero but then a new patch comes out and we decide that we want to upgrade to Utah patch one uh and we already have had some things in the upgrade plan can we change our upgrade plan to the new to the new patch and so I think Paige had the most experience with regenerating the that that building an upgrade plan would we I'm not sure would that translate if we upgraded the Builder instance to a new patch I wouldn't think so um yeah that's I I would not think so uh because it's it's basically capturing your skipped updates in the if you ever look at it the history or the upgrade history record when you look at that record it's got a bunch of skipped records down below that are matched up with that particular version um so I don't believe it would do that I agree there it is right there from what I've read so in that case you would close out the previous upgrade plan and do a new plan for the new uh patch right well yeah and so each time you generate you go in and you build a plan it's going to build it based on you know the version that you're trying to upgrade to so if you have an old one in there it's just going to create you a new one for you know Utah patch one all right I think we have many questions uh answered we we will have more questions down the line at any rate I want to wrap this up so first of all again thank you thank you thank you so much uh thank you Paige thank you Jared and thank you Miguel for diving into this topic preparing this uh presentation and taking us through the upgrade process and how it will change to once you start using upgrade plans I can see that this product can have a great effect effect on our customers and as I said the next Academy will be in two weeks uh we will be going through all of the amazing new things that are new in the Utah release for the now platform so be sure to join us again uh if you haven't uh signed up yet the session will go back to the regular schedule so it'll be uh 6 p.m in uh CEST then Central Europe in summertime uh it will be um 12 I think noon Eastern and 9 A.M Pacific so I look forward to see you all again uh as I said thank you everybody for joining uh this was a very interesting session and um I hope to see you again thank you everybody and yes you guys the knowledge we're all going to be there so oh yeah feel free to stop us talk to us ask us questions right as we're there for so if you guys go to knowledge we'll be there yeah yes the times that I won't be in sessions actually uh being a speaker you can find me uh at the platform section that is in the center of the show floor so you will likely find me somewhere either in the platform area or the Creator con area I would love to speak to you so uh find us at knowledge that would be awesome have a wonderful day bye everyone yeah I appreciate it