Aras Innovator R40 vs R38: .NET 10 Migration Guide

Every Aras admin currently running a production instance on Release 38 is about to get the same email: Microsoft ends .NET 8 Long Term Support on November 10, 2026, and Aras has moved its platform forward accordingly. The Aras Innovator R40 vs R38 migration question is not really a question about a framework version — it is a question about which of two much smaller, much more concrete changes will break your environment first: a date-format assumption buried in a decade-old server method, or a Microsoft SQL Server Reporting Services (SSRS) report your quality team runs every Monday morning. This piece separates the marketing noise around “.NET 10 support” from the two breaking changes that will actually cost you time, and lays out a decision framework for whether R40 is worth the jump today or whether R38 with a backported patch is the more defensible choice for your shop in Q4 2026.

What this covers: the real release cadence from R37 through R40, what “compliant with .NET 10” actually obligates you to do, the SQL date-format and SSRS breaking changes verified against Aras’s own release notes, a before/after comparison table, Aras’s formal upgrade-eligibility policy, and a practical checklist for planning the move.

Context and Background

Aras Innovator has spent the better part of two decades positioned as the open-architecture alternative to the traditional enterprise PLM stack. Where Siemens Teamcenter, PTC Windchill, and Dassault’s 3DEXPERIENCE/ENOVIA ship as largely closed, license-gated platforms, Aras built its business on a subscription model layered over a code-optional, model-driven architecture — customers pay for support and upgrades, not per-seat licenses, and the system’s data model, business logic, and UI are meant to be extended through configuration rather than forked source code. That architectural bet is documented in depth in our breakdown of the Aras Innovator open-source PLM architecture, and it matters here because it shapes how disruptive a runtime migration like this one actually is: a well-configured Aras instance with minimal custom server methods absorbs a .NET version bump far more gracefully than one carrying fifteen years of bespoke C# event handlers.

The incumbents are not standing still on the underlying-platform question either. Enterprise PLM vendors have spent the past three years pushing their installed bases toward SaaS delivery models specifically to get out of the business of chasing customer-managed runtime dependencies — a dynamic we cover in our comparison of Teamcenter X, 3DEXPERIENCE, and Windchill+ as SaaS PLM offerings. Aras has taken a different path: it remains a customer-deployed (or partner-hosted) product, which means every .NET LTS transition Microsoft executes becomes a scheduled, unavoidable event on the Aras roadmap, and by extension, on yours. Microsoft’s own .NET support policy is the root cause of everything in this article; the policy documentation itself is public at dotnet.microsoft.com’s support policy page, and it is worth reading once so the Aras-specific dates below have context. This is the second such transition Aras has navigated publicly in its release notes, and the pattern it followed — a phased rollout starting with the newest release and backporting to older ones — is itself a data point worth understanding before you decide when to move.

The broader PLM industry’s shift toward quarterly or near-quarterly release trains is worth naming explicitly, because it changes how upgrade planning should work compared to the annual or biennial major-version cycles that defined PLM through the 2010s. A vendor shipping every thirteen weeks cannot treat each release as a disruptive event customers brace for; instead, releases become a rolling stream that customers sample from at whatever interval matches their own change-management appetite. That is the operating assumption behind Aras’s backport commitment discussed later in this piece — a vendor on an annual cycle would be far less likely to promise patches reaching six releases into the past, because there would be far fewer releases to reach across in the first place. Understanding this cadence is a prerequisite for reading the rest of this migration correctly: the question is never “should we ever upgrade to R40,” it is “which of the last several quarterly releases is the right stopping point for our current change window.”

Migration Overview: What Actually Changed Between R38 and R40

Direct answer: Release 39 (version 14.39.0), shipped May 14, 2026, is the first Aras Innovator release compliant with .NET 10. Release 40, shipped August 6, 2026, is the current shipping version and carries that compliance forward. Release 38, shipped February 2, 2026, predates the .NET 10 work entirely and still targets the outgoing .NET 8 runtime that Microsoft retires on November 10, 2026.

The framing that matters here is sequencing, not raw version numbers. Aras did not silently swap .NET versions inside a routine quarterly release; it drew a clear line in its own documentation, stating in its migration guidance that R39 is “the first .NET-10-compliant release of the platform.” That phrasing is deliberate — it tells you the .NET 10 work is a discrete, identifiable milestone that customers can plan around rather than a background dependency bump scattered across several releases. If your instance is on R38, you are, by Aras’s own definition, one full release cycle behind the compliance line. If you are already on R39 or R40, you have crossed it.

Figure 1: The R37–R40 release cadence, with R39 marked as the first .NET-10-compliant build and R40 as the current shipping release, framed against the .NET 8 end-of-support and .NET 10 LTS support windows.

The diagram above lays out the four most recent releases against Microsoft’s runtime calendar. Each Aras release lands roughly thirteen weeks after the last one — R37 on November 13, 2025, R38 on February 2, 2026, R39 on May 14, 2026, and R40 on August 6, 2026 — a cadence steady enough that a shop planning its 2027 IT calendar can reasonably assume a fifth release in the November 2026 window. What breaks that rhythm from a planning perspective is not the schedule itself but the runtime underneath it: .NET 8 stops receiving security patches from Microsoft on November 10, 2026, four days shy of the typical next-release date, while .NET 10 is committed as Aras’s new LTS target, with Microsoft supporting it “through November 2028.” That two-year runway is the actual reason to care about this migration — it is the difference between running on a framework Microsoft is still patching and one it has stopped patching entirely.

What “compliant with .NET 10” covers inside Innovator

Aras has been specific about the blast radius of this migration rather than leaving it vague. Its documentation states the .NET 10 work covers “Innovator Core (Server, Client, OAuth, Vault, Conversion, and Agent endpoints, plus shared plug-ins).” That is a wide surface — it is effectively every process-hosting component in a standard Innovator deployment, not just the web application tier most admins think of first. The OAuth service handles federated authentication; the Vault Server handles file storage and streaming; the Conversion service handles visualization and document rendering; the Agent endpoints handle background job processing. A migration that touches all of these means your validation plan after upgrading needs to exercise each of those subsystems individually, not just confirm that the main Innovator client loads.

Practically, this scope statement is also a reassurance. It tells you Aras treated the .NET 10 move as a platform-wide re-target rather than a partial one, which reduces the risk of a mixed-runtime deployment where, say, the Vault Server is still running .NET 8 binaries against a .NET 10 Innovator Server. Customers running a distributed topology — separate boxes for the application server, vault server, and conversion server — should confirm during testing that every tier was actually redeployed on the new runtime, since a partial rollout across physical or virtual servers is an operational error the platform-wide compliance claim does not itself prevent.

A validation plan that takes this scope statement seriously looks different from a typical “smoke test the login page” post-upgrade check. It means exercising OAuth token issuance end to end, not just confirming the login screen renders; it means uploading and streaming back a file large enough to exert the Vault Server’s chunking logic, not just confirming a thumbnail loads; it means triggering at least one visualization or document conversion job and one background Agent-processed task, such as a scheduled workflow escalation, and confirming both complete under the new runtime. Each of those six named components — Server, Client, OAuth, Vault, Conversion, and Agent — has its own process, its own configuration file, and in a distributed deployment, potentially its own physical host, which means each is a separate opportunity for a stale binary or an unrestarted service to leave part of the estate on the old runtime while the rest has moved on.

Why the release cadence itself is a planning signal

There is a second, quieter benefit to Aras’s consistent thirteen-week cadence that is easy to miss when you are focused on the .NET 10 change specifically: predictability. A vendor with an erratic release schedule forces its customers into reactive upgrade planning — you find out a breaking change is coming when the release notes land, not before. A vendor holding to roughly ninety days between releases, as the R37 through R40 sequence demonstrates, lets an IT team build a standing quarterly review into its own change-management calendar, checking each new release’s notes against a fixed checklist — breaking changes, security-relevant fixes, deprecations — as a routine practice rather than a fire drill. Shops that treat this migration as a one-off crisis are missing the opportunity to build the underlying process this cadence enables: a recurring, low-drama release-review cycle that would have surfaced the SSRS deprecation notice in R39, four months before the R40 notes escalated it into an explicit warning.

The phased rollout that changes your urgency calculus

The detail most likely to get lost in a quick skim of the release notes is this: Aras is not forcing every customer onto R39 or R40 to get .NET 10 support. Its own documentation states that Aras will ship “patches for supported versions beginning with Innovator R32, prioritized by end-of-life dates and customer adoption rates.” In plain terms, if you are running anything from R32 through R38, Aras intends to backport .NET 10 compatibility to your existing release rather than requiring a full version upgrade first.

This single sentence should reset how most R38 shops think about their November 2026 deadline. The .NET version itself is not the forcing function for an R38-to-R40 upgrade project — a patched R38 running on .NET 10 is a legitimate, Aras-supported way to clear the .NET 8 end-of-support deadline without touching anything else in your environment. The forcing functions that actually justify a full version jump are the two breaking changes covered next, both of which apply regardless of which patched version you land on, because they concern behavior your own customizations depend on, not the runtime version tag.

Breaking Changes Walk-through: R38 to R40

Two changes in this window are not optional runtime plumbing — they are functional breaking changes that will surface as production incidents if you do not address them proactively, independent of whether you take the .NET 10 patch on R38 or move all the way to R40.

The first is a SQL parameter format change affecting custom server-side code. Aras’s R39 release notes state plainly that “SQL parameters need to be in neutral date format, such as ‘2026-03-13T14:30:00’.” If your Aras instance has any custom Item event handlers, method-based business logic, or reporting queries that construct SQL date literals using a locale-specific or otherwise non-ISO format, those code paths are candidates for silent failure or, worse, subtly wrong date filtering after the migration. This is exactly the kind of change that unit tests rarely catch, because it depends on server locale and the specific string-formatting calls buried in old customizations — the kind of code a code-optional platform is supposed to minimize, but which nearly every long-lived Aras deployment accumulates anyway.

The second is the discontinuation of SSRS integration. Both the R39 and R40 release notes confirm this, with the R40 notes phrasing it as a direct customer instruction: “Customers should plan to migrate SSRS reports before upgrading to Microsoft SQL Server 2025.” Microsoft’s own consolidation of its reporting stack onto Power BI is the root cause — Aras is not choosing to drop SSRS out of preference, it is following Microsoft’s platform direction, the same forcing dynamic that produced the .NET 8-to-10 migration in the first place. For any Aras shop that built quality, engineering-change, or BOM reports on SSRS — a common pattern in manufacturing IT departments that already run SQL Server and had SSRS “for free” — this is the change most likely to require actual project budget, since it means rebuilding report definitions in Power BI rather than a configuration toggle.

Finding every SQL date-literal risk in a mature Aras instance is a search-and-classify exercise, not a guess. Pull every custom server method and event handler from your configuration export and search for string-concatenation patterns feeding into SQL WHERE clauses or parameter objects — locale-formatted date constructors, ToString calls with a short-date or long-date format specifier, or hardcoded string templates like MM/dd/yyyy are the highest-risk patterns, because they format a date in a way that depends on the server’s regional settings rather than the neutral, ISO-8601-style format Aras now specifies. A method that already builds dates with ToString("s") or an explicit yyyy-MM-ddTHH:mm:ss format string is almost certainly safe; a method that calls a bare ToString() with no format argument, letting .NET fall back to the server’s current culture, is the pattern most likely to produce a subtly wrong date filter after the runtime change rather than an outright crash — which is precisely what makes it dangerous, since a subtly wrong filter can pass casual testing and still return incorrect BOM or effectivity data in production.

Release-by-release comparison

Dimension	R38 (Feb 2, 2026)	R39 (May 14, 2026)	R40 (Aug 6, 2026)
.NET 10 compliance	Not compliant — predates the migration	First .NET-10-compliant release	Current shipping release, .NET 10 compliant
SQL date-parameter behavior	Pre-change behavior	Requires neutral ISO date format in custom SQL	Same requirement carries forward
SSRS integration	Present, not yet flagged for deprecation	Deprecation confirmed in release notes	Deprecation confirmed; explicit warning ahead of SQL Server 2025
Notable UI/UX additions	Not detailed in this fact set	Tree Grid multi-select, resizable dialogs, persistent grid sorting, editable favorites, relationship-tab colors	Thousands-separator toggle, per-view accordion state, labeled Advanced Search, filterable Where Used
Support eligibility window	Inside 30-month window as of late 2026	Inside 30-month window	Inside 30-month window, most current

Figure 2: The .NET 10 migration’s scope inside Innovator Core — Server, Client, OAuth, Vault, Conversion, and Agent endpoints plus shared plug-ins — alongside the SSRS-to-Power BI reporting transition Microsoft’s SQL Server roadmap is driving.

Notice what the table does not show: a like-for-like feature comparison between R38 and R40 directly, because Aras’s own release notes document R39’s and R40’s additions separately, and no equivalent detailed feature list for R38 appears in the verified source material for this piece. Treat R38’s feature baseline as “whatever preceded the two documented feature rounds below” rather than a fabricated list — this is a case where the honest answer is that the fact pack has a gap, and a diligent admin should pull R38’s own release notes directly from Aras before assuming feature parity in either direction.

What R39 added on top of R38

Independent of the .NET 10 work, R39 shipped a meaningful UI and workflow release: multi-select support inside Tree Grid View rows, resizable and maximizable dialogs, multilingual favorite labels, a configurable default descending sort order, improved history readability, persistent column sorting inside saved grid layouts, editable favorites, configurable accordion labels for Item Views, customizable relationship-tab colors, required-property indicators inside relationship grids, save-and-restore of relationship grid layouts, and improved performance for xClassification and xProperties operations. None of these are breaking changes — they are additive UX improvements — but they are relevant to your upgrade decision because several of them (persistent grid sorting, relationship-tab colors) are the kind of quality-of-life feature that end users notice immediately and start requesting once a neighboring department has them.

The xClassification and xProperties performance improvement is worth a moment’s explanation for readers less immersed in Aras’s internals: xClassification governs how Items are organized into the hierarchical classification trees Aras uses for part families and standardized component catalogs, while xProperties handles the dynamic property sets attached to classified Items — the mechanism that lets a “Resistor” classification node expose resistance-value and tolerance properties that a “Capacitor” node does not. Both operations get progressively more expensive as a classification tree and its associated property definitions grow, which makes this a performance fix that matters disproportionately to larger part libraries; a shop with a shallow, lightly classified catalog is unlikely to notice the change, while a shop with a deep, heavily classified electronics or fastener library is the intended beneficiary. Aras’s release notes do not quantify the improvement with a benchmark number, so treat “improved performance” as directionally confirmed rather than a measured percentage [gap in the verified fact pack — no benchmark figure is published].

What R40 added on top of R39

R40’s additions are narrower but still notable: a thousands-separator toggle for numeric formatting that respects locale conventions (for example, rendering 1,000,000 for en-US locales), independently configurable accordion states — expanded, collapsed, or maximized — per Item View, an Advanced Search interface that now surfaces an ItemType’s configured display label instead of its raw internal name, type-ahead filtering that can be configured through OnFilterSelection events, and the ability to filter “Where Used” results by a specific reference path before the query executes. The Where Used filtering change in particular is a meaningful engineering-change-management improvement for any team doing impact analysis on shared parts, since unfiltered Where Used queries against deeply reused components can return results too broad to act on quickly — a workflow this site has covered in detail in our piece on ECR/ECO engineering change management architecture.

Trade-offs, Gotchas, and What Goes Wrong

The single biggest planning mistake available here is treating “we need .NET 10 before November 10, 2026” as equivalent to “we need to upgrade to R40 before November 10, 2026.” Those are different projects with different risk profiles. Aras’s own backport commitment — patches for supported versions starting at R32 — means an R38 shop under time pressure has a lower-risk path: apply the .NET 10 patch to the version already in production, validate it, and defer the R39/R40 feature and behavior changes to a separate, better-planned project. Conflating the two turns a runtime patch into a full release upgrade under deadline pressure, which is exactly the condition under which upgrade projects go over budget and over schedule.

A second gotcha sits inside the SQL date-format change. Because it only affects custom server-side code — not out-of-the-box Aras functionality — it is invisible to a standard smoke test. A QA pass that only exercises native Aras workflows will pass cleanly on a broken instance; the failure only shows up when a specific customization runs, often triggered by a date-sensitive business event like an effectivity date calculation or a scheduled report. Treat this as a mandatory static-code-review item — search your custom method library for date-literal construction — rather than something regression testing alone will catch.

The SSRS deprecation carries its own trap: report rebuilds in Power BI are not drop-in replacements. Report layout, parameterization, and distribution (subscriptions, scheduled email delivery) work differently between SSRS and Power BI, and organizations that treat this as a mechanical export/import will discover gaps in report behavior after cutover, typically in scheduled-delivery and role-based-security configurations that SSRS handled through Report Server permissions and Power BI handles through workspace and app permissions instead.

Finally, be honest about what is not confirmed in Aras’s public materials as of this writing: there is no published exact date for when the .NET 10 patch actually lands for pre-R39 versions, only the commitment that it will be “prioritized by end-of-life dates and customer adoption rates” [I — inferred prioritization logic, not a published schedule]. If your organization’s compliance posture requires a committed patch date rather than a general commitment, that is a conversation to have directly with your Aras account team now, not a date to assume from the pattern of past releases.

A less obvious gotcha involves rollback planning, which upgrade projects routinely underestimate for a code-optional platform like Aras. Because Innovator’s behavior is driven substantially by database-resident configuration — ItemTypes, forms, workflows, relationships — rather than solely by deployed binaries, a failed upgrade rollback is not simply a matter of redeploying the old application files. It requires restoring the database to its pre-upgrade state as well, since schema and configuration migrations applied during the upgrade are not generally designed to be reversed in place. Any upgrade runbook for this migration should include a full database backup taken immediately before the upgrade begins, with an explicit, tested restoration procedure, rather than assuming the application-tier rollback alone is sufficient.

Testing overhead is the last trade-off worth naming directly. The six-component scope of the .NET 10 migration — Server, Client, OAuth, Vault, Conversion, Agent, plus shared plug-ins — means a thorough validation pass takes meaningfully longer than validating a typical feature release, because each component has distinct failure modes and none of them can be assumed safe by extension from the others passing. Organizations that compress this validation window under end-of-support deadline pressure are the ones most likely to discover the SQL date-format issue in production rather than in staging, since that specific defect requires exercising a customization path that a generic smoke test will not touch.

Figure 3: A decision flow for R32–R38 customers weighing a .NET 10 patch against a full upgrade to R40, keyed to the two real breaking changes — SSRS usage and custom SQL date handling — rather than the .NET version number itself.

Practical Recommendations

Start by separating the compliance deadline from the upgrade decision. The November 10, 2026 date is about .NET 8 support ending, not about R38 becoming unsupported — confirm with your Aras account team whether your specific version is in the initial .NET 10 patch wave or a later one, since “beginning with R32” does not specify sequencing among R32 through R38. Second, run a code audit against your custom server methods for non-neutral date-format SQL construction before you touch any runtime upgrade; this is cheap to check and expensive to debug in production. Third, inventory every SSRS report in active use and classify each as safe-to-retire, needs-Power-BI-migration, or business-critical-needs-project-budget — this inventory alone often reveals that the real migration cost sits in reporting, not in the platform upgrade itself. Fourth, confirm your organization’s Aras upgrade-services subscription status and your current version’s age against Aras’s 30-month eligibility window before assuming Aras Support can assist with an upgrade project.

Sequence the work as two loosely coupled projects rather than one monolithic upgrade, because they have different urgency and different owners. The .NET 10 runtime patch is an infrastructure task your Aras administrator and account team can drive against the November 10, 2026 deadline largely on their own timeline. The SSRS-to-Power BI migration is a business-facing reporting project that needs input from whichever departments actually consume those reports, and it has no hard deadline tied to it in the verified release notes beyond “before upgrading to Microsoft SQL Server 2025” — a date each organization sets independently based on its own SQL Server upgrade cadence. Running these as one combined project risks the infrastructure work getting held hostage by reporting-stakeholder scheduling, when in fact the compliance deadline does not require the reporting migration to be finished first.

Communicate the distinction clearly to whichever stakeholders are asking about this migration, because “Aras is moving to .NET 10” is the version of this story that reaches non-technical leadership, and it invites exactly the wrong question — “are we compliant yet” — when the better question is “have we handled the SQL date-format risk and the SSRS transition, on whatever version we’re running.” Framing the conversation around the two concrete breaking changes, rather than the runtime version number, keeps the project scoped to work that actually needs doing.

Checklist before you schedule anything:

• Confirm which patch wave (R32–R38 backport vs. native R39/R40) applies to your current version
• Audit custom server-side SQL for non-ISO date-literal construction
• Inventory all SSRS reports and classify migration effort for each
• Verify active Subscription for Upgrade Services is current
• Confirm production deployment status and version age fall within the 30-month support-eligibility window
• Decide explicitly: patch-in-place on current version, or full upgrade to R40 — do not default into one path by inaction

Figure 4: The three eligibility gates — active Upgrade Services subscription, a production deployment, and a version released within the last 30 months — that Aras’s release notes repeat verbatim across R38, R39, and R40 as prerequisites for supported upgrade assistance.

Frequently Asked Questions

Does .NET 8 end-of-support mean my Aras Innovator R38 instance stops working on November 10, 2026?

No. End of support means Microsoft stops shipping security patches for .NET 8, not that existing software stops running. Your R38 instance keeps functioning after that date; the risk is unpatched runtime vulnerabilities accumulating over time. Aras has committed to backporting .NET 10 patches to supported versions starting at R32, so R38 shops have a documented path to a patched runtime without a full version upgrade, though Aras has not published an exact patch date for each pre-R39 version.

Is Release 39 or Release 40 the one I actually need for .NET 10?

R39 (version 14.39.0) is the first release Aras describes as .NET-10-compliant, so it is the minimum version if you upgrade natively rather than taking a backported patch. R40 is the current shipping release and carries that compliance forward along with additional UI features shipped after R39. Neither release number is itself the compliance requirement — .NET 10 compliance is the requirement, and R39 is simply where Aras first delivered it.

What exactly breaks in custom SQL code during this migration?

Aras’s release notes specify that SQL parameters must use a neutral date format, giving the example ‘2026-03-13T14:30:00’. Any custom server method, event handler, or report query that builds SQL date literals in a different format — locale-specific formatting, for instance — is a candidate for failure or silently incorrect date filtering after migrating. This is a code-review item, not something Aras’s platform upgrade fixes automatically.

Do I have to migrate off SSRS reports right now?

Not immediately, but Aras’s R40 release notes are explicit that customers should migrate SSRS reports before upgrading to Microsoft SQL Server 2025, since Microsoft is consolidating its reporting stack onto Power BI. If your organization has no near-term SQL Server 2025 upgrade planned, you have runway, but the deprecation direction is confirmed in both R39 and R40 notes, so treat it as a scheduled project rather than an indefinite deferral.

What does Aras require before its support team will help me upgrade?

Aras’s release notes repeat the same three conditions across R38, R39, and R40: an active Subscription for Upgrade Services, a production deployment of Aras Innovator, and a version released within the last 30 months. All three must be true simultaneously — a lapsed upgrade-services subscription or a version older than the 30-month window disqualifies you from supported upgrade assistance regardless of the other two conditions.

Should a shop on R38 today jump straight to R40, or stay on R38 with a patch?

Based on Aras’s own phased-rollout commitment, the .NET version alone does not force a full upgrade — a patched R38 clears the .NET 8 deadline. The decision should instead turn on whether you use SSRS reporting (favoring an earlier, planned migration) and whether your custom SQL code needs remediation regardless of platform version. Shops wanting R39/R40’s UI improvements have an independent, feature-driven reason to upgrade; shops that don’t can reasonably stay patched on R38.

Further Reading

• Aras vs. Teamcenter vs. Windchill: a full PLM platform comparison
• Aras Innovator’s open-source PLM architecture explained
• SaaS PLM compared: Teamcenter X vs. 3DEXPERIENCE vs. Windchill+
• Digital thread PLM architecture and implementation patterns
• Engineering change management: ECR/ECO architecture in PLM
• Aras’s own .NET 10 migration documentation: docs.aras.com/aras-innovator-migration-to-net-10
• Microsoft’s .NET and .NET Core official support policy: dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

By Riju — about