Desktop App Web Migration Service
One source, two ways to use it.
Move your .NET Framework desktop app to .NET 10 and use it in the browser too — without rebuilding the screens.
No screen rebuild
The web version runs the same source as the desktop version on the server and shows its screens in the browser. No redesign or rebuild of screens.
Two safe stages
First move from .NET Framework to .NET 10 (LTS) and verify it as a desktop app. Then change what the web needs: third-party controls, Win32 API and EXE calls.
Keep the desktop version
The desktop version keeps working after you go web. Use each per business area or site, and switch over gradually.
Target systems
Everything is brought to .NET 10 first, then taken to the web the same way.
Windows Forms apps
- Move to .NET 10 (update the project format, replace APIs not available in .NET 10)
- Replace third-party controls with our library
- Review Win32 API calls and decide how to handle EXE calls
- Run the same source on Blazor Server, while the desktop version continues
VB6 / Delphi / PowerBuilder
- Convert to .NET (C#) with conversion tools; our library absorbs compatibility
- Once on .NET, go web with the same steps as .NET Framework apps
.NET Framework support status
4.x is treated as part of Windows and is supported along with Windows.
| Version | Support model | End of support | Notes |
|---|---|---|---|
| .NET Framework 4.8.1 / 4.8 / 4.7.x | Windows component | Follows the Windows version it runs on | 4.8.1 is the final release. New features are added only to .NET (.NET 10 etc.) |
| .NET Framework 4.6.2 | Own end date | 12 Jan 2027 | Update to 4.8 / 4.8.1, or move to .NET |
| .NET Framework 3.5 SP1 | Own end date | 9 Jan 2029 | Reportedly to be removed from Windows 11 setup and installed separately |
| .NET 10 (target) | LTS | Until 14 Nov 2028 (released 11 Nov 2025) | Updated to each LTS release, which ships every two years |
| .NET 8 / .NET 9 | — | 10 Nov 2026 | Apps already on .NET 8 / 9 also need to move to .NET 10 |
.NET Framework 4.8 / 4.8.1 can be used for some time. The reason to move is less the deadline than the fact that web, new libraries and hiring all assume .NET (the .NET 10 line).
Sources: Microsoft “.NET Framework Support Policy” and “.NET and .NET Core Support Policy” (checked October 2026); heise online (.NET Framework 3.5).
Common misconceptions
“.NET Framework will soon stop working.”
4.8 / 4.8.1 continue with Windows support. The reason to move is that the web and new features assume .NET (.NET 10 etc.), not the deadline.
“Switch the project to .NET 10 and it just runs.”
Besides the project format, features unavailable in .NET 10 (BinaryFormatter, .NET Remoting, AppDomain isolation, etc.) must be rewritten.
“Going web means rebuilding the screens.”
Our web version runs the same source as the desktop version on the server. Changes focus on what cannot run in a browser: third-party controls, Win32 API and EXE calls.
Three steps to the web
For .NET Framework desktop applications (Windows Forms)
Move to .NET 10
Conversion tools move the .NET Framework projects and source to .NET 10, verified as a desktop (Windows Forms) app.
→ Desktop version done
Changes for the web
Replace third-party controls with our library and change what cannot run in a browser, such as Win32 API and EXE calls.
→ Same source
Build and test the web version
Run on Blazor Server and use RPA to confirm the same screens and data appear as today.
→ Ready in the browser
After STEP 1 you can already run the .NET 10 desktop version in production. Web migration can then proceed screen by screen, business area by business area.
STEP 1: what moving to .NET 10 involves
Conversion tools handle the mechanical changes; the rest is checked and handled individually.
| Item | What we do | Handled by |
|---|---|---|
| Project format | Convert legacy .csproj / .vbproj to SDK style and target .NET 10 (net10.0-windows) | Conversion tool |
| References and NuGet | packages.config to PackageReference; update to .NET 10 versions or choose alternatives | Tool + review |
| Config files | Connection strings and settings in app.config are still read via the ConfigurationManager package | Conversion tool |
| Features unavailable in .NET 10 | Rewrite BinaryFormatter, .NET Remoting, AppDomain isolation, WCF server features, etc. | Tool / manual |
| Data access | ADO.NET as is; Entity Framework 6 also runs on .NET 10 (EF Core optional) | Review only |
| Reports and third-party products | Check .NET 10 support of report products and libraries; consider replacements | Decided with you |
| In-house C++ / COM components | Check how native DLLs and COM components are called, and 32-bit / 64-bit handling | Case by case |
※ The handling for each item is fixed from the up-front analysis. At this stage the app runs as a desktop (Windows Forms) app.
Three things that change for the web
The web version runs screens on a WinForms-compatible model on the server. Anything outside that model needs changes.
① Third-party controls
e.g. grids, date/number inputs, charts
Why it must change
Without their source code, third-party controls cannot be adapted to the Blazor server.
How we handle it
Replaced with controls from our library.
② Win32 API
e.g. SendMessage / FindWindow, key state, native DLLs
Why it must change
Web screens have no Windows window handles, and processing runs on the server, so the user’s PC cannot be touched.
How we handle it
Replaced with standard .NET features or our library. Server-safe processing stays; PC-dependent processing is reviewed.
③ EXE calls
e.g. launching apps with Process.Start, opening Excel or a PDF viewer, external tools
Why it must change
The program runs on the server, so an EXE would start on the server and never appear on the user’s screen.
How we handle it
Decided per target: download and open a file, run on the server, or take the called app to the web the same way.
Local file access, direct printing and peripherals such as scanners also need to be reworked to go through the browser.
Finding what must change — before the estimate
Our analysis tool parses your source and identifies what must change and the effort involved, before we estimate. Results are delivered as an Excel report.
Findings fall into four categories
- Converted automatically
- Absorbed by our library
- Fixed by hand
- Decided with you
Report contents
- Screens and complexity (high / medium / low)
- Third-party controls per screen
- Win32 API (P/Invoke) list
- EXE calls and external integration
- Features unavailable in .NET 10
- References and NuGet packages
- Lines of code by language
- Effort estimate (adjustable factors)
Counts per category directly support the effort and estimate. Analysis runs in your environment or under NDA, and your source is never uploaded to an external AI.
Desktop vs. web
Which to choose depends on what you prioritize. Both run from the same source.
| Item | Desktop (.NET 10 / Windows Forms) | Web (Blazor Server) |
|---|---|---|
| Environment | Installed on Windows PCs | Used in a browser (Edge, Chrome, etc.); the server must be Windows |
| Deployment | Deployed to each PC (auto-update possible with ClickOnce) | Placed on the server only; nothing to deploy to PCs |
| Screens and feel | Almost the same as today’s .NET Framework version | The same screens as the desktop version, drawn on the server; input fields are the browser’s own |
| Printing | Directly to printers | Basically PDF output printed from the browser |
| Files and devices | Local files and devices used directly | Browser restrictions; handling needs review |
| Where it is used | Mainly the internal network | Easy to use remotely and across sites; responsiveness depends on the network |
| Number of users | Runs on each PC, so no server-load limit | Up to about 50 users recommended, due to server load |
| Best for | Core systems with many screens, data entry | Systems used externally or across sites, inquiry-centric work |
The desktop version keeps working after you go web, and browser use can be extended to the business areas that need it.
How the web version (Blazor Server) works
Screens run only inside the server, and the browser receives their appearance. It runs from the same source as the desktop version.
A WinForms-compatible model runs on the server
Events fire in the same order as WinForms on our library’s compatible model. MessageBox and similar calls stay synchronous.
Appearance is sent as images and HTML
Controls are rendered to PNG with GDI+ and only changes are sent. Input fields are real browser inputs, so Japanese input works as is.
User actions return as window messages
Clicks and keystrokes flow on the server as window messages, so the app reacts just like the desktop version.
One process per user
So that apps holding state in static variables don’t interfere between users, a worker process is started for each browser.
Benefit：Run in the browser from the same source as the desktop version, without rewriting the migrated code.
Caution：Traffic and responsiveness depend on the network. Rendering uses GDI+, so a Windows server is required. Up to about 50 users is recommended due to server load.
Other desktop applications
VB6, Delphi, PowerBuilder and similar apps are first converted to .NET (C# / Windows Forms) and verified as desktop apps, then taken to the web the same way.
VB6
How we convert
gmStudio converts VB6 to C# / Windows Forms, also replacing COM / ActiveX, Win32 API and VB6 built-in functions.
What we check closely
- ActiveX (OCX) components
- Code that assumes 32-bit
- Direct Win32 API calls
Delphi
How we convert
After analyzing the assets, conversion tools built with AI convert the code to C#. We propose the approach after seeing your assets.
What we check closely
- Third-party VCL components
- Database components (BDE, etc.)
- Direct Win32 API calls
PowerBuilder
How we convert
Our own conversion tool converts to C#; DataWindow behaviour is reproduced by our DataWindow-compatible components.
What we check closely
- Dynamic DataWindow changes (Describe / Modify)
- OCX and external DLLs
- Reports
Components that will need changes for the web are identified during conversion, to reduce rework.
Conversion — AI builds the converter
The conversion tool converts the source; AI develops and improves that tool. The same source always yields the same code, and even if the current source changes during the project it can be re-converted at the same quality. AI only sees the tool’s source and the issues — your source stays in-house. Results are tested repeatedly with RPA.
More on AI-driven modernization →How the project runs
Analysis and a trial migration fix the approach first; then .NET 10 migration, then the web.
Analysis and PoC
Analyze assets with our tool; try .NET 10 and the web version on representative screens; fix the approach and estimate.
Move to .NET 10
Migrate with conversion tools and verify as a desktop app — usable in production at this point.
Changes for the web
Replace third-party controls and change Win32 API and EXE calls.
Build and test the web version
Build the server, add session management, and run RPA screen-comparison tests.
Go live
Switch to the web version by business area or site; the desktop version can run alongside.
※ Duration and effort depend on asset size and the components used, and are fixed from the Phase 0 results.
For testing, please provide: ① screenshots of the current system (about 5 per screen) and ② a database with the same data as when the screenshots were taken.
Service menu
Choose from three menus to match your goal.
Move to .NET 10
Delivered running as a desktop app
- Asset analysis and estimate with our tool
- Migration to .NET 10 with conversion tools
- Verified as a desktop app
- Web can be added later
.NET 10 + web
Both desktop and web versions delivered
- Everything in MENU A
- Third-party control replacement
- Win32 API and EXE call changes
- Web version built and tested (Blazor Server)
- RPA screen-comparison tests
Web from legacy languages
For VB6, Delphi and PowerBuilder
- Convert legacy source to .NET (C#)
- Then the same steps as MENU B
- .NET only, without web, is also possible
Options
Prerequisites and cautions
Points to confirm when considering the web version.
Prerequisites
- The web server must be Windows Server (rendering uses GDI+)
- Up to about 50 users is recommended; beyond that, combine with the desktop version or consult us
- Per-user session management is added
- For testing, provide current screenshots and a database with the same data
- Licence fees for .NET 10 versions of third-party products are not included
Cautions
- Responsiveness and traffic depend on the network
- Reports are basically PDF output printed from the browser
- Local files and peripherals must be reworked to go through the browser
- EXE calls need a decision per target
- For internet exposure, authentication and encryption are considered separately
Next steps
We start by looking at your assets and proposing the scope and approach for the web.
Asset analysis
Share your source and our tool identifies screens, third-party controls, Win32 API and EXE calls. NDA first.
PoC (trial migration)
Try .NET 10 and the web version on representative screens and check the feel and responsiveness yourself.
Plan and estimate
Based on the analysis and PoC, we present the scope, approach and estimate.
If your source cannot leave your company, send us the number of screens, the third-party controls used and a list of external integrations, and we will give a rough estimate.
Tell us your .NET Framework version and number of screens to start
Tell us the platform version and the number of screens, and we will send an initial answer. We are happy to sign an NDA first.
TEL +81-3-5962-3776