Upgrade FAQs & Best Practice

overview servicely is an ever evolving platform and as a result there are often times we will reach out to upgrade your environment, or we need to upgrade your environment to deploy a minor new feature or hot fix this details what we consider best practice for upgrades, as well as provides answers to common questions that we have received and been asked over the year we typically suggest staying on the most recent major version, as this will allow us to more easily applying fixes and include new features that we may not be able to include in earlier versions best practice process for upgrades to help in planning and completing an upgrade, this section details the various stages of the upgrade and the steps that we recommend you take preparation in preparation to any upgrade, there are things that you can organise at any time to make any future upgrades a smoother and more relaxed process this is something that can be prepared ahead of time and you do not necsscarily need to wait until an upgrade is read to complete these preparatory activities create a library of test cases of how you utilise the platform this should be compiled with how people use the platform on a daily basis we suggest you create your own library, as the way you have configured and use the system, will often be different to our other customers this should typically include things such as what personas use the system (and as a result, what roles / groups for users should be prepared for any testing) example as follows end users who have the self service role it agents who have the itsm agent role it managers who have the itsm manager role and hr agent role hr agents who have the hr agent role what processes do you make use of and how do these personas interact with said processes and what are the steps they do to take this example as follows log in as a “test self service” user go to the catalog and select the “my computer is broken” catalog item submit a get help item and confirm you can see the item after being submitted ensure you can see the open incident in your portal and make requests with an alternative user, ensure all fields are populated with what is required what features are commonly used and how can these be tested example as follows the scheduled task feature is used every week to generate weekly patching tasks to test this, wait until monday and ensure weekly tasks have been generated for all companies as required or alternatively create a new scheduled task to be generated once for an hour from now as you introduce / start using newer features in servicely, continue to add to your library of test cases identify a range of users within your organisation who can assist in testing for any upgrade we typically suggest not only using your system administrator to do the testing, but preferably people who use these processes from a day to day basis this is due to the fact that you want to make sure the people who do the activities in a day to day basis, do it as they would identify any integrations and if it is viable to test it prior to upgrades with a non production or otherwise this is not always viable and we typically strive to avoid any changes to this (without notifying you), but if you have any integrations and it is viable to do testing with a non productive, it is often worth identifying what environments can be used for testing before the upgrade when we have highlighted that there is a new version available, there are a few steps that we will typically suggest you can follow if this is a major version , review the release notes and take special note note the upgrade consideration section and if there is anything you need to do if you have a non production environment, identify any open change sets and if viable either deploy them before we upgrade your non production or plan to deploy these after the upgrade (noting it will likely make sense to re test) servicely recommends that you only deploy change sets to instances of the same version, due to potential changes in the table structures or otherwise, so finalising any deployments before the upgrade is suggested if there are any changes required post upgrade and if you have a non production , we suggest keeping all changes that are required in a change set you can deploy after the upgrade not all changes can be captured in this manner inform your employees although we try to make sure all upgrades goes without any issue, informing your agents especially can be helpful just in case there is something that you did not pick up during testing if you have a non production, follow and complete any test cases that you have accumulated during the preparation phase if there is anything that does not seem quite right, feel free to reach out to support, we are always happy to help and answer your questions we do not suggest, taking the time to review new features that you don’t currently use from a set up and testing point of view, until you have completed the upgrade to your production environment this is because this can delay the upgrade process and we believe doing this after the upgrade ensures a more sustainable and controlled way of implementing new features within servicely when you are ready to go, let us know via support so we can work together and agree on a date and time and so you can inform your users when this occurs please note that for minor patches or hot fixes, completing all test cases does not always make sense we will highlight if there is anything signifcant that has changed, but please note that we make an effort to test our releases in a base product before releasing them in other words, if you have any configurations that are non standard, we naturally will be unable to test those, prior to upgrade any of your environments during the upgrade when the agreed and schedule time arrives, there is typically not much you need to do servicely upgrades typically do not need any down time and outages and typically do not require any action from you there are some rare situations where you may need to apply change sets (if identified before hand), but if there are any changes we are aware of, we can often help you in this process upgrades are scarcely lengthy endeavours and users can often continue working during this process depending on the size and changes however, it may make sense to pause it, depending on what it is after upgrade after the upgrade has completed, we will update the support ticket and inform you depending on when this upgrade is happening and if you are not directly involved, this message will not always be sent immediately upon completion, but often after do complete our final checks once done, it should often not change how you use the system, but if you notice any issues / differences we suggest testing in your non production if it also happens there check with your users if it is something that has existed for a while, or new due to the upgrade outline steps to reproduce, as well as the browser, user and test records, as well as what you would expect the behaviour to be understand the importance is of it being resolved, as it can be easy to assume everything is a priority 1, but may be a small nuisance, whilst it is being investigated during the upgrade process, it is often at this time that pre existing issues or bugs come up this is important to keep in mind, as not everything will be directly related to the upgrade, but something that had simply not been noticed prior ongoing once the upgrade has been done, it is important to note there are items we suggest you do from an on going basis to make sure you are prepared for any future upgrades continue to add and modify your library of test cases and scenarios, as you continue to use new functionality in servicely keep note of any official communication or release notes and determine if you are in the current version or behind we will typically reach out to you if you are very behind, but suggest staying update in case any of your requested features or bug fixes have been resolved take note of any feature or bug that you have noted to and who raised it, as within our release notes, that will allow you to inform the appropriate user(s) of its introduction and / or resolution frequently asked questions (faq) question how many versions (major and minor) do you release per year? we do not have a set number of releases that we make per year, but at least strive for at least 1 major release a year the number of releases can depend on a number of factors, so we do not a set number we feel as though setting an arbitrary number of releases can cause undesired consequences (with rushing functionality) or not focusing on the features our customers want question do you have any test cases that we can follow to complete our testing? when we test any new features, we follow a range of tests that make sense in the base product and what is available out the box realistically however, every customer environment is different (even if it in minor ways) and how your users use the system may be different to how we believe your users use the system we feel as though if you make the test cases based on our test cases, you will not be testing it as you use it, but how we tested it and excluding any of your configurations question if i upgrade my environment, will there be an outage? if so, for how long? our upgrades do not typically require an outage and can occur whilst people use the system if there is an outage, it is typically will only last 5 15 minutes we will inform you if there is an outage required, but it should be noted that this is rare question what happens if i have an integration that pulls data from servicely (such as power bi) during the upgrade and assuming there is no outage, this can keep running as it did previously if there is an outage, during that time you will not be able to pull data, as the environment will be unavailable, so will need to pull the data that may have occurred during that time frame separately (or delay the call) question do we need to take backups before an upgrade? no backups need to be made we take backups of your environments as been defined within your contracts that said, there is very rarely a situation that would require returning to a backup, as in doing so would mean the loss of any records between when the backup was made and the time the backup was applied with no ability to recover them question if the upgrade fails, is it possible to revert to an earlier version? it is not possible to revert to an earlier version of servicely if there is something occurs, we will typically fix forward if required, we can go to a backup, but this is very rarely (if at all) required upgrades are permanent question how will i know if a feature that we commonly use will be affected? we suggest reading the release notes for major version to understand if anything was changed for hot fixes or minor patches, we do not typically try to introduce changes to existing functionality that said, this is why we suggest keeping a library of test cases that you can go through, to ensure that you can properly review and test any upgrade that occurs question how can i request an upgrade? upgrades can be requested with our support team through the normal channels as any other support ticket (portal and email) question do we need to upgrade our environment / will you force us to go to new versions? we strongly recommend keeping up to date with servicely versions for a number of reasons this is largely because if you encounter an issue or require a new feature, we will often focus on the newest major version, due to how the platform may have moved on most importantly though, this allows us to ensure that your instance has all the new security enhancements to allow us to better secure your data, as well as your customers can i deploy change sets to an environment that is a different version? from a servicely perspective, we do not technically stop you from doing so, however, we would strongly suggest against doing so this is due to the fact that between different versions, we may make changes to the table structure, making the change you are deploying irrelevant to the new instance in other words, in a non production there might be a field that exists on x table called “external identifier”, but in production this field would no existing until the upgrade therefore, if you deploy this change, this value won’t have a home and therefore won’t be set once you upgrade production as a result, we would suggest closing or deploying all your change sets on non production, prior to upgrading the non production if there are any you cannot close, we then suggest to only deploy them once you have upgraded production to the same version as the non production (after doing another test) any further questions? if you have any questions or any concerns regarding upgrades, please don’t hesitate to reach out to our customer support team system administrators can do this by logging onto our support portal (https //support servicely ai)