12 Years on an Enterprise Case-Management Platform

Background

The visible product is a case-management system: a US social-services organization uses it to register people experiencing homelessness and coordinate the help they receive — every case worker's day moves through it. But the system worth dissecting is the one underneath: an application platform built to generate business systems — relational data management, web-based collaborative processing, seamless access to distributed enterprise data, plus a tightly integrated set of modules and tools for assembling new applications. Case management was its flagship business, and "flexibly meeting each client's special needs" was the reason the platform existed.

Two constraints ran through all twelve years: business continuity above all (the system does not go down), and naturally distributed data (SQL Server and Oracle coexisting, requiring seamless access).

My role

In a 20-person team, I owned the platform's foundations — the layer every business module stands on:

• The data-access engine (the core of the platform's relational data management): read, refresh, and update behind one unified interface, so feature teams never wrote raw data code
• Gateway and identity: reverse proxy (YARP), authentication, and the shared operations libraries every service consumed
• Three service domains and their multi-year upgrades: Account Server, Chat Server, Library Server
• Horizontal tooling: data conversion utilities, a short-link service, database replication tooling

The platform's job was to make business systems quick to assemble and safe to run; my job was to make them all stand on the same foundation. On a team of twenty, "the foundations developer" is a specific kind of trust: when your module breaks, everyone's breaks.

Technical decisions

Six generations, zero rewrites. From VB.NET + WinForms in 2007, through Silverlight, ASP.NET MVC, AngularJS SPA, and Angular + .NET Core, to today's .NET 8 microservices. The data layer stayed SQL Server throughout (EF and Dapper by workload); deployment moved from on-premises servers to the cloud. Every generation was a live migration, not a greenfield restart — the front end changed its face five times while the data engine never moved, which is what layered lock-in buys:

The judgment those upgrades distilled: long-lived systems die from skipped upgrades far more often than from big ones done carefully.

The work I'm proudest of: the cross-database replication pipeline. The platform promised seamless access to distributed enterprise data; the reality was tens of millions of rows syncing SQL Server → Oracle. Early versions were slow and occasionally lost data. The final architecture made loss impossible by construction — and redelivery harmless by design. Change Tracking captures changes in-engine with zero burden on business transactions; delivery windows are materialized and paged out through a pull API; on the Oracle side, a Windows Service writes idempotently and acknowledges row by row while a server-side cursor advances only across the contiguous acknowledged run — anything unacknowledged is automatically re-offered, and row-level failures (constraint violations) take a separate retry channel that never stalls the window. Structured error tracking pinpoints drift to the specific row, health is one status query away, and any anomaly fires an immediate email alert:

A 50-million-row full-table update crossed end to end at 1,316 rows/s; five tables in parallel aggregated 17,306 rows/s — but this pipeline's hardest problem was never speed. It was making failure legible: at any moment, there is an answer for where every row stands. The pipeline later crystallized into a standalone ReplicationServer; the full design, failure model, and measurements are in its own case study.

"Is the sync healthy?" went from an investigation to a status query — not a nice-to-have; the difference between whether the person on call sleeps.

Outcome

Twelve years, one platform, six technology generations, zero rewrites. What it delivered was more than a case-management system — it was the capability for business systems to change their clothes generation after generation without ever waking the foundation.