.NET 10 Platform Migration

Tyler Technologies' product page for Enterprise Service Requests — the platform this work was done on, not a project of my own.

At Tyler Technologies I work on Enterprise Service Requests, a multi-tenant service-request platform that organizations use to take in requests and incidents and route them through pre-defined workflows, so each one reaches the right team, is documented, and gets tracked to resolution. End users file through a web portal or a mobile app; staff work the queue from the back office. The estate I work across is seven web applications, some AWS-hosted and some still on-premise, and this project moved all of them from .NET 8 to .NET 10.

A major framework version across an estate this shape is not a version-bump commit. The runtime, the SDK, the base images, and the CI agents all have to move together, and a dependency graph that resolved cleanly under .NET 8 does not necessarily resolve under .NET 10 — transitive packages pin ranges that no longer overlap, and the conflict usually surfaces as a restore failure in CI rather than anything a local build reveals. Breaking changes then arrive at different layers: some at compile time, some only under load in an environment that resembles production.

The cost of getting this wrong is not an internal inconvenience. The platform is how its customers' users get a request in front of the right team — so a broken intake channel does not simply inconvenience one user, it stops work from reaching the people who act on it, across every tenant on that application at once. That framing decided the approach: the migration ran one application at a time through Development, QA, Staging, and Production rather than as a single estate-wide cutover. Sequencing it that way keeps the blast radius to one application, and makes each promotion evidence for the next rather than a bet on all seven at once. The on-premise and cloud deployments were handled as distinct targets, since they do not share a release path.

The work I would point to is less the upgrade itself than the ordering and the verification around it: deciding what moves first, what has to move together, and what signal confirms an environment is actually healthy before the next promotion. Centralized Datadog metrics, logs, and traces are what made that last question answerable with something other than optimism.

• Migrated seven production web applications from .NET 8 to .NET 10 across both on-premise and AWS-hosted deployments.
• Worked each application through the full cycle — sprint planning, development, and deployment across CI, QA, and production.
• Resolved transitive dependency conflicts and triaged breaking changes surfacing at compile time and at runtime.
• Sequenced the rollout per-application through Development, QA, Staging, and Production so a regression could never span the estate.
• Treated on-premise and cloud as separate release targets, since the two do not share a deployment path.
• Used centralized Datadog metrics, logs, and traces to verify environment health before each promotion.
• Used AI tooling — OpenAI Codex and Claude Code — to speed up development and to trace and fix errors surfacing in CI, QA, and production.
• Worked on a multi-tenant platform where an outage in one application reaches every customer on it, which made a per-application rollout the only acceptable shape.