Start with architecture and behaviour
Web Forms has its own page lifecycle, server controls, postback behaviour and state management. A slow screen or unexpected validation result may be connected to those mechanisms, the database or an external dependency. We investigate the specific behaviour before proposing a change.
We also establish the .NET Framework version, IIS configuration, third-party controls, authentication and build process. These details affect the options available and the effort needed to release safely.
Work that can be scoped separately
- Investigating errors, unreliable journeys and failed background operations.
- Improving database access and slow reporting.
- Adding defined workflows, forms or integrations.
- Reviewing access controls and handling of user-supplied data.
- Improving mobile presentation and accessibility in existing screens.
- Making releases, configuration and handover less dependent on one person.
A maintenance assignment need not become a complete platform migration unless the requirements justify it.
Understand the migration boundary
Web Forms is part of ASP.NET on .NET Framework. It is not a UI framework that can simply be recompiled as ASP.NET Core. Moving to a different application framework involves decisions about screens, state, authentication and the business logic currently tied to page events.
We assess what can be reused and what needs redesign. The lifecycle of the actual framework, operating system and components should be checked independently rather than described with a blanket end-of-life claim.
Make an incremental plan
An illustrative first step might be separating a repeated business rule from page code, creating a clear integration boundary or replacing one high-friction workflow. The right sequence depends on the application and its tests, not a universal migration recipe.
Where old and new parts coexist, we define ownership of data, identities and transactions. We also retain a practical release and recovery plan so ordinary users are not left to discover integration faults.
Scope and acceptance
Send the source solution, build instructions if available, framework and hosting details, database dependencies and examples of the issue. We use those to distinguish a bounded fix from wider discovery.
Acceptance checks should describe what staff or customers can successfully do after the release. A successful compile is necessary for a compiled application, but it is not proof that the business journey works.
Common questions
Can you support C# and VB.NET Web Forms code?
These are relevant parts of Naxtech’s Microsoft development experience. The particular codebase, dependencies and build access still need assessment before scope is agreed.
Should we move everything to ASP.NET Core immediately?
Only where requirements and risk justify it. Retaining useful functionality while improving selected areas may be more proportionate than an immediate rewrite.
Can accessibility improve without a full rebuild?
Often, but server controls, generated markup and page behaviour need examination. We agree the changes and test the actual rendered journeys.