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 (RES) on 29 September 2026. The final release, 2026.09, has AWS support until 30 September 2027; earlier lines retain their own deadlines. Customers beginning adoption after the September 2026 cutoff do not receive AWS support.
Existing deployments remain open source and keep running in the customer’s account. At the applicable deadline, AWS technical support and critical-issue fixes end. Continuing RES maintenance then belongs to the organisation or its partner.
Host patching is already your responsibility
That handover does not mean AWS patches everything today. Its support policy already makes customers responsible for patching infrastructure and virtual-desktop hosts after deployment. Keep that existing work separate from future responsibility for the RES software itself.
The retirement concerns RES, not the underlying AWS services. The notice explicitly leaves services including EC2, EFS, FSx and Directory Service unaffected, with DCV continuing to receive development and support.
A new major line needs a new installation
In-place updates cover patch releases within one major line. Moving to another major version requires a new installation. Choosing the final line is therefore a deployment decision, not simply another patch.
For that project, build a rehearsal around representative users: can they sign in, reach their data and resume their research? Assign someone to approve the evidence and someone to call a rollback. Those are practical acceptance questions, not claims that BlackTree has tested a migration.
Choose an owner, not just a destination
AWS offers continued self-management, partner maintenance or migration to managed services or an alternative product. Its managed-service suggestions are not drop-in replacements for the RES portal.
- Staying in-house: give the maintenance team time, a release process and an escalation route, rather than leaving an unnamed obligation in the risk register.
- Using a partner: ask who approves emergency work, how a missed response is escalated and what evidence accompanies a delivered fix. Put the answers in the agreement.
- Moving elsewhere: have a researcher demonstrate the complete working day, not just a successful login. Record which gaps are accepted and who can approve the cutover.
Make the handover tangible: a named owner, a funded decision and an agreed acceptance record. A support date alone supplies none of those.
Sources
- AWS announcement and transition choices, published 29 September 2026.
- AWS end-of-support notice.
- AWS support policy and host-patching responsibility.
All three sources checked on 16 October 2026.
