Когда не стоит переводить Windows-приложение в веб: таблица решений и «разделение» как реальный выход

«Хотим наконец перевести в веб Windows-приложение, которым пользуемся внутри компании» — таких запросов с каждым годом всё больше. Мотивация зачастую вполне обоснованная, но стоит углубиться в детали, и часто оказывается, что речь идёт о полной веб-миграции приложения, которое после этого станет менее удобным и более дорогим в эксплуатации.

Сразу оговоримся: эта статья — не призыв «никогда не переводить в веб». Есть немало ситуаций — использование из нескольких офисов, стремление сократить обслуживание устройств, — где веб-миграция явно оправдана. Проблема в другом: приложения, которые по своей природе не подходят для веба, огульно подгоняют под формулу «модернизация = веб-миграция». В этой статье мы разберём, как в реальной практике заказной разработки Windows-приложений отличают случаи, когда переход в веб лучше не делать, и предложим разделение как реальную альтернативу дилемме «всё в веб или всё в Windows».

1. Сначала вывод (таблица решений)

Главное — оценивать не приложение целиком, а каждую функцию или свойство приложения по отдельности.

А теперь — сразу вывод.

• За запросом «хотим в веб» обычно скрываются сразу три разные проблемы. Хлопоты с распространением, ограничения по месту использования и технологическое устаревание. У каждой свой способ решения, и веб-миграция — единственное решение лишь для части из них (глава 2).
• Приложениям с интеграцией оборудования, обработкой локальных файлов или офлайн-режимом безопаснее не переводить в веб хотя бы эти части. Браузеры намеренно ограничивают доступ к локальным ресурсам из соображений безопасности — это не изъян веба, а осознанный дизайн¹. Обходные пути существуют, но приносят собственные издержки: ограниченную поддержку браузеров и усложнение эксплуатации (главы 3–5).
• Веб-миграция — это не «перенос», а «переделка заново». Существующие экранные наработки нельзя перенести как есть, а после завершения проекта появляется новая постоянная статья расходов — эксплуатация сервера. Если оценка стоимости не строится на этой предпосылке, план рано или поздно рухнет (глава 7).
• Реальный выход — разделение. Просмотр, агрегацию и отчёты — в веб, интеграцию с оборудованием и ввод данных на месте — оставить в Windows, связав всё общим API и базой данных. Так можно начать с меньшего объёма, чем при полной веб-миграции, и двигаться по порядку эффекта (глава 8).

2. Раскладываем запрос «хотим в веб» на составляющие

Получив запрос на веб-миграцию, мы первым делом раскладываем его на составляющие. За словами «хотим в веб» обычно стоит одна из трёх вещей (или сразу несколько).

(1) Хотим избавиться от хлопот с распространением и обновлением. Жалоба звучит примерно так: «при каждом обновлении версии приходится обходить все компьютеры и устанавливать заново». Веб-миграция действительно это решает, но решить это можно и без перехода в веб. Переход на способ распространения со встроенным автообновлением — например, ClickOnce или MSIX — позволяет свести работу по распространению почти к нулю, оставаясь при этом Windows-приложением. Подробнее об этом — в статье «Как выбрать способ распространения Windows-приложения». Если единственный мотив — хлопоты с распространением, веб-миграция становится избыточной инвестицией.

(2) Хотим пользоваться откуда угодно, с любого устройства. Доступ из нескольких офисов, у клиента, из дома, просмотр с планшета — вот где веб-миграция действительно раскрывается. Но и здесь стоит отдельно проверить: «хотим все функции откуда угодно» или «хотим видеть данные откуда угодно»? На практике чаще верно второе, и тогда достаточно разделённой архитектуры (глава 8), при которой в веб выносится только просмотр и агрегация.

(3) Хотим уйти от устаревшей технологии. Мотив звучит как «человек, который это писал, уволился» или «страшно оставаться на .NET Framework». Проблема законная, но решение необязательно веб-миграция. Если переделывать всё равно придётся, а характер работы тяготеет к десктопу, есть вариант переписать приложение на актуальной версии .NET, оставаясь в Windows («Таблица решений: выбор между WinForms, WPF и WinUI»). Также стоит помнить, что переход в веб сам по себе не избавляет от устаревания. Хорошо известный случай — корпоративная веб-система, изначально созданная только под IE, которая осталась не у дел после прекращения поддержки IE (см. «Продление жизни корпоративной веб-системы через режим IE и стратегия выхода»). Веб-приложения тоже требуют сопровождения, чтобы не отставать от изменений во фреймворках и браузерах, — «перейти в веб» не равно «избавиться от сопровождения».

После такого разбора становится видно, что решается только веб-миграцией, что решается и другими способами, а что веб-миграция не решает вовсе. Дальше нужно проверить, нет ли в приложении функций, подпадающих под описанные ниже случаи, когда лучше не переводить в веб.

3. Случай 1: прямая связь с оборудованием и периферией

Связь с производственным оборудованием, приём данных от измерительных или контрольных приборов, весы или сканеры штрихкодов по последовательному интерфейсу (RS-232C), тонкое управление специализированными принтерами — приложения с функциями прямого общения с оборудованием структурно плохо подходят для перевода этой части в веб.

Причина проста: код в браузере выполняется в изолированной среде — песочнице. Браузеры намеренно блокируют доступ к локальным ресурсам, чтобы простое открытие веб-страницы не могло произвольно трогать файлы или устройства на компьютере. Это не изъян веба, а сама суть его архитектуры безопасности. Например, даже в Blazor WebAssembly, позволяющем писать веб-клиент на C#, код выполняется внутри песочницы браузера, а доступ к файловой системе или открытие произвольного сетевого соединения приводит к исключению PlatformNotSupportedException¹. Возможности ограничены тем, что умеет сам браузер².

Можно возразить: «а как же Web Serial API и WebUSB — они ведь позволяют браузеру работать с последовательным портом». Действительно, такие API существуют, но поддержка браузеров ограничена. Web Serial API работает в браузерах на Chromium (Chrome, Edge и др.), а начиная с Firefox 151, выпущенного в мае 2026 года, появилась поддержка и в десктопной версии Firefox — но Safari до сих пор не поддерживает эту технологию (а на мобильных устройствах Chrome для Android поддерживает лишь частично, только последовательную связь через Bluetooth), при этом WebUSB по-прежнему работает только в браузерах на Chromium³. Помимо того, что это ограничивает главное преимущество веб-миграции — «работает из любого браузера», — при подключении устройства (как минимум при первом подключении или при добавлении нового устройства) пользователю всё равно нужно вручную выбрать устройство и дать разрешение через диалог браузера, поэтому как способ интеграции с оборудованием в бизнес-системе это часто просто не окупается.

Есть также вариант обойти ограничение через архитектуру «веб-приложение плюс резидентный агент интеграции на каждом устройстве», но при этом Windows-программа, требующая распространения и обновления, всё равно остаётся. Само по себе это не плохо — это по сути одна из форм разделённой архитектуры из главы 8, — но важно проговорить это на этапе планирования: это совсем не то же самое, что изначальная надежда «после перехода в веб на компьютеры вообще ничего не придётся ставить».

По проектированию интеграции с оборудованием также см. «Лучшие практики проверки и отображения состояния внешних устройств».

4. Случай 2: тесная интеграция с локальными файлами и другими приложениями

Следующий частый случай — когда работа с файлами на компьютере или с другими приложениями составляет ядро бизнес-процесса.

• Мониторинг общей или локальной папки с автоматической обработкой появляющихся в ней файлов
• Пакетное преобразование, переименование или сортировка сотен или тысяч файлов
• Запуск Excel и сборка отчётов через COM, работа с существующими макросами Excel
• Обмен данными с другими бизнес-приложениями через файлы или межпроцессное взаимодействие

Общее правило доступа браузера к файлам — доступ ограничен «файлами, которые пользователь сам выбрал через диалог в конкретный момент». Массовый доступ без действий пользователя, а также резидентный мониторинг, продолжающий работать при закрытом браузере, невозможны. Современный File System Access API позволяет получить доступ в рамках выбранной пользователем папки, а экспериментальный API (FileSystemObserver) даже умеет отслеживать изменения в выбранной папке, пока открыта страница, — но всё это работает только в браузерах на Chromium⁴ и несёт ту же проблему «привязки к поддерживаемым браузерам», что и интеграция с оборудованием. А способа запустить и управлять из браузера другим локальным процессом, например Excel, попросту не существует.

Перевод такого функционала в веб потребует изменить сам рабочий процесс: например, «пользователь загружает файлы на сервер, а обработка происходит на стороне сервера». Если бизнес может работать в такой логике — это вариант. Но если у вас регулярно обрабатываются файлы размером в гигабайты, данные обрабатываются локально и не могут покидать компанию, или есть плотная связь с наработками в Excel, разумнее оставить эту часть в виде Windows-приложения (а для безлюдной обработки вроде мониторинга папок или пакетных задач — в виде Windows-службы). Отдельно стоит обратить внимание на размещение COM-интеграции с Excel: Microsoft не рекомендует и не поддерживает автоматизацию Office из безлюдных, неинтерактивных сред вроде служб⁵, поэтому код, управляющий Excel автоматически, должен находиться на стороне десктопного приложения, где работает вошедший в систему пользователь, либо его стоит переписать на работу с форматом Open XML напрямую, без запуска самого Office. О построении интеграции с Excel мы писали в статье «Как реализовать вывод отчётов в Excel», а о мониторинге папок — в «Безопасные основы работы с FileSystemWatcher».

5. Случай 3: работа на объектах с нестабильной сетью, где процесс нельзя останавливать

По своей природе веб-приложение предполагает наличие постоянного сетевого соединения. Это верно и для веб-приложений с серверным рендерингом, и — что важно для мира C# — для Blazor Server: поскольку каждое действие пользователя обрабатывается через постоянное соединение с сервером, при разрыве соединения приложение перестаёт работать. В официальной документации прямо указано, что офлайн-режим не поддерживается².

Это становится проблемой в таких условиях:

• Заводы, склады, работа на улице: сигнал Wi-Fi блокируется металлическими стеллажами или оборудованием, кратковременные обрывы связи происходят регулярно
• Линии, которые нельзя останавливать: если экран регистрации или инструкций зависает даже на пару минут, это сказывается на производстве или отгрузке
• Объекты с тонким или нестабильным каналом связи: временные офисы на мобильном интернете, суда, горные районы и подобные места

Нативное Windows-приложение можно без особых сложностей построить так, чтобы данные хранились локально, работа продолжалась в офлайне, а синхронизация происходила после восстановления связи. Офлайн-режим сама Microsoft называет одной из причин выбирать нативное приложение⁶. Технически сделать веб-приложение способным работать офлайн тоже возможно — через PWA (service worker) или архитектуру с хранением данных на стороне клиента, — но реализация этого, включая синхронизацию и разрешение конфликтов, требует существенных дополнительных вложений, что идёт вразрез с изначальной надеждой «переход в веб сделает всё дешевле».

Ключевой вопрос для принятия решения: «если сеть пропадёт на 30 минут, сможет ли этот процесс подождать?» Если нет — экран, отвечающий за этот процесс, должен работать локально, как минимум.

6. Случай 4: в основе работы — быстрый и объёмный ввод данных с клавиатуры

Ввод накладных, регистрация проверки и отгрузки, экран оператора колл-центра — работа, где человек весь день сидит за экраном и вводит большие объёмы данных, в основном с клавиатуры. Это область, где качество десктопного интерфейса очень высоко, и переход в веб часто заметно ухудшает субъективное качество работы.

• Задержка отклика: при архитектуре с постоянным соединением с сервером, как у Blazor Server, каждое действие пользователя сопровождается сетевым круговым обменом, что повышает задержку интерфейса². Даже десятки миллисекунд на одно действие при тысячах операций в день ощущаются вполне отчётливо как «подтормаживание».
• Воспроизведение поведения клавиатуры: такие привычные для ввода данных вещи, как переход между полями по Enter, назначение функциональных клавиш, мгновенная валидация при вводе, приходится реализовывать, преодолевая поведение браузера по умолчанию (Enter отправляет форму, F1 открывает справку и т. п.). Это не невозможно, но означает доплату за то, чтобы догнать качество, которое десктопный фреймворк и компонент таблицы дают «из коробки».
• Таблицы с большими объёмами данных: чтобы реализовать в вебе таблицу десктопного уровня — с плавной виртуальной прокруткой через десятки тысяч строк, редактированием ячеек, закреплением столбцов и копированием-вставкой, — требуется полнофункциональный коммерческий компонент и немалая доработка.

Для просмотра, согласований или редкого ввода веб-форма вполне подходит. Но для экрана, где скорость ввода напрямую влияет на производительность бизнеса, стоит трезво оценить: реально ли будет использовано преимущество веб-миграции (доступность откуда угодно), или этот экран в итоге всё равно будет использоваться только с фиксированного рабочего места в офисе? Если место использования зафиксировано, веб-миграция ничего не даёт, а только отнимает.

7. Случай 5: смету составили как на «перенос», а по факту начали «переделку заново»

До сих пор речь шла о функциональности и способах использования, теперь — о структуре затрат. Классический сценарий, при котором план веб-миграции рушится на полпути, — это когда смету считают исходя из образа «перенести то, что есть, в веб», а по факту оказывается, что это была переделка заново.

• Экранные наработки перенести нельзя. Реального способа автоматически конвертировать в веб описания и логику экранов WinForms или WPF не существует — интерфейс придётся спроектировать и построить заново для каждого экрана. Количество экранов, умноженное на их сложность, напрямую становится трудозатратами.
• Сначала нужна инвентаризация бизнес-логики. В приложениях с долгой историей эксплуатации нередко встречаются бизнес-правила, которые нигде не задокументированы и существуют только в коде. Веб-миграция включает в себя работу по извлечению всего этого и повторной реализации. Здесь полностью применим принцип «не переписывать всё целиком с нуля» из статьи о продлении жизни и миграции бизнес-приложений на VB6 / Access.
• Расходы на эксплуатацию после завершения структурно растут. Эксплуатация десктопного приложения сводилась к обслуживанию устройств, а веб-приложение приносит постоянную работу: развёртывание, мониторинг, резервное копирование, обновление сертификатов и безопасности сервера (или облачной среды). Если в компании нет своей команды для этого, придётся ежемесячно платить внешним подрядчикам. Сравнение стоимости веб-миграции нужно проводить с учётом не только первоначальной разработки, но и этих текущих расходов.
• Меняются требования к безопасности. В момент, когда приложение, работавшее только внутри корпоративной сети, переводится в веб и открывается для доступа извне, планка требований к аутентификации, авторизации, шифрованию трафика и защите от атак поднимается на новый уровень. Это тоже часть «стоимости веб-миграции».

Повторим: всё это не аргументы против веб-миграции, а материал для корректной оценки стоимости. Если даже с учётом переделки и текущих расходов преимущества веб-миграции перевешивают, стоит её проводить. Если нет — сначала стоит проверить, можно ли меньшими вложениями закрыть большую часть мотивации через модернизацию в рамках Windows-приложения (переход на актуальный .NET, улучшение способа распространения, обновление интерфейса).

8. Реальный выход: не сводить всё к дилемме «всё в веб или всё в Windows»

Если применить всё вышесказанное на практике, ответом в большинстве случаев оказывается не «полная веб-миграция» и не «оставить как есть», а разделение.

Идея проста: применять таблицу решений из главы 1 не ко всему приложению целиком, а к каждой функции отдельно.

• Что выносить в веб: просмотр, поиск и агрегацию данных, которые нужны нескольким офисам или сотрудникам, скачивание отчётов, лёгкие операции вроде согласований. Ведение справочников тоже обычно попадает сюда.
• Что оставлять в Windows: интеграцию с оборудованием и периферией, мониторинг и пакетную обработку локальных файлов, работу на месте, которую нельзя останавливать даже в офлайне, экраны быстрого ввода данных.
• Что делать общим: базу данных и бизнес-логику. Данные централизуются так, чтобы и веб-приложение, и Windows-приложение обращались к одному и тому же API (или базе данных). При такой общей части получается архитектура, закрывающая большую часть мотивации для веб-миграции: «сотрудники на месте вводят данные через Windows-приложение, а головной офис мгновенно видит их через браузер».

У такой архитектуры есть практические преимущества, которых нет у полной веб-миграции: меньший объём одномоментной переделки, возможность двигаться поэтапно, начиная с самых эффективных частей (просмотра), а также сохранение удобства работы на местах. С другой стороны, потребуется команда, способная поддерживать сразу две системы — Windows-приложение и веб-приложение, — так что если целевое приложение небольшое и в основном сводится к просмотру данных, иногда логичнее сразу сделать полную веб-миграцию. И здесь тоже вопрос не «или-или», а степени.

Отдельно стоит упомянуть: если требование звучит как «хотим, чтобы экраны были на веб-технологиях, но при этом нужен доступ к локальным ресурсам», есть гибридный вариант — Electron или Blazor Hybrid (WebView2). Он позволяет использовать интерфейс на веб-технологиях без ограничений браузерной песочницы, но нужно помнить, что это по-прежнему десктопное приложение, требующее распространения, и оно не отвечает на запрос «хотим пользоваться только из браузера».

9. Чек-лист перед принятием решения о веб-миграции

Перед запросом сметы или внутренним согласованием стоит проверить следующее — это сократит количество переделок:

1. Разложить мотивацию на составляющие: что на самом деле является проблемой — хлопоты с распространением, место использования или технологическое устаревание? Если только распространение — не достаточно ли будет сменить способ распространения?
2. Наличие интеграции с оборудованием: есть ли функции прямой связи с serial/USB-устройствами, измерительными приборами, специализированными принтерами? Если да — заранее решить, как с этим быть (оставить в Windows / архитектура с агентом).
3. Зависимость от локальных ресурсов: есть ли мониторинг папок, пакетная обработка файлов, взаимодействие с процессами вроде Excel? Можно ли изменить рабочий процесс на серверную обработку?
4. Требования к офлайн-режиму: если сеть пропадёт на 30 минут, сможет ли этот процесс подождать?
5. Доля работы по вводу данных: есть ли экраны, за которыми целый день печатают на клавиатуре? Действительно ли этим экраном будут пользоваться «откуда угодно»?
6. Реальная картина пользователей и мест использования: кто, откуда и что хочет видеть или вводить? «Всем нужны все функции извне компании» или «головному офису просто нужно видеть данные»?
7. Организация эксплуатации: кто будет заниматься развёртыванием, мониторингом и обновлением безопасности сервера? Сколько это будет стоить в месяц?
8. Где находится бизнес-логика: соответствует ли документация коду? Учтено ли в смете время на инвентаризацию?

Если хотя бы один из пунктов 2–5 актуален, рекомендуем рассматривать в качестве основного варианта не полную веб-миграцию, а разделённую архитектуру. Об общей подготовке перед заказом разработки также см. «Что стоит прояснить перед заказом внешней разработки Windows-приложения».

Итог

Веб-миграция — это инструмент, а не самоцель. Она однозначно помогает при использовании из нескольких офисов и при стремлении сократить обслуживание устройств, но интеграция с оборудованием и обработка локальных файлов упираются в ограничения, коренящиеся в архитектуре безопасности браузера, которые трудно преодолеть выбором фреймворка или дополнительной разработкой, а офлайн-режим и быстрый ввод данных технически реализуемы, но затраты на их реализацию и эксплуатацию часто идут вразрез с изначальной целью «стало легче за счёт перехода в веб». И, наконец, веб-миграция — это переделка заново, а не перенос, и после её завершения добавляется новая постоянная статья расходов — эксплуатация сервера.

Именно поэтому практическое решение — это не вопрос «переводить в веб или нет», а вопрос проектирования: «какие функции вынести в веб, какие оставить в Windows, а что сделать общим». Путь от инвентаризации существующего приложения до решения о целесообразности веб-миграции и проектирования разделённой архитектуры почти всегда требует суждений, основанных на реальном коде и практике эксплуатации, — если сомневаетесь, обращайтесь к нам за консультацией.

Связанные статьи

• Что стоит прояснить перед заказом внешней разработки Windows-приложения
• Продление жизни и миграция бизнес-приложений на VB6 / Access — таблица решений «оставить, обернуть или заменить»
• Таблица решений: выбор между WinForms, WPF и WinUI
• Как выбрать способ распространения Windows-приложения (MSI / MSIX / ClickOnce / xcopy / собственный updater)
• Продление жизни корпоративной веб-системы через режим IE и стратегия выхода
• Лучшие практики проверки и отображения состояния внешних устройств
• Безопасные основы работы с FileSystemWatcher
• Как реализовать вывод отчётов в Excel

Похожие направления консультаций

«Го Комура Софт» занимается техническими консультациями по вопросам целесообразности веб-миграции существующих Windows-приложений, проектирования разделённой архитектуры «веб + Windows», а также разработки и доработки бизнес-приложений с интеграцией оборудования и локальной обработкой данных.

• Разработка Windows-приложений
• Доработка и сопровождение существующего Windows-ПО
• Техническая консультация и обзор архитектуры
• Связаться с нами

Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если мы всё равно обновляем старое Windows-приложение, стоит ли заодно перевести его в веб?

Переводить приложение в веб только потому, что оно «старое», мы не рекомендуем. Веб-миграция по трудозатратам ближе к полной переделке, чем к переносу, а веб-приложения тоже подвержены технологическому устареванию (классический пример — корпоративная веб-система, оставшаяся работать только в IE). Определяющим фактором должна быть не «древность» технологии, а то, как приложение реально используется. Если им пользуются из нескольких офисов и хочется сократить объём обслуживания устройств, преимущества веб-миграции очевидны. Но если в основе приложения — интеграция с оборудованием или обработка локальных файлов, модернизация в рамках Windows-приложения (переход на новую версию .NET, обновление интерфейса) чаще оказывается выгоднее по соотношению цена/эффект.

Разве перевод в веб не избавляет от хлопот с распространением и установкой?

Работа по распространению на клиентских машинах действительно исчезает, но если это единственный мотив, есть решения легче, чем веб-миграция. Переход на способ распространения со встроенным автообновлением — например, ClickOnce или MSIX — позволяет практически свести к нулю обход всех устройств для установки, оставаясь при этом Windows-приложением. А при переводе в веб вместо этого появляется новая постоянная статья расходов — развёртывание, мониторинг и обновление безопасности сервера (или облачной среды). Принимайте решение, оценивая одновременно и то, какие затраты исчезают, и то, какие появляются.

Можно ли перевести в веб только часть приложения?

Можно, и на практике именно такой вариант часто оказывается реальным решением. Типичная схема — вынести в веб просмотр данных, агрегацию, отчёты и доступ из нескольких офисов, а интеграцию с оборудованием, быстрый ввод на месте и обработку локальных файлов оставить в виде Windows-приложения, связав обе части общим API и базой данных. По сравнению с полной веб-миграцией объём одномоментной переделки меньше, и можно двигаться поэтапно, начиная с тех частей, где эффект от перехода в веб наиболее заметен.

А как насчёт промежуточных вариантов вроде Electron, PWA или Blazor Hybrid?

Здесь смешаны вещи разной природы, и их нужно рассматривать по отдельности. Electron и Blazor Hybrid (WebView2) работают как настольные приложения, поэтому могут обращаться к файлам и устройствам без ограничений браузерной песочницы, а экраны при этом пишутся с помощью веб-технологий. Однако это по-прежнему настольные приложения, требующие распространения и обновления, и они не отвечают на запрос «сделать доступным только из браузера». PWA, в свою очередь, может ощущаться как установленное приложение — например, закрепляться на панели задач, — но по сути остаётся веб-приложением, работающим в браузере, с теми же ограничениями доступа к локальным ресурсам, что и у обычного веб-приложения. Поэтому важно сначала разобраться, какую именно проблему вы пытаетесь решить, рассматривая веб-миграцию.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.