When Not to Move a Windows App to the Web: A Decision Table and the Practical Answer of Splitting

“We’d like to move the Windows app we use in-house to the web soon” — this kind of request comes up more and more every year. It’s often a reasonable motivation, but when we dig into the details, we frequently find teams about to fully migrate to the web an app that would actually become harder to use and more expensive as a result.

Let me say up front: this article is not an argument for “never migrate to the web.” There are plenty of situations — use from multiple sites, reducing device management overhead — where web migration is clearly the right call. The problem is treating apps whose nature doesn’t suit the web as if “modernization = web migration” applies universally. This article organizes how we actually judge, in Windows contract development work, which cases are better off not migrating to the web, and lays out splitting as a realistic alternative to the all-or-nothing choice between “fully web” and “fully Windows.”

1. The Bottom Line First (Decision Table)

The key is to judge not the app as a whole, but each function or characteristic the app has, individually.

Now, here’s the conclusion up front.

• Requests to “go web” usually mix together three different problems. The hassle of distribution, constraints on where the app can be used, and technological obsolescence. Each has a different solution, and web migration is the only fix for just some of them (Chapter 2).
• Apps with device integration, local file processing, or offline operation are safer left off the web, at least for those parts. Browsers deliberately restrict access to local resources for security reasons — this is a design philosophy, not a flaw in the web¹. Workarounds exist, but they bring their own costs: limited browser support, more complex operations (Chapters 3–5).
• Web migration is a rebuild, not a port. Existing screen assets can’t be carried over as-is, and once it’s done you take on a new ongoing cost: server operations. If your estimate doesn’t start from this premise, the plan will fall apart partway through (Chapter 7).
• The realistic answer is to split. Put viewing, aggregation, and reports on the web; keep device integration and on-site data entry on Windows; connect them through a shared API and database. You can start smaller than a full web migration and proceed in order of impact (Chapter 8).

2. Breaking Down What “We Want to Go Web” Actually Means

When we get a request to migrate to the web, the first thing we do is break down the request. Behind the words “we want to go web” there’s usually one (or more) of these three things.

(1) We want to eliminate the hassle of distribution and updates. The complaint is something like “every time we release a new version, we have to go around installing it on every machine.” Web migration does solve this, but you don’t need to migrate to the web to solve it. Switching to a distribution method with built-in auto-update, such as ClickOnce or MSIX, can bring distribution work down to nearly zero while keeping the app a Windows app. We cover this in detail in “Choosing a Windows App Distribution Method.” If distribution hassle is the only motivation, web migration is overkill.

(2) We want to use it from anywhere, on any device. Use from multiple sites, access from a client site or home, viewing on a tablet — this is where web migration truly shines. But even here, it’s worth separating “we want to use all functions from anywhere” from “we just want to view the data from anywhere.” In practice it’s usually the latter, in which case a split architecture (Chapter 8) that puts only the viewing and aggregation parts on the web is enough.

(3) We want to get away from old technology. The motivation here is something like “the person who built it has left the company” or “we’re anxious about staying on .NET Framework.” This is a legitimate concern, but the solution isn’t necessarily web migration. If you’re rebuilding anyway and the nature of the work suits desktop use, rebuilding as a Windows app on the latest .NET is also an option (“A Decision Table for Choosing Between WinForms / WPF / WinUI”). It’s also worth keeping in mind that moving to the web doesn’t free you from obsolescence. The well-known case of an in-house web system built for IE-only use, left stranded once IE was retired, is a good example (“Extending the Life of an IE-Mode-Dependent In-House Web System, and Its Exit Strategy”). Web apps still need maintenance to keep up with framework and browser changes — “going web” doesn’t mean “freedom from maintenance.”

Once you break the request down this way, you can see what only web migration solves, what other approaches can also solve, and what web migration doesn’t solve at all. From there, check whether the app has any functions matching the “cases better off not migrating to the web” described below.

3. Case 1: Directly Connected to Devices or Peripherals

Communication with manufacturing equipment, data capture from measurement or inspection instruments, serial (RS-232C) connected scales or barcode readers, fine-grained control of specialized printers — apps with functionality that talks directly to hardware are structurally a poor fit for migrating that part to the web.

The reason is simple: code running in a browser executes inside an isolated environment called a sandbox. Browsers deliberately block access to local resources, because it would be a problem if simply opening a web page let it freely touch files or devices on the machine. This isn’t a flaw in the web — it’s the security design itself. For example, even in Blazor WebAssembly, which lets you write a web client in C#, the code runs inside the browser’s security sandbox, and file system access or opening arbitrary network connections throws a PlatformNotSupportedException¹. What you can do is limited to the scope of what the browser itself supports².

You might object that “the Web Serial API or WebUSB let browsers do serial communication.” That’s true, but browser support is limited. The Web Serial API is supported by Chromium-based browsers (Chrome, Edge, etc.), and as of Firefox 151, released in May 2026, desktop Firefox also added support — but Safari remains unsupported (and on mobile, Chrome for Android only has partial support for serial over Bluetooth), while WebUSB is still Chromium-only³. On top of restricting the biggest advantage of web migration — “usable from any browser” — the user also has to select and grant permission for the device through a browser dialog (at least the first time, or whenever a device is added), which in practice often makes it not worth the trade-off as a device-integration mechanism for a business system.

There’s also the option of working around this with a “web app plus a resident integration agent on each device” architecture, but this is a setup where a Windows program requiring distribution and updates ends up sticking around anyway. That’s not inherently bad — it’s actually one form of the split architecture in Chapter 8 — but it’s important to share, at the planning stage, that this is not the same thing as the original expectation that “migrating to the web means we won’t need to install anything on the machines.”

For designing the device-integration part, also see “Best Practices for Checking and Displaying External Device State.”

4. Case 2: Deeply Integrated with Local Files or Other Apps

The next most common case is where working with files on the machine, or with other applications, is at the core of the business process.

• Monitoring a shared or local folder and automatically processing files placed in it
• Batch converting, renaming, or sorting hundreds or thousands of files
• Launching Excel and assembling reports via COM, or working with existing Excel macros
• Passing data to other business apps via files or inter-process communication

The general rule for browser file access is that it’s limited to “files the user selected through a dialog, on that occasion.” There’s no way to do bulk access without user interaction, nor resident-style monitoring that keeps running while the browser is closed. Recent additions like the File System Access API allow access scoped to a folder the user selected, and there’s even an experimental API (FileSystemObserver) for watching changes within a selected folder while the page is open — but these are Chromium-only⁴, carrying the same “locks you into supported browsers” problem as device integration. As for launching and controlling another local process such as Excel from the browser, there’s simply no way to do that at all.

Migrating this kind of function to the web requires changing the business workflow to something like “have the user upload files to the server, and process them server-side.” If the business can work that way, it’s an option — but if you’re dealing with routinely handling gigabyte-scale files, processing data locally that can’t leave the company, or being tightly coupled to Excel assets, it’s more reasonable — for both the builder and the user — to keep that part as a Windows app (or, for unattended processing like folder monitoring or batch jobs, a Windows service). One thing to watch specifically is where you place COM integration with Excel: Microsoft discourages and does not support automating Office from unattended, non-interactive environments such as services⁵, so code that drives Excel automatically should live on the desktop app side, where a signed-in user is running it, or should be rewritten to read and write via an Open XML-based library that doesn’t launch Office at all. We cover building Excel integration in “How to Build Excel Report Output” and folder monitoring in “The Safe Basics of FileSystemWatcher.”

5. Case 3: Used On-Site Where the Network Is Unstable, for Operations That Can’t Stop

By its nature, a web app assumes the network connection is alive. This is true of server-side-rendered web apps, of course, but also of Blazor Server, popular in the C# world — since every UI operation is processed over a persistent connection to the server, the app stops working the moment the connection drops. The official documentation states plainly that there’s no offline support².

This becomes a problem in environments like these:

• Factories, warehouses, outdoor sites: Wi-Fi signals blocked by metal shelving or machinery, with momentary drops a daily occurrence
• Lines that can’t stop: A recording or instruction screen freezing for even a few minutes affects production or shipping
• Sites with thin or unstable connections: Temporary offices relying on mobile data, ships, mountainous areas, and the like

A native Windows app can straightforwardly be built to hold data locally, keep working offline, and sync once the connection is restored. Offline operation is even listed by Microsoft itself as a reason to choose a native app⁶. It’s technically possible to make a web app offline-capable too, using a PWA (service worker) or a design that keeps data client-side, but building that out — including sync and conflict resolution — is a substantial additional investment, working against the original hope that “moving to the web will make things cheaper.”

The deciding question is: “If the network drops for 30 minutes, can this business process wait?” If it can’t, at least the screen handling that process should run locally.

6. Case 4: Keyboard-Driven, High-Speed, High-Volume Data Entry Is Central to the Job

Slip entry, inspection and shipping registration, call-center response screens — jobs where someone is at that screen all day, typing in large volumes of data, mostly via keyboard. This is an area where desktop UI is highly refined, and where web migration tends to visibly degrade the feel of using the app.

• Response latency: With server-connected models like Blazor Server, every user action involves a network round trip, raising UI latency². Even tens of milliseconds per action reliably shows up as a “sluggish” feeling across thousands of operations a day.
• Reproducing keyboard behavior: Things taken for granted in data-entry work — moving between fields with Enter, function-key assignments, instant validation while typing — end up being built while fighting the browser’s default behavior (Enter submitting a form, F1 opening help, and so on). It’s not impossible, but it means paying extra to catch up to the quality a desktop framework and grid control already have out of the box.
• Grids with large amounts of data: Building a desktop-grade grid for the web — one that smoothly virtual-scrolls through tens of thousands of rows and supports cell editing, column freezing, and copy-paste — requires adopting a full-featured commercial component and a fair amount of tuning.

For viewing, approvals, or occasional data entry, a web form is plenty. But for a screen where input speed itself is directly tied to business productivity, calmly check whether you’ll actually benefit from web migration’s advantage (usable from anywhere) — or whether that screen will, in the end, only ever be used from a fixed desk in the office. If where it’s used is fixed, web migration has nothing to gain and only things to lose.

7. Case 5: Starting a “Rebuild” While Estimating It as a “Port”

So far we’ve talked about functionality and usage patterns; the last piece is cost structure. The classic pattern where a web migration plan falls apart midway through is estimating it as a port — “move what we have to the web” — only to discover later that it was actually a rebuild.

• Screen assets don’t carry over. There’s no realistic way to automatically convert WinForms or WPF screen definitions and logic to the web — the UI has to be redesigned and rebuilt screen by screen. The number of screens times their complexity becomes your effort estimate directly.
• Business logic needs to be inventoried first. It’s not unusual, in a long-running app, for business rules that exist nowhere in the spec to exist only in the code. Web migration includes the work of digging all of that out and reimplementing it. This is exactly the principle of “don’t jump straight into a full rewrite” from “Migrating VB6 / Access Business Apps.”
• Post-completion operating costs structurally increase. Operating a desktop app meant looking after devices, but a web app brings ongoing work: building, monitoring, backing up, and applying certificate and security updates to a server (or cloud environment). If you don’t have that capability in-house, you’ll be paying an outside vendor every month. Comparing the cost of web migration needs to include this running cost, not just the initial development cost.
• Security assumptions change. The moment an app that only ran inside the company LAN is put on the web and opened to external access, the bar for authentication, authorization, transport encryption, and defense against attacks rises a level. This too is part of “the cost of web migration.”

To repeat: none of this is an argument against web migration — it’s material for estimating it on the right premise. If web migration’s benefits still outweigh the rebuild and running costs once you factor them in, go ahead. If they don’t, first check whether modernizing while staying a Windows app — moving to the latest .NET, improving the distribution method, refreshing the UI — can satisfy most of the motivation with a smaller investment.

8. The Realistic Answer: Don’t Force an All-Web-or-All-Windows Choice

Bringing everything above down to practice, the answer in most cases is neither “fully migrate to the web” nor “leave everything as-is,” but splitting.

The idea is simple: apply the decision table from Chapter 1 not to the whole app, but function by function.

• What to put on the web: Viewing, search, and aggregation of data that multiple sites or people need to see; downloading reports; light operations like approvals. Master data maintenance usually falls here too.
• What to keep on Windows: Integration with devices and peripherals, monitoring and batch-processing local files, on-site work that can’t stop even offline, screens for high-speed data entry.
• What to share: The database and business logic. Centralize the data so both the web app and the Windows app reference the same API (or database). Once this is shared, you get an architecture that satisfies most of the motivation for web migration: “on-site staff enter data through the Windows app, while head office can check it instantly through a browser.”

This architecture has practical advantages a full web migration doesn’t: the scope you rebuild at once is smaller, you can proceed in stages, starting from the highest-impact parts (viewing), and on-site usability doesn’t degrade. On the other hand, you’ll need a structure that can maintain two systems — a Windows app and a web app — so if the target app is small and mostly about viewing, a straightforward full web migration may well be the better call. This, too, is a matter of degree rather than a binary choice.

One more note: if the requirement is “we want the screens built with web technology, but we still need to touch local resources,” hybrid options like Electron or Blazor Hybrid (WebView2) exist. They let you use a web-technology UI without being constrained by the browser sandbox, but keep in mind this is still a desktop app that requires distribution — it doesn’t answer a request to “use it from the browser alone.”

9. A Checklist Before Deciding on Web Migration

Checking the following before requesting a quote or seeking internal approval reduces the risk of rework:

1. Break down the motivation: Which is the real issue — distribution hassle, where it’s used, or technological obsolescence? If it’s only distribution, would changing the distribution method be enough?
2. Hardware integration: Does it communicate directly with serial/USB devices, measurement instruments, or specialized printers? If so, decide up front how to handle that part (keep on Windows / agent architecture).
3. Dependence on local resources: Is there folder monitoring, batch file processing, or process integration with Excel and the like? Can the workflow be changed to a server-processing model?
4. Offline requirements: If the network drops for 30 minutes, can that business process wait?
5. Weight of data-entry work: Are there screens where someone types on a keyboard all day? Will that screen really be used “from anywhere”?
6. Who uses it, and from where: Who wants to see or enter what, and from where? Is it “everyone needs every function from outside the company,” or just “head office wants to view the data”?
7. Operational structure: Who will build, monitor, and apply security updates to the server? What will that cost per month?
8. Where the business logic lives: Does the spec match the code? Have you included the time needed for the inventory in your estimate?

If any of items 2 through 5 apply, we’d recommend considering a split architecture as the main approach rather than a full web migration. For general preparation before commissioning work, also see “Things Worth Sorting Out Before Requesting Outsourced Windows App Development.”

Summary

Web migration is a tool, not a goal in itself. It clearly helps with use from multiple sites and reducing device management, but device integration and local file processing run into constraints rooted in the browser’s security design, which are hard to overturn through framework choice or engineering effort, while offline operation and high-speed data entry can technically be handled, but the cost of building and operating them tends to run counter to the original goal of “making things easier by going web.” And web migration is a rebuild, not a port — once it’s done, it adds a new ongoing cost: server operations.

That’s exactly why the practical decision isn’t “web migration or not,” but a design question: “which functions go on the web, which stay on Windows, and what gets shared?” Getting from an inventory of the existing app to a decision on web migration and the design of a split architecture usually requires judgment grounded in the actual code and operations, so if you’re unsure, feel free to reach out.

Related Articles

• Things Worth Sorting Out Before Requesting Outsourced Windows App Development
• Extending the Life of and Migrating VB6 / Access Business Apps — A Decision Table for Keep, Wrap, or Replace
• A Decision Table for Choosing Between WinForms / WPF / WinUI
• Choosing a Windows App Distribution Method (MSI / MSIX / ClickOnce / xcopy / Custom Updater)
• Extending the Life of an IE-Mode-Dependent In-House Web System, and Its Exit Strategy
• Best Practices for Checking and Displaying External Device State
• The Safe Basics of FileSystemWatcher
• How to Build Excel Report Output

Related Consulting Areas

KomuraSoft LLC handles technical consulting on whether to migrate an existing Windows app to the web, designing a split web-plus-Windows architecture, and developing or modifying business applications involving device integration and local processing.

• Windows App Development
• Maintenance and Modification of Existing Windows Software
• Technical Consulting / Design Review
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

If we're updating an old Windows app anyway, should we migrate it to the web while we're at it?

We don't recommend migrating to the web for the sole reason that the app is 'old.' Web migration takes an effort closer to a full rebuild than a port, and web apps face technological obsolescence too (an in-house web system that stayed locked to IE is a textbook example). The deciding factor should not be how old or new the technology is, but how the app is actually used. If it's used from multiple sites and you want to reduce device management, web migration pays off. But if the app centers on device integration or local file processing, modernizing it while keeping it a Windows app — moving to a newer .NET version, reworking the UI — is often more cost-effective.

Doesn't moving to the web at least eliminate the hassle of distribution and installation?

It removes client-side distribution work, but if that's your only motivation, there are lighter solutions than a full web migration. Switching to a distribution method with built-in auto-update, such as ClickOnce or MSIX, can make per-machine installation visits almost unnecessary while keeping the app a Windows app. And if you do migrate to the web, you take on a new, ongoing operational cost instead: building, monitoring, and applying security updates to a server (or cloud environment). Weigh both the costs you remove and the costs you add before deciding.

Can we migrate only part of the app to the web?

Yes, and in practice that's often the realistic answer. A typical pattern is to put data viewing, aggregation, reports, and multi-site reference on the web, while keeping device integration, fast on-site data entry, and local file processing as a Windows app — connecting the two through a shared API and database. Compared with a full web migration, the scope you have to rebuild at once is smaller, and you can proceed step by step, starting with the parts where web migration pays off the most.

What about intermediate options like Electron, PWA, or Blazor Hybrid?

These are different in nature and need to be considered separately. Electron and Blazor Hybrid (WebView2) run as desktop apps, so they can access files and devices without being constrained by the browser sandbox, while the UI is written with web technology. That said, they're still desktop apps that require distribution and updates, so they don't answer a request to 'make it usable from the browser alone.' A PWA, on the other hand, can feel installed — pinned to the taskbar, for instance — but under the hood it's still a web app running in the browser, with the same restrictions on local resource access as any other web app. It's important to first break down exactly what problem you're trying to solve by considering web migration.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.