Skip to main content

Overview

Approximately two to three years before an operating system (OS) reaches its end-of-life date, ISC Systems Support & Consulting initiates a Server OS Upgrade Project to transition all servers running that OS to a supported version. This proactive approach provides time to plan, coordinate, and complete upgrades before vendor support ends.

All servers must be upgraded or otherwise transitioned from the end-of-life OS before its vendor support ends. Doing so helps reduce security and operational risk, avoids additional support costs, and ensures continued access to the most comprehensive support available.

Process Overview & Compliance

Why does my server need to be upgraded?

Your server needs to be upgraded to remain compliant with current policies and security standards. When the operating system (OS) reaches its end of life (EOL), it no longer receives updates or security patches. This leaves the server increasingly vulnerable to security risks and potential exploits. Upgrading ensures your server stays secure, supported, and reliable. 

What happens if my server is not upgraded by the End of Life (EOL) deadline?

If your server is not upgraded by the required deadline it will no longer receive security patches, increasing the risk and making it vulnerable.   If you no longer are getting security patches and an active security vulnerability is discovered, we will need to take immediate action removing the system from the network. Please open a work order request with Systems Support & Consulting (SSC) proactively if you are concerned you will be unable to meet the deadline.

How long will the upgrade take?

You should plan for at least two weeks of preparation prior to the upgrade and a minimum of two hours of downtime during the cutover. The actual timing can vary significantly depending on the server and application complexity. 

As the cutover date approaches, more accurate estimates for expected downtime will be provided. 

Work the day of the upgrade typically takes 2-4 hours of work dependent on multiple factors. 

What does the typical upgrade process look like?

The typical upgrade process involves active client participation. It begins with scheduling a meeting among key stakeholders to review the upgrade steps and define an outage window based on your feedback and operational needs.

Once the plan is finalized and the outage window is approved, the upgrade proceeds according to the agreed timeline. A snapshot of the server is taken prior to the upgrade, and the server is then brought offline. The required changes are implemented with your involvement, followed by testing conducted by your team to ensure the server is functioning as expected before the upgrade is completed.

What happens if I do not respond to the request to schedule an upgrade?

A response is required. Because ISC is responsible for helping maintain the security of the University's computing environment, we will continue to contact you until the issue has been addressed. Delaying or not responding will not resolve the issue or prevent further action if the underlying risk remains unaddressed.

If a server is determined to pose a risk to the University, it may be disconnected from the network to protect the broader computing environment.

Our goal is to work with you to minimize service disruption and ensure a smooth, planned upgrade process. Please contact the Project Manager within the requested timeframe to schedule your upgrade(s).

Roles & Responsibilities

What is my role in the upgrade process?

As the server owner or application owner, you play a key role in ensuring a successful OS upgrade. Your responsibilities include:

  • Maintaining the relationship with your application vendors and ensuring your application is compatible with all components of the new operating system (OS). Strong vendor coordination and communication are critical to a successful upgrade.
  • Partnering with ISC throughout the upgrade process. ISC can provide assistance; however, the application owner remains responsible for all vendor interactions. ISC does not perform application upgrades on the owner's behalf or work directly with vendors without the application owner's involvement.
  • Developing a documented test plan that verifies your application's functionality before and after the OS upgrade. Pre-upgrade testing establishes a functional baseline, and post-upgrade testing confirms that the application continues to operate as expected.
  • Maintaining a current backup of the system and a recovery plan in the event the upgrade does not proceed as expected.
  • Collaborating with the Systems Support & Consulting (SSC) team to schedule, prepare for, and test the OS upgrade to help ensure a smooth and successful transition.

What if I have lost contact with my vendor?

If you have lost contact with your vendor or are unsure who to contact, please submit a work order request as soon as possible to request assistance. Systems Support & Consulting (SSC) team can help explore options, including engaging SysAdmins and/or Consultants, to support you in moving forward with your upgrade efforts.

What if our team needs help preparing for the upgrade?

If your team has limited resources, is unsure how to proceed, or has competing priorities, please submit a work order request to discuss your situation. System Support & Consulting (SSC) can assist with many aspects of upgrade preparation. If additional help is required, consultants may be engaged to provide further support.

Decommissioning & Data Retention Scenarios

Do I need to upgrade if I plan to decommission my server in the near future? 

If you plan to decommission your server, please submit a work order request to Systems Support & Consulting (SSC) to discuss your decommissioning plan. A clear and reliable plan to retire the server before the End of Life (EOL) date is required. 

If there is any uncertainty around the decommission timeline, the server will be included in the upgrade schedule to ensure compliance. Should your decommissioning plans change at any point, SSC must be notified immediately.

What should I do if I have a server that contains data that may need to be accessed, but the server does not need to remain online?

As soon as you identify this need, please open a work order request with System Support & Consulting (SSC) to discuss available options. 

In many cases, the data can be moved to a long-term storage solution that provides limited, controlled access and includes a defined retention or access deadline. A risk analysis will be performed based on the type and sensitivity of the data involved. The solution will vary depending on the level of risk identified.

 

Application Compatibility

What should I do if the application running on my server is not compatible with the new Operating System (OS), but must remain online because it is actively being used?

As soon as a compatibility issue is identified, please open a work order request with System Support and Consulting (SSC) to discuss possible solutions. 

 

If it is determined the application must remain online, you will need to request an exception. To obtain an exception, a documented risk mitigation plan is required. SSC can assist in developing this plan based on risk analysis. 

Examples of potential risk mitigation measures may include:

  • Network isolation or additional firewall rules
  • Restricted access controls and multi-factor authentication
  • Increased monitoring, logging, and alerting

The solution will vary depending on the level of risk identified and the nature of the data involved. Please note that exceptions are not permanent solutions; an end date and long-term remediation plan will be required.

Additional Questions

What if I have additional questions or concerns?

If you or your team have questions that are not addressed here, please submit a work order request so we can discuss your specific situation and provide guidance.