K2 end of support 2026: EWS, .NET 8 and XSLT readiness

K2 end of support 2026 planning needs to cover more than the K2 version installed on the server. Exchange Online integration, the .NET runtime and browser behaviour are changing on separate schedules. This technical guide explains what to review and how to organise the work for an existing Nintex Automation K2 environment.

Based on the Nintex technical bulletin published on 29 June 2026, with linked technical guidance checked on 1 November 2026. The implementation checklist below is Web CheckIn’s guidance; the linked vendor documentation defines supported configurations.

Three changes to include in your maintenance plan

1. Exchange Online: assess EWS usage before moving to Graph

The Exchange Online change concerns integrations using Exchange Web Services (EWS), rather than every K2 email configuration. Microsoft began phased disablement in October 2026; the updated Nintex bulletin gives 1 April 2027 as the permanent cutoff. Tenant settings affect the interim position, so continued email delivery today does not establish readiness. This retirement does not apply to on-premises Exchange Server. See Microsoft’s EWS retirement guidance.

Nintex’s EWS-to-Microsoft Graph migration guide requires K2 5.8.1 or later. That is a feature prerequisite, not a recommendation to install an older release without checking its support lifecycle. Inventory workflow notifications, email rule actions, SmartActions and forms or workflows using Exchange Online SmartObjects. Graph permissions and API behaviour differ from EWS; some scenarios require application changes.

Select the migration route against that inventory. Reusing an existing feature instance and creating a parallel Graph feature have different consequences for references and testing. For acceptance, test the actual mailbox identity, a workflow notification, an email-based response where used, and representative mailbox operations. Treat legacy configuration removal as a separate, verified completion step.

2. .NET 8: match the runtime change to the K2 package

Microsoft lists 10 November 2026 as the end of support for .NET 8 in its .NET support policy. This is a servicing deadline, not a prediction that every application will stop on that day.

The current Nintex .NET 8 advisory lists these fix pack levels, or later, for the transition to .NET 10:

• K2 5.9.1 — Fix Pack 03.
• K2 5.9 — Fix Pack 17.
• K2 5.8 — Fix Pack 37.
• K2 5.7 — Fix Pack 30.

Use those entries as pointers to the release-specific instructions, not as a substitute for them. Nintex’s 5.9.1 fix pack notes, 5.9 fix pack notes and 5.8 fix pack notes also describe updated installers and warn that the fix pack must be reapplied after reconfiguration. Review the sequence before changing the environment.

Installing a new runtime alone does not demonstrate K2 compatibility. Record the installer build, applied fix pack and runtime requirements together, then confirm them against the Nintex compatibility matrix. Validate authentication and the services used by your applications after the supported package sequence is complete.

3. XSLT: include browser updates in K2 testing

Google’s XSLT removal schedule targets Chrome 158 on 17 November 2026. The change removes native browser XSLT processing; it does not remove XML itself. Browser updates therefore belong in the K2 change plan alongside server maintenance.

The Nintex XSLT advisory lists fixes for K2 5.9.1 FP 2, 5.9 FP 14, 5.8 FP 35 and 5.7 FP 30. It also identifies K2 Cloud Update 22 FP 16. These address XSLT specifically: they do not replace the separate .NET requirements above. Select a supported package that covers every applicable issue.

Test both design-time tools and business forms with the browsers your organisation actually deploys. Check page loading, rules, navigation and task completion. If a temporary browser policy is needed, confirm its availability and expiry with the browser documentation and give it an owner. Our preferred delivery outcome is a validated K2 fix with a normal browser update path, rather than an open-ended browser freeze.

K2 end of support 2026: a practical implementation checklist

• Establish the baseline. Record K2 version, build, fix pack, hosting model, email configuration and deployed browser versions for each environment.
• Separate the workstreams. Assign owners for Exchange configuration, K2 packages and endpoint browser management. Agree dependencies and the maintenance window.
• Prepare recovery. Confirm backups, configuration records and a recovery procedure appropriate to the selected migration and package instructions.
• Define acceptance cases. Include sign-in, a real approval route, integration calls, email notifications and the forms most important to daily work.
• Prove the result. Record installed versions, test outcomes and remaining exceptions. Monitor the first production runs and assign any follow-up actions.

For a K2 Cloud tenant, coordinate platform maintenance with Nintex and confirm the applicable maintenance notice. The original bulletin assigns cloud fixes to Nintex Operations. Application owners should still agree which customer workflows and integrations will be checked after that maintenance.

Review your environment with Web CheckIn

We can help identify affected applications, scope the required changes and plan testing around the processes your users depend on. Start with your current K2 build and a short description of the email and browser integrations in use. Explore our K2 upgrade assessment service or application maintenance service.

Request an environment review.