ASP.NET Web Forms was never ported to modern .NET — and per Microsoft, it never will be. Marcus, Kinetech's AI Mendix developer, reads the source your team inherited — every .aspx, every code-behind, every stored procedure — and rebuilds it as a modern, governed Mendix application, with evidence for every release.
01 · The clock
Your Web Forms apps still run. That's exactly the trap: .NET Framework 4.8 is maintained as a Windows component — security patches only — while the platform, the language tooling, and the people move on without it.
Rehosting is a rent payment, not a fix. Moving a Web Forms app to Azure or Server 2025 buys calendar time on the same frozen framework with the same staffing problem — and you'll pay for the move twice when the real modernization happens anyway.
02 · The unlock
A legacy .NET app is one of the most readable artifacts in enterprise software — everything is plain text. Marcus ingests the actual solution and derives a complete functional specification you review before anything is rebuilt.
| What you have | What Marcus extracts | What it becomes in Mendix |
|---|---|---|
| SQL schema & stored procedures | The true data model: tables, keys, relationships — and the business logic that migrated into procedures over the years | Domain-model entities and associations; procedure logic becomes documented microflows |
| Pages .aspx / .ascx / master pages | Full page and control inventory, navigation structure, the GridView/FormView CRUD patterns | Pages on a modern responsive layout — grids become Data Grid 2, forms become data views |
| Code-behind C# / VB.NET | Business rules, validation, calculations, event logic — the app's actual behavior, read line by line | Microflows and validation logic, documented and unit-tested |
| web.config + role checks | The complete security model: authorization rules, connection strings, membership config, every IsInRole scattered through the code | A written role-permission matrix for your sign-off, then Mendix model-level security and SSO |
| WinForms / WPF LOB apps | Typed DataSets, form layouts, event handlers — the same anatomy in desktop clothes | Web apps your users reach without a deployment package on every desktop |
| Compiled DLLs — source lost | .NET IL decompiles unusually well; tooling like ILSpy recovers buildable source from assemblies you own the rights to | The same pipeline as above — losing the source doesn't mean losing the app |
The extraction produces a written specification — data model, page inventory, business rules, role matrix — in plain English. You approve it before a line of the model is written. Your senior developer reviews a spec, not 200,000 lines of inherited code.
03 · How a migration runs
04 · The date
Here is the commitment we will put in writing. The assessment does not end with a range — it ends with a date, sized from your actual extracted complexity. Miss that date and the assessment fee comes back. We can promise a date because we never quote a calendar before reading your source.
The assessment names the date. Miss it, and the assessment fee comes back.
That is a real term, not a slide. It is affordable to us for one reason: the clock below starts only when a complete artifact pack is in our hands, and it pauses only for your own approval gates.
| One Web Forms application | Complete artifact pack → UAT-ready |
|---|---|
| Compact — ≤30 .aspx pages, ≤3 integrations, database-centric logic | 2–3 weeks |
| Departmental — 30–80 pages, user controls, 2–5 integrations | 4–6 weeks · ~30 days typical |
| Load-bearing — 80+ pages, WCF hybrid, custom membership, heavy ViewState-driven flows | 8–14 weeks |
| Each further application in the same estate | 30–40% faster |
Sizing model, not a price list — the assessment reads your actual source and returns one date. Bands assume a single rebuild boundary agreed at the scope gate.
The date is only honest if the inputs are complete, so here is the whole list up front. Nothing on it is unusual, and most of it exists already.
Three approval gates are yours: scope, permission ratification, design sign-off. We answer each within three business days. Time beyond that on your side moves the date by exactly that much — and nothing else does.
Production cutover on your change calendar. SSO and network provisioning by your IT. Third-party licenses or vendor contracts we don't control. Remediation of source-data quality problems the assessment flagged. Anything added after the scope gate.
Functional parity against the approved specification, running on your migrated data in a parallel environment, with production security enforced and tested per role, all nine quality gates green, and documentation published. Your users click through it.
Source is fully readable, so extraction is not the constraint — decisions are. What moves a Web Forms date is business logic spread between code-behind and stored procedures with no clear boundary, ViewState-driven page flows that encode rules nobody wrote down, and reporting. Worth noting what Copilot-class modernization tooling does not do: it does not convert Web Forms.
05 · The obvious question
If you have the team, the budget, and eighteen spare months — genuinely, maybe. Blazor is a fine platform. Here's the honest comparison for a portfolio of departmental apps:
| Hand rewrite to Blazor / ASP.NET Core | Marcus rebuild in Mendix | |
|---|---|---|
| Automation | None. Microsoft's own guidance is a guided hand-rewrite; its Copilot app-modernization agent upgrades .NET versions and rehosts to Azure but — per Microsoft's own FAQ — does not convert Web Forms. The programming models are too different. | Marcus reads the source, extracts the spec, and rebuilds — your team's hours go to approvals and review, not re-typing CRUD |
| Cost & timeline | Integrator-quoted rewrites commonly run $50k–$300k+ per app and 12–24 months, with widely cited failure and stall rates for large rewrites | Fixed bid per app from the assessment; typical departmental apps are days-to-weeks of Marcus work, evidence included |
| Staffing | Consumes your scarcest people for a year-plus, on work they didn't sign up for | Your seniors review specs and commits; nobody hand-builds test scaffolding |
| What you end with | A modern codebase you must staff and maintain line by line | A governed model: 100% documented, full test suite, security enforced at the model level, graded every release |
Where we'd tell you not to use Mendix: genuinely compute-heavy engines, high-scale anonymous public sites, and pixel-perfect bespoke UI. Those belong in code — keep them there, and let the rebuilt Mendix apps call them over REST. The assessment says which bucket each app is in before you spend a dollar.
06 · Straight talk
The SQL schema, the validation and business rules in code-behind and procedures, and the role model implied by your config and code — extracted, written down, and approved by you before build.
Users get a modern, responsive, accessible app instead of a ViewState postback page — usually the first UI improvement the app has had in fifteen years. You pick the design direction before pages are generated.
COM and Office-interop dependencies need redesign, not translation. Truly bespoke UI behavior is rebuilt as custom widgets at real cost. Both get named in the assessment, per app, before you commit.
07 · Quality & security
08 · Engagement & pricing
Marcus reads your solutions and schemas and delivers a scored portfolio: rebuild / rehost / retire per app, complexity ratings, extracted specs for the priority apps, and a fixed-bid quote for each rebuild.
Runs on a repo export or read-only access. The deliverable is yours either way.
Each app rebuilt as a Delivered engagement: working, fully tested, documented, with published evidence — priced from assessed complexity, not from hope.
Typical departmental apps are days-to-weeks of Marcus work, not consultant-quarters.
For portfolios, a dedicated Marcus instance works the migration backlog continuously — either your team drives, or a Kinetech engineer reviews every release, with an SLA.
Bring your own Claude access — a direct Anthropic key or your AWS Bedrock / Google Cloud commitment — and reduce the monthly by roughly 15–25%.
One-time onboarding: $6,000–$10,000 — provisioning, secure credential setup, brand intake, first approval cycle. Pilot-program pricing — locked for 12 months for early partners.
09 · The questions you should ask
Look at your current position honestly: Web Forms is already terminal lock-in — a framework with no successor and a hiring pool that shrinks every year. The Mendix side of the trade: your data stays in plain SQL, the model is 100% documented with a full test suite in a repository you own, integration is standard REST/OData, and custom logic can drop to Java when needed. If you ever leave, you leave with a documented, tested model — not with .aspx files nobody will touch. Neither is "open" in the purist sense; one of them has a future and an exit.
For the departmental shape — tens to hundreds of users doing CRUD, search, and workflow over SQL Server — comfortably, and it scales horizontally in ways an IIS-bound Framework app doesn't. Where an app has a genuinely compute-heavy core, we'll say so in the assessment and recommend keeping that core in code behind a REST interface. We'd rather lose that line item than pretend.
Usually not. .NET compiles to intermediate language that decompiles unusually well — tooling like ILSpy can recover a buildable project from the assemblies. The one hard requirement is legal: you must own the rights to the code, which for internally-built or bought-outright apps you typically do. Recovered source enters the same read-spec-approve-rebuild pipeline as everything else.
Use it — for what it does. Per Microsoft's own FAQ it upgrades .NET versions, containerizes, and moves apps to Azure. It does not convert Web Forms to anything, because no automated converter survives the programming-model gap. So the free tool relocates your frozen app; the actual modernization — new UI, tested logic, enforced security — is still a rebuild. That rebuild is the thing Marcus automates.
Some friction is real and we won't wave it away — heads-down users are slower for a few weeks after any UI change. What we do about it: design directions are derived from how the current screens actually work (we've read them), you sign off on the direction before pages exist, and every journey is driven end-to-end before release so day one isn't a surprise. The alternative — never changing a 2008 UI — is how apps end up with a single point of human failure.
Procedures: extracted and read. Logic that belongs in the app becomes documented microflows; genuinely set-based heavy lifting can stay in the database and be called from Mendix — migrating it is a choice, not a requirement. Reporting: operational reports rebuild as pages and exports; pixel-perfect print documents are a specific workstream we scope explicitly in the assessment rather than hand-wave.
It's graded on exactly that, every build: naming conventions, 100% documentation of authored elements, tidy domain models, and a release scorecard are blocking gates. Your developers open the model in Mendix Studio Pro and read it like a teammate's work — and unlike the codebase you have now, it comes with a full test suite and visual user guides. Ask us to walk through a delivered model; maintainability is easier to judge by looking than by promises.
10 · Next step
Pick the app everyone maintains and nobody understands. The assessment reads it, produces the spec your documentation never captured, and quotes the rebuild fixed. Judge the evidence — the extracted spec alone is usually worth the conversation.
Marc Lehane · Solutions Architect / CTO, Kinetech · [email protected]
Kinetech Cloud · San Antonio, TX · How we deliver · Live Build Console
You are reading Your platform — deeper detail on step 4, Why now?.
That is the pressure. What it costs to answer it is not one number — three things move it.