Что такое VBA — ограничения, перспективы, случаи, когда стоит заменить, и реалистичные паттерны миграции

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

• Что такое VBA в принципе
• Говорят, что макросы опасны — стоит ли вообще от них отказаться
• Перестанет ли это работать в будущем
• Стоит ли переносить всё в Office Scripts или Power Automate
• Оставлять существующие .xlsm и активы Access или избавляться от них
• Можно ли запускать Excel в ночных пакетных заданиях или на сервере

Это тема, которую не решить одним универсальным ответом. Смотреть в первую очередь стоит не на новизну или старость, а на то, где это выполняется, кто это использует, является ли сам Excel / Access интерфейсом или выполнение безнадзорное.

В этой статье мы разберём по порядку: что такое VBA, где находятся его ограничения, перестанет ли он работать, в каких случаях его стоит заменить и как реалистично провести поэтапную миграцию. Содержание опирается на официальную информацию Microsoft, доступную по состоянию на март 2026 года.¹²³⁴⁵

1. Сначала — вывод

Сначала перечислим выводы.

• VBA — это событийно-ориентированный язык для расширения десктопных приложений Office. Это технология, изначально рассчитанная на работу внутри Excel, Word, PowerPoint, Access и подобных приложений.¹
• По меньшей мере по состоянию на март 2026 года в официальной информации Microsoft не подтверждается чёткого объявления о том, что «сам VBA будет прекращён в ближайшее время». Происходящее сейчас — не столько «внезапная полная отмена», сколько изменение, при котором проясняется, где и при каких условиях VBA можно использовать.¹²³⁴
• Конкретно: в Excel для веба нельзя создавать, выполнять и редактировать VBA. Также макросы в файлах из интернета по умолчанию блокируются.²³
• Поэтому актуальный вопрос сегодня — не «отказаться ли от VBA полностью», а какие области оставить в VBA, а какие вынести наружу.
• В особенности обработку, которая требует безнадзорного выполнения, серверного выполнения, многопользовательской эксплуатации, поддержки браузера, централизованного распространения или строгого аудита, естественно не держать целиком на VBA. Microsoft также не рекомендует и не поддерживает серверную автоматизацию Office.⁶
• Направление миграции не одно. Реалистичное разделение: если Excel остаётся, вынести обработку в DLL на .NET или отдельный процесс; для бизнес-процессов в Microsoft 365 — Office Scripts + Power Automate; для кросс-платформенных расширений — Office Add-ins; а если Excel уже фактически перестал быть интерфейсом — вынести в Windows-приложение или веб-приложение.⁴⁵⁶

Иными словами, практично рассматривать VBA не как «технологию, которая вот-вот умрёт», а как «технологию с чётко определённой сферой применения».

2. Что такое VBA

VBA расшифровывается как Visual Basic for Applications — это разновидность Visual Basic, поставляемая вместе с Microsoft Office. В официальной документации Microsoft он также описывается как событийно-ориентированный язык программирования для расширения приложений Office.¹⁷

Здесь важно то, что VBA ближе к реальности рассматривать не как платформу для разработки универсальных приложений, а как язык расширения, встраиваемый внутрь приложений Office.

В Excel, например, он работает рядом с такими объектами:

• Workbook
• Worksheet
• Range
• кнопки и формы
• события при открытии книги, сохранении, изменении ячейки

То есть сила VBA — в том, что он очень близок к экранам, отчётам и структуре книг Excel и Access. Пользователь открывает десктопный Office, нажимает кнопку, обрабатывает данные из локальных файлов или общих папок и тут же получает отчёт. Для такой «автоматизации, полностью завершающейся на рабочем месте пользователя», у него до сих пор есть реальные сильные стороны.¹

И наоборот, изначальная сфера применения VBA никогда не включала серверы, браузеры, мобильные устройства или многопользовательские веб-системы.

3. Почему VBA до сих пор используется

Причина, по которой VBA до сих пор держится на местах, — не просто «остался по инерции, потому что старый».

Во-первых, в Excel и Access легко проникает не просто данные, а сама рабочая процедура.

• Внешний вид отчётов
• Настройки печати
• Проверка ввода
• Порядок ежемесячной обработки
• Исключения по подразделениям
• Порядок действий, к которому на местах привыкли годами

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

Кроме того, поскольку VBA близок к объектной модели Office, для операций «управлять Excel прямо перед пользователем и вернуть результат» требуется очень мало усилий. Эта близость важна и при рассмотрении кандидатов на замену — простого переписывания на новую технологию не всегда достаточно, чтобы закрыть задачу.

На практике естественно рассуждать так.

• Если Excel останется интерфейсом, часть VBA имеет смысл сохранить
• Если Excel нужен только как ввод-вывод, внутреннюю логику легко вынести наружу
• Если сам Excel уже не выполняет функцию полноценного интерфейса, он становится кандидатом на полную переработку

4. Основные ограничения VBA

4.1 Он рассчитан на десктоп

Это самое большое ограничение. VBA — технология, которая по своей сути работает внутри десктопной версии Office.

Согласно официальной информации Microsoft, в Excel для веба нельзя создавать, выполнять и редактировать VBA; книгу с макросами можно открыть и отредактировать, но выполнить VBA нельзя.²⁸

Уже на этом этапе он плохо сочетается с такими требованиями:

• всё должно завершаться в браузере
• одно и то же расширение должно работать на Mac / iPad / в вебе
• администратор должен распространять его централизованно
• нет зависимости от локального десктопного приложения Excel

Сама Microsoft в документации по VBA указывает, что для создания расширений под несколько платформ стоит смотреть на Office Add-ins.⁹⁵

4.2 Большое трение в вопросах безопасности и распространения

Значительная часть недопонимания «VBA больше нельзя использовать» на самом деле связана с усилением безопасности.

Microsoft теперь по умолчанию блокирует макросы VBA в файлах, полученных из интернета. Открытие вложения из письма или скачанного .xlsm больше не приводит к простому выполнению макросов, как раньше.³

С точки зрения безопасности это верное направление. Но со стороны эксплуатации растёт трение:

• при распространении через вложение макрос не работает
• шаблон, скачанный со стороннего сайта, не работает
• работа через OneDrive / SharePoint / сеть трудна для понимания
• подсказка «включите макросы» становится слабым местом эксплуатации

То есть проблемы VBA возникают не только в «возможностях языка», но и в проектировании распространения и доверия.

4.3 Барьер 32-бит / 64-бит

Office выпускается в 32-битной и 64-битной редакциях, и в Office 2019 и Microsoft 365 по умолчанию используется 64-бит.⁷

Из-за этого старый код VBA — особенно код, вызывающий Windows API через Declare, — может не работать как есть в 64-битной среде. Microsoft рекомендует сглаживать различия между 32-бит и 64-бит с помощью PtrSafe, LongPtr, LongLong и подобных средств.⁷

Болезненно здесь то, что помимо самого кода в проблему часто вовлекаются и такие зависимости:

• старые COM / ActiveX / OCX
• внешние DLL, рассчитанные на 32-бит
• компоненты, требующие регистрации в реестре
• расхождения в настройках ссылок Office

То есть миграция VBA очень часто оказывается не столько переписыванием языка, сколько распутыванием разрядности Office и внешних зависимостей.

4.4 Плохо подходит для безнадзорного и серверного выполнения

Этот пункт весьма важен. Microsoft прямо заявляет, что не рекомендует и не поддерживает серверную автоматизацию приложений Office. Office спроектирован в расчёте на интерактивный десктоп и профиль пользователя, и в безнадзорной среде возможны нестабильность и взаимные блокировки (deadlock).⁶

Поэтому такие конфигурации склонны к риску:

• запуск Excel из службы Windows
• автоматизация Office из ASP.NET или DCOM
• бесконечная работа невидимого Excel под управлением планировщика задач
• полное делегирование генерации отчётов серверному Excel

Иногда это «работает». Но работать и быть поддерживаемой конфигурацией — разные вещи.

Если требуется безнадзорное выполнение, первым подозреваемым должен быть не VBA, а сама конфигурация, управляющая приложением Excel.

4.5 Легко проигрывает в сопровождаемости, тестируемости и управлении изменениями

Код VBA легко оказывается запертым внутри книг и файлов Access. В результате легко возникают такие проблемы:

• становится неясно, какой файл является эталонным
• ответственность разбросана по формам, листам и стандартным модулям
• настройки ссылок и зависимости от ActiveX расходятся между окружениями
• код-ревью и просмотр различий затруднены
• сложно писать модульные тесты
• адреса ячеек Excel сами превращаются в спецификацию

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

4.6 Если есть зависимость от VBScript, нужна отдельная осторожность

В 2025 году в Microsoft 365 Developer Blog было объявлено, что поэтапный вывод VBScript из эксплуатации в Windows может затронуть и проекты на VBA. В частности, в зону влияния попадают случаи, когда выполняются внешние .vbs и когда есть зависимость от ссылки на VBScript.RegExp.¹⁰

При этом Microsoft также реагирует на ситуацию, включая класс RegExp в VBA по умолчанию, начиная с Office для Windows версии Microsoft 365 2508 (сборка 19127.20154).¹⁰

Здесь важно понимать: вывод VBScript из эксплуатации и прекращение существования VBA — это не одна и та же история. Точнее говорить не о том, что сам VBA исчезает, а о том, что часть внешних зависимостей, висящих на VBA, требует пересмотра.

5. Перестанет ли VBA работать в будущем

Прежде всего, речь не идёт о том, что «завтра всё перестанет работать». Но и не об эпохе, когда «можно использовать где угодно и для чего угодно».

По меньшей мере, если читать официальную информацию Microsoft, отчётливо просматривается такое направление.

• VBA как средство расширения десктопного Office продолжает существовать¹
• на стороне веба / кросс-платформенных сценариев используются по обстоятельствам Office Scripts и Office Add-ins⁴⁵⁹
• к безопасности распространения макросов теперь относятся строже, чем раньше³
• периферийные компоненты вроде зависимости от VBScript могут в будущем оказаться затронутыми¹⁰

Более того, Microsoft прямо заявляет об Office Scripts, что VBA ориентирован на десктоп, а Office Scripts предназначен для безопасных, кросс-платформенных облачных решений. При этом также поясняется, что на данный момент охват функций Excel, доступных в десктопном клиенте, у VBA шире.⁴

Если сопоставить эти два тезиса, получается вполне практичная картина.

• Для глубокой работы с десктопным Excel сфера применения VBA всё ещё шире
• Для браузера / M365 / совместных рабочих процессов более естественны Office Scripts и Add-ins
• Поэтому верен ответ не «просто перевести всё на Office Scripts», и не «навсегда держать VBA в центре»

Будущее VBA естественнее рассматривать как прояснение границ, а не исчезновение.

6. Случаи, когда стоит заменить / когда заменять не нужно

Сначала приведём грубую, но полезную таблицу решений.

Важно в этой таблице то, что ось решения — не «VBA устарел». На самом деле важно смотреть на среду выполнения, эксплуатацию, распространение, зависимости, аудит и расширяемость.

7. Реалистичные направления замены

7.1 Оставить Excel, а внутреннюю часть вынести в .NET или отдельный процесс

Самый реалистичный и наименее рискованный вариант — именно этот.

• Excel / Access остаётся точкой входа для экранов и отчётов
• Кнопки и формы ввода тоже пока остаются как есть
• Но бизнес-логика, HTTP, криптография, CSV / JSON, тяжёлые вычисления и обработка файлов выносятся наружу
• VBA сужается до роли «моста» и «управления интерфейсом»

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

Смежная статья:

• Как типизированно использовать DLL .NET 8 из VBA — публикация COM + генерация TLB с помощью dscom

Подход «прежде чем всё переписывать, для начала вынести только тяжёлые части» весьма практичен.

7.2 Для безнадзорного выполнения и генерации отчётов — прямая генерация файлов, а не автоматизация приложения Office

Если требуется массово генерировать отчёты Excel в ночных пакетных заданиях или службах, первым подозреваемым должен быть не вопрос «не устарел ли VBA», а сам факт запуска приложения Excel.

Microsoft не рекомендует серверную автоматизацию Office. Вместо этого она рекомендует работать с файлами Office напрямую, используя такие форматы, как Open XML.⁶

То есть если требования выглядят так:

• нужно создавать .xlsx
• нужно массово выпускать типовые отчёты
• нужно конвертировать в PDF
• нужно выполнять в ночном пакетном задании

то выбирать следует не по оси «управлять ли Excel», а по оси «собирать ли файл Excel».

Смежная статья:

• Как построить вывод отчётов Excel — таблица решений: автоматизация COM / Open XML / шаблонный подход

7.3 Для бизнес-процессов в Microsoft 365 — Office Scripts + Power Automate

Если бизнес уже во многом опирается на OneDrive / SharePoint / Teams / Outlook / Forms, Office Scripts вполне серьёзный кандидат.

Microsoft описывает Office Scripts как решение для безопасных, кросс-платформенных облачных сценариев. В сочетании с Power Automate обработку Excel можно автоматизировать, используя в качестве триггера письма, формы или расписание.⁴¹¹

Тем не менее, это тоже не универсальное решение.

• Office Scripts не поддерживает события уровня Excel
• Выполнение в основном происходит через ручной запуск или вызов из Power Automate⁴
• Для интеграции с Power Automate требуется бизнес-лицензия Microsoft 365¹¹
• У действия Run script есть ограничения — например, 1600 вызовов на пользователя в день и 120 секунд на синхронную обработку¹²

То есть точнее рассматривать Office Scripts не как «замену VBA», а как компонент автоматизации в рамках M365.

7.4 Если нужно кросс-платформенное расширение — Office Add-ins

Если нужно расширить Word, Excel, Outlook и подобные приложения на Windows / Mac / iPad / в браузере, первый кандидат — Office Add-ins.

В официальной документации Microsoft поясняется, что Office Add-ins можно создавать на HTML / CSS / JavaScript, они работают на нескольких платформах и подходят для централизованного распространения.⁵

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

• связать Office с внутренним порталом или основной системой
• вывести один и тот же UI и команды в Outlook / Excel / Word
• распространять централизованно, а не через раздачу макросов по компьютерам пользователей
• отказаться от модели распространения локальных .xlsm

Это иная площадка по сравнению с VBA, поэтому ощущается совсем не так, как написание кода внутри Excel. Взамен эксплуатацию и распространение становится гораздо легче держать в порядке.

7.5 Если Excel / Access уже перестал по сути быть интерфейсом — вынести в Windows-приложение или веб-приложение

Если дошло до такого состояния, продлевать жизнь VBA менее естественно, чем пересобрать всё как полноценное приложение.

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

В этом случае для инструмента, ориентированного на Windows, естественнее структура десктопного приложения на C# / .NET, а если круг пользователей или устройств широк — веб-приложения.

8. Как проводить поэтапную миграцию

Самое опасное при замене VBA — пытаться сразу свести всё к одной новой технологии. На практике безопаснее в целом двигаться в порядке, изложенном ниже.

8.1 Сначала составить реестр активов

В первую очередь стоит выявить не сам объём кода, а зависимости.

• какие есть .xlsm / .xlam / .accdb / .mdb
• какие из них являются точкой входа в реальную эксплуатацию
• что указано в настройках ссылок
• какие есть Declare, внешние DLL, COM / ActiveX / OCX
• каковы предположения о 32-бит / 64-бит
• какие макросы используются кем и в каком порядке
• что является результатом (Excel, CSV, PDF, печать, отправка почты и т. д.)

Если провести замену, оставив это неясным, позже возникнут инциденты вроде «макрос, которым, как считалось, никто не пользуется, оказался живым только в конце месяца».

8.2 Разделить код по зонам ответственности

Следующий шаг — разделение не по файлам, а по зонам ответственности.

• работа с UI Excel / Access
• ввод-вывод листов
• макет отчётов
• бизнес-правила
• ввод-вывод через внешние API / файлы / БД
• пакетная обработка
• печать / распространение

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

8.3 Определить направление миграции для каждой зоны ответственности

Разделение, которое легко рекомендовать, выглядит так.

• UI и работа с листами: пока оставить в VBA
• Бизнес-логика: вынести в DLL на .NET, отдельный процесс или службу
• Безнадзорная генерация отчётов: перейти на Open XML или прямую генерацию
• Рабочие процессы M365: Office Scripts + Power Automate
• Кросс-платформенный UI: Office Add-ins
• Области, превратившиеся в бизнес-систему: выделить в Windows- / веб-приложение

Важно не сводить направление миграции к одному варианту. Содержимое VBA-активов почти всегда представляет собой смесь нескольких зон ответственности.

8.4 Сначала зафиксировать интерфейсы

Перед началом миграции стоит как минимум решить следующее.

• что является входом
• что является выходом
• как сообщается об ошибке
• какие листы, именованные диапазоны, пути к файлам образуют контракт
• в какой момент результат считается окончательным

Если продвигаться, не решив этого, сами адреса ячеек превращаются в API, и всё легко ломается.

8.5 Сравнивать при параллельной эксплуатации

Особенно для отчётов и агрегированных данных безопаснее не переключаться резко.

• выводить результат старой версии на VBA и новой реализации параллельно
• сравнивать полученные .xlsx / CSV / PDF
• проверять расхождения в датах, округлении, форматировании, областях печати
• также тестировать исключительные ситуации и случаи с пустыми данными

Инциденты при замене VBA чаще всего проявляются не как «работает или нет», а как тихое расхождение чисел и форматирования.

9. Частые ошибки

9.1 Начинать с «VBA устарел, значит всё в Office Scripts»

Office Scripts — сильный вариант, но сама Microsoft поясняет, что у VBA шире охват функций десктопного Excel. Более того, Office Scripts не поддерживает события уровня Excel.⁴

Поэтому идея прямого переноса макросов с глубокой зависимостью от десктопного Excel «как есть» рискованна.

9.2 Продолжать запускать сам Excel при безнадзорном выполнении

Это встречается очень часто. Пока это работает, выглядит удобно, но Microsoft не рекомендует серверную автоматизацию Office.⁶

Для ночных пакетных заданий и служб безопаснее склоняться к сборке файлов Excel, а не к управлению Excel.

9.3 Менять экраны, отчёты и бизнес-правила все сразу

По-настоящему пугает при замене VBA не сама конвертация кода, а утеря части спецификации бизнес-процесса. В листах Excel и формах Access скрыто немало правил эксплуатации, которые нигде не записаны в коде.

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

9.4 Откладывать вопросы 32-бит / 64-бит и внешних ссылок на потом

В проектах миграции первым обычно взрывается не сам код VBA, а:

• Declare
• внешние DLL
• COM / ActiveX / OCX
• разрядность Office
• настройки ссылок

Если отодвинуть это на потом, в финальной фазе реализации становится резко тяжело.⁷

9.5 Путать историю VBScript и историю VBA

С точки зрения VBA поэтапный вывод VBScript из эксплуатации — это вопрос пересмотра части зависимостей. Это не означает завершения работы VBA в целом.¹⁰

Если это смешать, легко начинает жить своей жизнью небрежный внутренний слух вроде «похоже, VBA заканчивается».

10. Итог

Одной фразой VBA можно описать как язык расширения, тесно привязанный к десктопным приложениям Office. Для автоматизации работы прямо на месте пользователя, рядом с Excel и Access, он и сегодня остаётся весьма практичным.¹

Но в дальнейшей практике важно не рассматривать VBA как универсальную центральную технологию.

• Если нужен браузер / кросс-платформенность, стоит смотреть на Office Scripts и Office Add-ins⁴⁵
• Для безнадзорной / серверной обработки стоит избегать автоматизации Office⁶
• Тяжёлую логику и внешние интеграции нужно выносить в .NET или отдельный процесс
• Если Excel / Access уже с трудом справляется с ролью интерфейса, стоит выносить в Windows- или веб-приложение

Ответ — не «заменить всё» и не «не менять ничего», а «разделить по зонам ответственности и постепенно облегчать».

При беглом взгляде VBA-активы выглядят устаревшими. Но на практике в них плотно упакованы спецификация бизнес-процесса, порядок эксплуатации, дизайн отчётов и наработанные привычки на местах.

Именно поэтому замену безопаснее вести не как перевод, а как упорядочивание.

11. Смежные статьи

• Что такое COM / ActiveX / OCX — объясняем различия и связь
• Как типизированно использовать DLL .NET 8 из VBA — публикация COM + генерация TLB с помощью dscom
• Как построить вывод отчётов Excel — таблица решений: автоматизация COM / Open XML / шаблонный подход

12. Источники

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

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

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

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

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

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

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

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

Перестанет ли VBA работать в будущем?

По меньшей мере по состоянию на март 2026 года в официальной информации Microsoft не подтверждается чёткого объявления о том, что «сам VBA будет прекращён в ближайшее время». Происходящее сейчас — не внезапная полная отмена, а прояснение того, где и при каких условиях VBA можно использовать. Конкретно: в Excel для веба нельзя создавать, выполнять и редактировать VBA, а макросы в файлах из интернета по умолчанию блокируются. Будущее VBA естественнее рассматривать как прояснение границ, а не как исчезновение.

Стоит ли переносить весь VBA в Office Scripts?

Не рекомендуется. Сама Microsoft объясняет, что на данный момент охват функций Excel, доступных в десктопном клиенте, у VBA шире, а Office Scripts не поддерживает события уровня Excel. Точнее рассматривать Office Scripts не как замену VBA, а как компонент автоматизации в рамках M365, работающий с книгами в OneDrive или SharePoint в связке с Power Automate. Реалистичнее выбирать направление миграции отдельно для каждой зоны ответственности.

Можно ли безнадзорно запускать макросы Excel на сервере или в ночном пакетном задании?

Это рискованно. Microsoft прямо заявляет, что не рекомендует и не поддерживает серверную автоматизацию приложений Office. Office спроектирован в расчёте на интерактивный десктоп и профиль пользователя, и в безнадзорной среде возможны нестабильность и взаимные блокировки (deadlock). Если требуется массовая генерация отчётов, рекомендуется не запускать приложение Excel, а собирать файлы Excel напрямую, например в формате Open XML.

Как правильно мигрировать существующие VBA-активы?

Безопаснее не сводить всё сразу к одной новой технологии, а мигрировать поэтапно. Сначала составляется реестр активов: .xlsm, настройки ссылок, внешние DLL, предположения о 32-бит/64-бит. Затем код разделяется по зонам ответственности: работа с UI, бизнес-логика, отчёты, ввод-вывод. После этого UI и работу с листами пока оставляют в VBA, бизнес-логику переносят в DLL на .NET или отдельный процесс, безнадзорную генерацию отчётов — в Open XML, а рабочие процессы M365 — в Office Scripts, определяя направление миграции для каждой зоны ответственности отдельно. Для отчётов и агрегированных данных старую и новую версии запускают параллельно и сравнивают результаты, прежде чем переключаться.

Об авторе

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

Го Комура

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

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