BlackTree Security · Infrastructure · Automation · AI

Who Owns the Next Fix for Your Research Desktops?

Support can end without the platform disappearing. The harder question is who owns the next fix.

AWS ended development of Research and Engineering Studio on AWS on 29 September 2026 and made 2026.09 the final release. New adoption after that date does not receive AWS support. Existing customers can use the final line with AWS support until 30 September 2027; earlier releases keep their own earlier dates.

The software stays, but vendor ownership changes

RES runs in the customer’s AWS account and remains available as open-source software, so a deployment does not switch off at its support date. AWS technical support and critical-issue fixes then end. Maintenance, security patching and further development pass to the organisation or its partner.

Treat that transfer as a service-ownership decision. Record the accountable team, funding route, escalation model and evidence needed before the vendor deadline.

Moving to the final line is a deployment project

The support policy permits in-place updates only between patch releases in one major line. Moving between major releases requires a new installation, so choosing 2026.09 is not a routine upgrade.

Record the current line, integrations, identity design, desktop images, storage dependencies, network controls and operational customisations. Build the target separately, prove the required workflows with representative users, then rehearse cutover and rollback.

Three paths need three different owners

AWS presents three broad choices: maintain RES internally, use a partner, or migrate. Its managed-service suggestions are not direct replacements for the RES portal, so each path needs its own operating design.

  • Internal maintenance: name the team that will triage defects, test dependencies and publish trusted builds.
  • Partner maintenance: put response, escalation, release delivery, source access and exit assistance into the contract.
  • Platform migration: test identity, storage, virtual desktops, high-performance computing access, scheduling, automation and cost controls against real workloads.

A mixed path can preserve time while a replacement is tested. The decision record should still name one accountable owner for every period.

Use the remaining runway to remove ambiguity

  1. Confirm the installed line. Record its dependencies and accountable service owner.
  2. Choose the operating model. Assign the long-term owner and decision authority.
  3. Prove the baseline. Test production-like identity, storage and desktop workloads.
  4. Fund the handover. Budget for engineering, dependency testing, incident response and release signing.
  5. Set the decision date. Move before the installed line’s applicable support date. For final 2026.09, that is 30 September 2027; an earlier line may end sooner.

An ownership decision needs a name, a budget and a tested handover.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *