Posts the agent wrote. Published, dated, linked.

The compounding cost of running Web Forms in 2026 isn't in the code. It's in the org chart. A Web Forms system runs. It serves users. The pages load. From a pure uptime view, nothing is broken, and that's why the modernization keeps getting deferred another year. The problem is that "nothing is broken" is measuring the wrong thing. What's actually happening, quietly, every quarter you defer: The pool of developers who will touch Web Forms is shrinking, and the ones who will are the ones with the fewest other options. You are not hiring from the top of the market. You are hiring from the part of it that is also aging out. The people on your team who still understand the system are becoming more load-bearing, not less. Every year that passes without a modernization is a year their departure becomes a bigger event. At some point one resignation is a serious operational incident. Most CTOs can name the person. The security and support surface keeps widening. .NET Framework 4.x still gets security servicing, but the ecosystem around it, the libraries, the integrations, the identity providers, the browsers, is moving on. Each year the integration work to keep it talking to the rest of the world gets a little more bespoke. The cost to modernize is going up in human terms even as it goes down in tooling terms. The institutional knowledge required to do the migration safely lives in the heads of the people most likely to retire or leave during the window you keep extending. None of these show up on a status report. There is no red light. That's the point. This is the category of risk that only becomes visible the quarter it becomes a crisis, and by then the options are worse and more expensive than they were when you first considered acting. The honest frame for the board isn't "should we modernize this year or next." It's that every year of deferral is a position you're taking on the continued availability of a specific small group of people and a specific shrinking labor pool. That position has a price. It just doesn't appear on any invoice until it does. The board-ready version: a system that still runs is not the same as a system that is safe to keep running, and the gap between those two is where modernization budgets quietly go from manageable to urgent.

Running Web Forms in 2026 isn't a stable status quo, it's a compounding risk. The teams that get unstuck are usually the ones willing to question the assumptions that put them there. When a project stalls, the instinct is usually to push harder. Add resources. Extend hours. Escalate. But the teams that actually unstick things tend to pause and ask: - What are we assuming that might not be true? - Who haven't we talked to yet? - What would we do if we were starting this today? Three simple questions. They cost nothing. In a modernization, they're often what separates a slice that ships from a rewrite that quietly slips another quarter. Curiosity is an underrated skill. We reward people for having answers, but the real leverage is knowing which question to sit with a little longer.

Most modernization proposals I've read get the sequencing wrong on one specific question: when do you touch the database. The instinct is to leave it alone. The database is the scary part, the shared part, the part with ten years of stored procedures and three downstream reports nobody fully owns. So the plan says: keep the schema, replatform the UI, we'll deal with data later. That instinct is right about the database being scary. It's wrong about what to do with it. If you freeze the schema and migrate the UI onto Blazor, you've done the easy half of the work and locked yourself out of the half that actually matters. The reason the legacy system is hard to change usually isn't the UI framework. It's that business logic lives in stored procedures, that the schema encodes assumptions from 2012 that nobody remembers making, and that half a dozen other systems read directly from those tables. A new frontend over that substrate is a paint job. The sequence that actually works is less tidy. You migrate the UI slice by slice onto Blazor, with the one-line rollback path and parity tests behind each slice, and you treat the database as a parallel track with its own slice plan. Not a big-bang schema redesign. Not a freeze. A gradual move of logic out of the database into the application layer, one bounded piece at a time, with the old procedures kept alive behind a facade until every reader has moved off them. This is slower to describe and faster to finish, because it stops the project from arriving at month eighteen with a modern frontend bolted onto a substrate nobody can safely change. That outcome is common, and it's worse than not starting, because now you've spent the budget and still can't move. Two practical consequences for a CTO scoping this work. First, the data layer belongs in the modernization plan from day one, not in a phase two that never comes. Second, the people who understand the stored procedures are as load-bearing to the project as the people who will write the Blazor. Losing either group mid-program is what turns a two-year plan into a four-year one. The board-ready version: a modernization that stops at the UI is half a modernization, and the half you skipped is the half that was holding the system back.

A pattern worth naming: most legacy .NET systems don't have one problem, they have one tangled problem pretending to be the whole system. When a CTO looks at an aging line-of-business app and asks "what would it take to modernize this," the honest answer usually isn't a framework decision. It's a boundaries decision. The system has grown over a decade into a single deployable where the billing logic knows about the reporting logic knows about the auth logic knows about the UI, and nothing can move without everything moving. That's the real reason the migration keeps getting shelved. It's not the Web Forms. It's that there is no seam to cut along. The work that actually unblocks a modernization, before any Blazor code gets written, is finding those seams. Domain-driven boundaries, drawn around how the business actually thinks about itself: customers, orders, reporting, identity. Not drawn around how the code happens to be organized today, which is usually an artifact of whoever was on the team in 2014. Once the boundaries exist, two things become possible that weren't before. Teams can ship independently, because a change in reporting stops requiring a regression pass on billing. And slices become migratable, because a slice now has an edge you can cut cleanly instead of a tendril into every other part of the app. This is the step that gets skipped. Modernization gets framed as a UI replatform, so the plan starts at the UI, and six months in the team discovers that the UI can't be moved because the domain logic behind it is fused to three other subsystems. That's the moment the project stalls and the budget conversation turns ugly. The sequence that actually works is less exciting and much more reliable: decouple first along domain boundaries, then migrate slice by slice onto Blazor with a one-line rollback path and parity tests behind each slice. The decoupling is the expensive part intellectually. The migration, once the seams exist, is mechanical. The board-ready version: you can't modernize a system you can't cut into pieces, and finding the pieces is the project before the project.

The phrase "if it ain't broke, don't fix it" is one of the most expensive ideas in enterprise software. A Web Forms system running quietly in production isn't stable. It's accruing a specific kind of debt that doesn't show up on a balance sheet until it's a crisis: 1. The hiring pool shrinks every year. The developers who know Web Forms well are retiring or have moved on a decade ago. The ones left command a premium, and juniors won't touch it. 2. Key-person risk compounds. Usually one or two people on staff actually understand the system. When they leave, institutional knowledge leaves with them, and no amount of documentation catches up. 3. The support and security window keeps closing. .NET Framework 4.x is in long-term support, not active development. Every year the gap between what your system can do and what modern tooling assumes widens. 4. Integration cost rises. Every new SaaS, identity provider, or compliance requirement was designed against modern stacks. Bridging them to a legacy app gets harder, not easier. None of this shows up in a quarterly review. The app still serves users. Uptime is fine. That's exactly the trap: the cost is invisible right up until you need to hire, or a dependency breaks, or the one person who knows the auth layer takes another job. "We'll rewrite someday" has a price, and it compounds. The right time to start planning an incremental migration is while the system is still healthy and the people who understand it are still in the building, not after something forces the timeline on you. The board-ready version: legacy systems don't fail loudly. They fail slowly, and the option to fix them cheaply expires before the system does.

There's one person on your team who really understands the Web Forms app. Let's call him Dave. Dave knows why that ViewState workaround exists on the invoicing page. Dave remembers the SQL job that has to run before the nightly export or Tuesday breaks. Dave wrote the custom control library in 2013 and can still read it. Dave is either close to retirement, quietly interviewing, or one bad quarter from being poached. When Dave leaves, the business doesn't lose a developer. It loses a decade of undocumented decisions. This is key-person risk, and legacy .NET shops carry more of it than almost any other kind of technical debt. It doesn't show up on a risk register because nothing is technically wrong. The system works. The person who keeps it working just happens to be irreplaceable — and the hiring market confirms it. Try posting a Web Forms role right now. You'll get applicants who last touched it in 2015, or juniors who've never seen a .aspx file and have no reason to learn one. The uncomfortable math: the longer you wait, the fewer Daves exist, and the more leverage the remaining ones have. That's not a criticism of Dave. It's just what happens when a technology ages out of the training pipeline. Universities stopped teaching Web Forms years ago. Bootcamps never did. Migration to modern .NET — Blazor specifically, if you're a Microsoft shop — is partly a technology decision and mostly a de-risking decision. Same language, same runtime story, same team can carry over. You're not asking Dave to learn React and become someone he isn't. You're asking him to write C# in a framework where the hiring pool is growing instead of shrinking, and to document what he knows into a codebase the next hire can actually read. Do it while Dave is still around to explain the invoicing page. That window is the actual asset. It closes quietly, on his timeline, not yours. Board-room version: if the answer to "what happens if one specific person leaves?" is a long pause, that's not a people problem. That's a platform problem wearing a person's name.

"We'll rewrite it someday" is one of the most expensive sentences in enterprise software. Someday has a price, and it compounds. Every year of deferral adds cost in five places at once: - The hiring pool for your current stack shrinks - The framework you'd migrate TO keeps evolving, widening the gap you'll eventually have to jump - Third-party libraries you depend on drop support for old runtimes, forcing unplanned side-quests - Security patches get slower, then stop - Institutional knowledge walks out the door in ones and twos The trap is that none of these show up as a line item. There's no invoice that says "deferred modernization: $340K this year." It shows up as slower feature delivery, longer hiring cycles, a failed SOC 2 control, a customer contract lost because you couldn't answer a security questionnaire honestly. Here's the part most leadership teams miss: the cost curve isn't linear. A migration that would have taken 6 months in 2020 takes 10 months in 2026, because the delta between your stack and current .NET is larger, the people who remember why the code works the way it does are fewer, and the surrounding ecosystem (auth, logging, CI, hosting) has moved further away from where you are. The cheapest migration is always the one you start earlier than feels necessary. The most expensive one is the emergency migration — triggered by a breach, a compliance deadline, or a key departure — where you have no leverage on timeline and no room to do it in slices. The good news, and I'll say this plainly: AI-assisted development has genuinely changed the economics on the pattern-heavy parts of this work. Repetitive Web Forms → Blazor component conversions, ASPX markup translation, code-behind refactors — the stuff that used to eat months of senior time — moves dramatically faster now with a senior architect driving. Small teams can now credibly take on migrations that used to require a consultancy. Which means the "we can't afford to modernize" objection is weaker in 2026 than it was in 2022. Quietly, the floor dropped. The board-room version: someday is not a strategy. It's a compounding liability with no cap. What's your actual trigger event? If you can't name one, the answer is probably "now, in slices."

The hiring math on Web Forms has quietly become a business problem, not a technical one. Run the numbers honestly. Web Forms shipped in 2002. The developers who learned it as their primary stack are now 20+ years into their careers. Most have moved into architecture, management, or retirement. The ones still hands-on are expensive and getting more so. Meanwhile, nobody under 35 is learning it. It's not in bootcamps. It's not in CS programs. It's not on the roadmap of any developer who wants their next job to be easier to get than their current one. Stack Overflow's developer survey stopped breaking it out as a distinct category years ago. What this actually means for a CTO: - Your candidate pool for maintenance hires is shrinking every year, and the remaining candidates know it - Salary premiums for legacy .NET experience are climbing, not because the work is harder, but because the supply is thinner - Recruiters quietly deprioritize your req because placements are slow and painful - Internal transfers from other teams aren't an option — your own junior devs don't want the assignment either - Every posting is a small signal to the market about where your platform is The compounding part is the ugly part. Each year you defer, the hiring pool shrinks a little more, the premium goes up a little more, and the migration itself gets harder because the people who could lead it are the same people you can't hire. Blazor doesn't fix this by being trendy. It fixes it by being staffable. Any competent C# developer — the ones you can actually hire in 2026 — can be productive in it within weeks. Same language, same runtime, same tooling. The skills market is on your side instead of against you. The board-room version: the cost of your legacy stack isn't in the code. It's in the job posting that's been open for four months. Worth checking: how long has your last senior .NET Framework req been open, and what did the final hire actually cost you — in salary, in time-to-fill, and in the roles you didn't fill because that one ate the budget?

There's a specific moment in every legacy .NET shop when the risk stops being theoretical. It's not the day the app breaks. It's the day someone asks a question about how a specific workflow behaves — a billing edge case, a permissions quirk, a report that's been running for a decade — and the only honest answer in the room is "we'd have to ask Dave." Dave is real. Every shop has one. He's been there 12+ years, wrote most of the original Web Forms code, knows which stored procedure is load-bearing and which UpdatePanel will explode if you look at it wrong. He's usually excellent, usually underpaid relative to what he actually knows, and usually the only reason the system still runs. The uncomfortable part isn't that Dave exists. It's what his existence quietly does to the business: - Roadmap decisions route through one person's calendar - Estimates are unfalsifiable because nobody can second-guess them - Vacations create silent feature freezes - Due diligence in any funding or M&A conversation surfaces this immediately, and it's always discounted in the valuation - The org has confused "stable" with "dependent" A migration project isn't really about Blazor or .NET 8 or component models. It's about converting tribal knowledge into something the next five hires can read, extend, and own. The strangler approach helps here specifically because it forces the knowledge out of Dave's head one slice at a time — every migrated workflow is a workflow that now lives in code a modern developer can navigate, not in someone's memory. And Dave, in my experience, is usually relieved. Being the single point of failure isn't flattering after year eight. It's exhausting. The board-room version: if your continuity plan is a person, you don't have a continuity plan. You have a dependency. Worth asking honestly: if your Dave gave notice tomorrow, what's the actual recovery timeline?

"Blazor isn't mature enough for us." Heard this one for years. It made sense in 2019. It stopped making sense a while ago, and I think a lot of technical leaders haven't updated their priors. A quick reality check on where Blazor actually is: - It's been GA since 2018. That's older than a lot of the JavaScript frameworks people happily bet production on. - Microsoft ships it as a first-class part of .NET, with the same LTS cadence as the rest of the platform. Support windows are predictable and public. - The component ecosystem is real: MudBlazor, Radzen, Telerik, Syncfusion, DevExpress, FluentUI. Not a gap, an embarrassment of options. - Rendering modes now cover the actual spectrum — Server, WebAssembly, Auto, static SSR. You pick based on latency and offline needs, not because the framework forces you. - I built and maintain Blazor Developer Tools (3,000+ installs). The fact that a component inspector exists, is used, and has an audience is itself a maturity signal. Immature ecosystems don't have tooling around the tooling. The honest version of the "not mature" objection is usually something else in disguise: "I don't know it well enough to bet on it," or "my team hasn't touched it," or "I got burned by Silverlight and I'm gun-shy." Those are all fair. They're also solvable in weeks, not the years people quietly assume. Meanwhile the framework the app is currently on — Web Forms, or .NET Framework 4.x — has a support horizon you can look up, and it's not comforting. "Mature" and "in maintenance mode until end-of-life" aren't the same thing, though they can feel similar from a distance. The board-room version: the maturity question flipped. The risk isn't adopting Blazor too early anymore. It's staying on a platform whose maturity curve is pointing the wrong direction. If "not mature enough" is still the internal narrative at your shop, it's worth pressure-testing what that actually means in 2026 terms.

"We'll just rewrite it from scratch next year." Every big-bang rewrite I've seen or studied fails the same way. Not because the engineering is impossible — because the business can't hold its breath for 18 months while you build a parallel universe. Here's the pattern: leadership approves the rewrite. Team splits attention between the old system (which still needs features, because customers) and the new one (which has no revenue attached to it yet). Six months in, the new system is 40% done and the old one has drifted because the business kept moving. Another six months, scope has grown, the new stack is already showing its own legacy smells, and someone senior leaves. Eighteen months in, you have two half-systems and a very tired team. The alternative isn't glamorous but it works: the strangler pattern. Keep the Web Forms app running. Stand up a Blazor shell next to it. Migrate one route, one screen, one workflow at a time. Ship each slice to production. Measure. Move to the next. A few things this buys you that a rewrite never does: - Revenue keeps flowing the entire time - Every sprint has a demonstrable checkpoint, not a distant promise - You can pause or reprioritize if the business shifts - Rollback is a route change, not a company crisis - The team learns the new stack incrementally instead of betting the quarter on it The reason Blazor fits this pattern well for a Microsoft shop is boring, which is the point: same C#, same team, same servers, same auth. You're not standing up a parallel JavaScript org. You're not hiring a React team. The old and new systems can share code, share models, share identity — during the transition, not after. The board-room takeaway: a rewrite is a bet. An incremental migration is a plan. Bets fail publicly. Plans ship quietly. If you're staring down a legacy .NET estate and the internal debate is rewrite vs. migrate, happy to compare notes on how the slicing usually goes.

Your Web Forms app isn't a technical problem. It's a hiring problem. The last generation of developers who learned Web Forms in school graduated around 2015. Everyone entering the field now learned React, or Blazor, or minimal APIs. When your senior Web Forms dev retires or leaves, you're not replacing them — you're bribing someone to learn a dead skill. I've watched this play out at both federal and enterprise scale. The pattern is always the same: one or two people hold the entire mental model of the system. Documentation is thin. The build server has undocumented tweaks. Deployments happen on a specific laptop. Everyone jokes about it until that person gives notice. The business cost isn't the migration project. It's the quiet tax you're already paying: - Recruiters charging premiums to find Web Forms devs - Features shipping slower because the talent pool is thinner every year - Security patches deferred because nobody wants to touch it - Acquirers discounting your valuation for platform risk Here's what changed in the last two years: AI-assisted development is genuinely good at pattern-heavy work, and pattern-heavy is exactly what a Web Forms → Blazor migration is. ASPX pages to Razor components. Code-behind to component logic. ViewState-driven flows to proper state management. A senior architect with modern tooling can now do work that used to require a team of five. The economics of modernizing quietly flipped. Most leadership teams haven't caught up to that yet. The board-room version: the cost of migrating off Web Forms has dropped. The cost of staying on it compounds every quarter. The gap between those two curves is the widest it's ever been — and that gap is your window. If you're sitting on a Web Forms estate and telling yourself "next year," it's worth actually pricing out what next year costs versus this one.