--- layout: handbook-page-toc title: Live Upgrade Assistance workflow category: Live Upgrade Assistance --- ## On this page {:.no_toc .hidden-md .hidden-lg} - TOC {:toc .hidden-md .hidden-lg} ### Overview The GitLab support team is here to help. As a part of our [Priority Support](index.html#priority-support) we offer Live Upgrade Assistance. That is, we'll host a live screen share session to help you through the process and ensure there aren't any surprises. In addition to the live assistance, it is important for GitLab Support to ensure the customer's plan for the upgrade is accurate and fully supported by GitLab in advance of the production upgrade. #### The Process 1. If the customer has a [Technical Account Manager (TAM)](/handbook/customer-success/tam/#what-is-a-technical-account-manager-tam), they reach out to the TAM with the required information. From there, the TAM creates an [support-team-meta issue](https://gitlab.com/gitlab-com/support/support-team-meta/issues/new) using the `Upgrade Assistance Request` issue template. 1. The current [manager on-call](/handbook/support/on-call/index.html#manager-on-call) will act as a DRI for the issue at this moment. That manager should also ping the Support Manager who will be on-call during the upgrade window so they can be involved in this process. 1. The DRIs will locate a Support Engineer to review the current given info (upgrade documentation, architecture diagram, etc.). This should occur within 24 hours of the request's creation. * Should the TAM notice this has not been done, the TAM should escalate the issue via the #support-managers slack channel. 1. The Support Engineer will review the given information. If a ticket does not yet exist for this upgrade request, the Support Engineer will create the ticket (using the point of contact email information) to reach out to the user. If a ticket does exist, the Support Engineer will reply to the ticket with their review findings. 1. The Support Engineer will add the ticket link to the upgrade assistance issue via a comment. 1. The Support Engineer will add the issue link to the ticket. 1. Once the Support Engineer has confirmed a viable path for the upgrade, they will comment on the issue notiftying the manager(s) acting as DRI(s) that the request can now be scheduled. 1. The DRI(s) will locate a Support Engineer to perform the live upgrade call. 1. This Support Engineer will schedule the call via Zoom and reply to the user with the details of how to connect. This should occur no later than 24 hours before the upgrade window. 1. The Live Upgrade Assistance call happens (see [What does live upgrade assistance look like](/support/scheduling-live-upgrade-assistance.html#what-does-live-upgrade-assistance-look-like)). 1. Post call, the Support Engineer will comment on the issue with a post-mortem of sorts. This should detail any issues that occurred or comments that might be relevant for the TAM or Support. 1. The Support Engineer will close out the upgrade request issue. #### What to do if issues occur during the course of upgrade assistance Should issues occur, the Support Engineer should encourage the user to initiate the reviewed rollback plan. If the Support Engineer feels confident they can resolve the issues they have encoutered, they may do so. However, the planned maintenance window of the user should be taken into consideration. Ensure there is enough time to rollback should it be required. #### Can a request for live upgrade assistance be declined? It is possible for this to occur, especially in situations where the upgrade is poorly planned or likely to cause production downtime. We should encourage the user to reschedule the window so we can allow for more time to test out changes and ensure a smooth upgrade. In cases where we decline to perform live upgrade assistance, we still allow for the use of emergency support. In cases where emergency support is utilized, often the best answer will be to rollback to the last working GitLab version.