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

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

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

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

flowchart TB
    accTitle: Оси, с которых начинают решение по VBA
    accDescr: Решение оставить VBA или заменить его определяется не новизной, а тем, где выполняется код, кто им пользуется, является ли сам Excel или Access интерфейсом и нужно ли выполнение без участия пользователя.
    a0["Новизна или старость"] -.-> a1["Не первая ось решения"]
    b0["С чего начинать"] --> b1["Где выполняется"]
    b0 --> b2["Кто пользуется"]
    b1 --> b3["Excel / Access сам является UI"]
    b2 --> b4["Нужно ли выполнение без участия пользователя"]

Рис. 1: Ось решения по VBA — не новизна, а место выполнения, пользователь, UI и неинтерактивный запуск.

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

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

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

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

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

flowchart TB
    accTitle: Как читать текущие изменения
    accDescr: Происходит не внезапная полная отмена, а прояснение мест и условий использования. Вопрос не в том, отказаться ли от VBA целиком, а в том, какие области оставить в VBA, а какие вынести наружу.
    c1["Внезапная полная отмена"] -.-> c2["В официальных материалах не подтверждается"]
    d1["Прояснение мест и условий использования"] --> d2["Меняется сам вопрос"]
    d2 --> d3["Какие области оставить в VBA"]
    d2 --> d4["Какие области вынести наружу"]

Рис. 2: Вопрос не «отказаться ли от всего», а как разделить области, которые остаются, и области, которые выносят.

Карта знаний этой статьи

VBA — событийный язык, который работает внутри классических приложений Office: в Excel for the web его нельзя ни создать, ни выполнить, ни править, а макросы в файлах из интернета по умолчанию блокируются. Эту блокировку можно точечно обойти механизмами вроде надежных расположений, надежных сайтов, надежных издателей и сертификата подписи кода. VBA не подходит для автоматизации Office на стороне сервера: Microsoft для безлюдной генерации бланков рекомендует прямую генерацию в формате Open XML. Старые операторы Declare на 64-битном Office иногда не работают, а запуск внешних .vbs и зависимость от VBScript.RegExp могут попасть под поэтапный отказ от VBScript. Замена не одна: тяжёлую бизнес-логику относят в .NET DLL, кроссплатформенные расширения — в Office Add-ins, рабочие процессы на M365 — в Office Scripts и Power Automate; реалистично делить по зонам ответственности.

flowchart LR
    accTitle: Карта знаний ограничений VBA и вариантов замены
    accDescr: Схема, которая показывает, что VBA — язык расширений, замкнутый внутри классического Office; несовместимость с Excel for the web; блокировку макросов по умолчанию и обход через надежные расположения, надежные сайты и надежных издателей; нерекомендуемость автоматизации на стороне сервера и альтернативу Open XML; ограничения вроде разрядности и зависимости от VBScript; и направления замены по зонам ответственности — Office Scripts, Office Add-ins и .NET
    vba["VBA (Visual Basic for Applications)"]
    excel_for_the_web["Excel for the web"]
    macro_block_policy["блокировка интернет-макросов по умолчанию"]
    zone_identifier["Zone.Identifier (Mark of the Web)"]
    trusted_location["надёжные расположения (Trusted Location)"]
    trusted_site_zone["зона «Надёжные узлы» / «Местная интрасеть»"]
    trusted_publisher_store["хранилище «Доверенные издатели»"]
    code_signing_cert["сертификат подписи кода"]
    server_side_office_automation["серверная автоматизация Office"]
    open_xml_format["формат Open XML"]
    unattended_report_generation["генерация отчётов без оператора"]
    bitness_match_requirement["требование совпадения разрядности"]
    vba_64bit_migration["поддержка 64-bit в VBA (PtrSafe/LongPtr)"]
    com["COM (Component Object Model)"]
    activex["ActiveX"]
    ocx["OCX"]
    cross_platform_office_extension["кроссплатформенное расширение Office"]
    office_addins["Office Add-ins"]
    m365_cloud_workflow["облачный поток на Microsoft 365"]
    office_scripts["Office Scripts"]
    power_automate["Power Automate"]
    vbscript_regexp_dependency["зависимость от VBScript.RegExp и внешних .vbs"]
    vbscript_deprecation["поэтапный вывод VBScript"]
    dotnet[".NET (начиная с Core)"]
    vba -->|"несовместимо с"| excel_for_the_web
    macro_block_policy -.->|"предотвращает"| vba
    zone_identifier -->|"может вызвать"| macro_block_policy
    vba -->|"настраивается"| trusted_location
    vba -->|"настраивается"| trusted_site_zone
    vba -->|"настраивается"| trusted_publisher_store
    trusted_publisher_store -->|"требует"| code_signing_cert
    vba -->|"не рекомендуется"| server_side_office_automation
    open_xml_format -->|"рекомендуется для"| unattended_report_generation
    server_side_office_automation -->|"не рекомендуется"| unattended_report_generation
    vba -.->|"требует"| bitness_match_requirement
    vba -.->|"требует"| vba_64bit_migration
    vba -.->|"использует"| com
    vba -.->|"использует"| activex
    vba -.->|"использует"| ocx
    vba -->|"несовместимо с"| cross_platform_office_extension
    office_addins -->|"рекомендуется для"| cross_platform_office_extension
    vba -->|"не рекомендуется"| m365_cloud_workflow
    office_scripts -->|"рекомендуется для"| m365_cloud_workflow
    power_automate -.->|"использует"| office_scripts
    vba -.->|"требует"| vbscript_regexp_dependency
    vbscript_regexp_dependency -.->|"несовместимо с"| vbscript_deprecation
    dotnet -->|"рекомендуется для"| vba

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 23, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое VBA

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

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

flowchart TB
    accTitle: Как правильно смотреть на VBA
    accDescr: VBA ближе к реальности рассматривать не как универсальную платформу разработки, а как событийно-управляемый язык расширения, который встраивают внутрь приложений Office.
    v1["VBA"] --> j1{"Как смотреть"}
    j1 -.->|"Далеко от практики"| a1["Универсальная платформа разработки"]
    j1 -->|"Ближе к практике"| a2["Язык расширения внутри приложений Office"]
    a2 --> a3["Событийно-управляемый язык внутри Office"]

Рис. 3: VBA — не универсальная платформа, а язык расширения внутри Office.

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

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

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

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

' Стандартный модуль Excel. Предполагается вызов с кнопки на листе
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("Детали")

    If MsgBox("Будут очищены строки со 2-й и ниже на листе «Детали». Продолжить?", _
              vbOKCancel + vbQuestion, "Подтверждение") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

На лист ставят фигуру или кнопку элемента управления формы, через «Назначить макрос» в контекстном меню выбирают этот ClearMeisai — и при каждом нажатии выполняется эта процедура. Здесь важно увидеть, что объекты Excel вроде ThisWorkbook, Worksheets, Rows появляются как есть, без преобразования и без вызова API. «Язык, который работает внутри Office» на практике и есть эта близость. На замене, где этой близости нет, тем же числом шагов такой код не напишешь.

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

flowchart TB
    accTitle: Область применения VBA
    accDescr: VBA близок к экранам, отчётам и структуре книг Excel и Access и до сих пор силён в автоматизации на машине пользователя, но серверы, браузеры, мобильные устройства и многоарендаторные веб-системы изначально вне его области.
    s1["Объекты Excel доступны напрямую"] --> s2["Автоматизация на машине пользователя"]
    s2 --> s3["Область, где VBA силён и сейчас"]
    t1["Сервер / браузер / мобильные / веб-система"] -.-> t2["Изначально вне области применения"]

Рис. 4: Близость к Office — сила VBA; там, где эта близость не нужна, область применения заканчивается с самого начала.

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

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

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

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

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

flowchart TB
    accTitle: Что несут VBA-наработки
    accDescr: В Excel и Access легко оказываются внешний вид отчётов, печать, проверка ввода, порядок обработки, исключения и привычный порядок действий. Внешний вид, операции, исключения и эксплуатация слиты, поэтому одним переносом кода миграция не заканчивается.
    e1["Наработки Excel / Access"] --> e2["В них сидит сама рабочая процедура"]
    e2 --> f1["Внешний вид отчётов и печать"]
    e2 --> f2["Проверка ввода и порядок обработки"]
    e2 --> f3["Исключения и порядок действий"]
    f2 --> g1["Одним переносом кода не обойтись"]

Рис. 5: VBA-наработки несут не только код, а рабочую процедуру и эксплуатацию целиком.

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

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

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

flowchart TB
    accTitle: Смотреть на роль Excel как UI
    accDescr: Если Excel останется интерфейсом, часть VBA стоит сохранить; если Excel нужен только как ввод-вывод, логику легко вынести; если Excel уже не является настоящим UI, это кандидат на переработку.
    q1{"Какова роль Excel"}
    q1 -->|"Остаётся UI"| r1["Имеет смысл оставить часть VBA"]
    q1 -->|"Только ввод-вывод"| r2["Логику легко вынести наружу"]
    q1 -->|"Уже не настоящий UI"| r3["Кандидат на переработку"]

Рис. 6: От того, является ли Excel интерфейсом, зависят решения оставить, вынести или переписать.

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

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

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

В официальных материалах Microsoft указано, что в Excel for the web нельзя создавать, выполнять и править VBA; книгу с макросами можно открыть и править, но выполнить VBA нельзя.²⁸

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

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

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

flowchart TB
    accTitle: Ограничение «только десктоп»
    accDescr: VBA работает внутри десктопного Office. В Excel for the web его нельзя создавать, выполнять и править, поэтому он плохо стыкуется с браузером и кросс-платформенными требованиями; для нескольких платформ указывают Office Add-ins.
    h1["VBA"] --> h2["Работает внутри десктопного Office"]
    h2 --> h3["В Excel for the web нельзя создавать, выполнять и править"]
    h3 --> h4["Плохо стыкуется с браузером и централизованной раздачей"]
    h4 -.-> h5["Для нескольких платформ смотреть Office Add-ins"]

Рис. 7: Самое большое ограничение — расчёт на десктоп.

4.2 Много трения в безопасности и распространении

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

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

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

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

flowchart TB
    accTitle: Трение из-за блокировки макросов по умолчанию
    accDescr: Макросы VBA в файлах из интернета по умолчанию блокируются, поэтому вложения и скачанные файлы уже не выполняются как раньше, и трение при распространении и эксплуатации растёт.
    m1["Файл из интернета"] --> m2["Макросы VBA блокируются по умолчанию"]
    m2 --> m3["Вложение или загрузка уже не работают просто"]
    m3 --> m4["Растёт трение при раздаче и эксплуатации"]
    m2 -.-> m5["Для безопасности это верное направление"]

Рис. 8: Ощущение «больше нельзя использовать» во многом даёт блокировка макросов по умолчанию.

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

Одновременно прямо названы и ограничения.³

• Надёжные расположения и надёжные узлы означают доверие ко всему, что туда положили. Место должно быть таким, где вы контролируете, кто может писать.
• Надёжные издатели — это настройка Windows в целом, а не только Office.
• Надстройки Excel (.xla / .xlam) не заработают, даже если подписать их и доверить издателя, пока на файле висит Mark of the Web. Нужно либо снять метку, либо положить файл в надёжное расположение.
• Если сетевую папку открывают по IP-адресу, она может не попасть ни в надёжные узлы, ни в местную интрасеть и остаться заблокированной.

Иначе говоря, если VBA оставляете, отдельно от кода нужно спроектировать распространение: куда класть файлы и как им доверять. Раздавать .xlsm вложением в письма, не решив этого, — самый трущийся вариант.

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

flowchart TB
    accTitle: Если VBA оставляете, нужно спроектировать и раздачу
    accDescr: Решение оставить VBA требует отдельно от кода решить, куда класть файлы и как им доверять. Продолжать раздавать .xlsm вложением, не решив этого, даёт наибольшее трение.
    p1["Решение оставить VBA"] --> p2["Разговор про код"]
    p1 --> p3["Разговор про раздачу"]
    p3 --> p4["Куда класть"]
    p3 --> p5["Как доверять"]
    p4 -.-> p6["Раздача .xlsm вложением без решения = наибольшее трение"]

Рис. 9: Если оставляете VBA, отдельно от кода спроектируйте место хранения и способ доверия.

4.3 Барьер 32-bit / 64-bit

Office бывает 32-bit и 64-bit, и в Office 2019 и Microsoft 365 по умолчанию стоит 64-bit.⁷

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

Болезненно здесь то, что вместе с кодом часто всплывают и такие зависимости:

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

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

flowchart TB
    accTitle: Барьер 32-bit / 64-bit
    accDescr: В Office 2019 и Microsoft 365 по умолчанию 64-bit, поэтому старые вызовы Windows API через Declare часто требуют PtrSafe и LongPtr. Вместе с этим всплывают старые COM и ActiveX, 32-bit DLL и расхождения ссылок, так что миграция больше про зависимости, чем про переписывание языка.
    b1["Office 2019 / M365 по умолчанию 64-bit"] --> b2["Старые вызовы Declare могут не работать как есть"]
    b2 --> b3["Разницу сглаживают PtrSafe и LongPtr"]
    b2 -.-> b4["Вместе всплывают COM / ActiveX / OCX и 32-bit DLL"]
    b4 --> b5["По сути это разбор разрядности и внешних зависимостей"]

Рис. 10: При переходе на 64-bit чаще сначала ломаются внешние зависимости, а не сам код.

4.4 Плохо подходит для запуска без участия пользователя и для сервера

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

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

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

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

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

flowchart TB
    accTitle: Почему VBA плохо подходит для сервера и запуска без пользователя
    accDescr: Office рассчитан на интерактивный рабочий стол и профиль пользователя. Серверная автоматизация не рекомендуется и не поддерживается; в неинтерактивной среде возможны нестабильность и deadlock. Подозревать нужно не VBA, а схему, которая гоняет само приложение Excel.
    u1["Схема, где Excel запускает служба или пакетное задание"] --> u2["Office рассчитан на интерактивный рабочий стол"]
    u2 --> u3["В неинтерактивной среде возможны нестабильность и deadlock"]
    u3 --> u4["Серверная автоматизация вне поддержки"]
    u4 -.-> u5["Подозревать нужно схему запуска Excel, а не VBA"]

Рис. 11: «Иногда работает» и «эту схему можно поддерживать» — разные вещи; при запуске без пользователя сомневайтесь в самой схеме.

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

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

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

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

flowchart TB
    accTitle: Проблема структуры «логика внутри файла Office»
    accDescr: Код VBA легко запирается внутри книг и файлов Access: эталон становится неясным, ответственность разъезжается, различия и тесты делать трудно. В небольшой автоматизации это мало заметно, но при превращении в бизнес-систему резко проявляется.
    k1["Код запирается внутри файла Office"] --> k2["Эталон неясен, ответственность разъезжается"]
    k1 --> k3["Трудно смотреть различия и писать тесты"]
    k2 --> k4["В небольшой автоматизации мало заметно"]
    k3 --> k4
    k4 --> k5["При превращении в бизнес-систему резко проявляется"]

Рис. 12: Проблему создаёт не язык, а структура «бизнес-логика внутри файла».

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

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

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

Повлияет ли это на ваши наработки, можно понять, поискав три вещи. Подойдёт и поиск в меню «Правка» редактора VBE, и grep по тексту, выгруженному в .bas / .cls.

Список ссылок смотрят в VBE: меню «Сервис» → «Ссылки».

По RegExp, как сказано выше, начиная с Microsoft 365 Version 2508 (сборка 19127.20154) класс RegExp в Windows-версии Office включают в VBA по умолчанию.¹⁰ Тяжелее третья строка — «запуск внешнего .vbs»: саму обработку придётся переносить либо в VBA, либо на другую среду выполнения. Когда будете составлять реестр наработок (раздел 8.1), эти три пункта лучше сразу туда записать, чтобы не искать дважды.

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

flowchart TB
    accTitle: Связь вывода VBScript и VBA
    accDescr: Поэтапный вывод VBScript в Windows может затронуть запуск внешних .vbs и зависимость от VBScript.RegExp. Для RegExp в новом Office класс уже включают в VBA по умолчанию. Это не снятие VBA целиком.
    w1["Поэтапный вывод VBScript"] --> w2["Зависимость от запуска внешних .vbs"]
    w1 --> w3["Зависимость от VBScript.RegExp"]
    w2 --> w4["Смотреть перенос на другую среду выполнения"]
    w3 -.-> w5["В новом Office класс уже в VBA по умолчанию"]
    w1 -.-> w6["Это не снятие VBA целиком"]

Рис. 13: Затрагиваются только зависимости, висящие на VBScript, а не сам 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 естественнее рассматривать как прояснение границ, а не исчезновение.

flowchart TB
    accTitle: Не исчезновение, а прояснение границ
    accDescr: В глубокой работе с десктопным Excel область VBA всё ещё шире, а в браузере, M365 и совместных процессах естественнее Office Scripts и Add-ins. Это не сдвиг всего в одну сторону, а прояснение границ.
    z1{"Где использовать"}
    z1 -->|"Глубокая работа с десктопным Excel"| z2["Область VBA всё ещё шире"]
    z1 -->|"Браузер / M365 / совместные процессы"| z3["Естественнее Office Scripts и Add-ins"]
    z2 --> z4["Прояснение границ"]
    z3 --> z4

Рис. 14: Ни «всё в Office Scripts», ни «VBA навсегда в центре» — границы постепенно фиксируются.

6. Когда стоит заменить / когда заменять не нужно

Сначала грубая, но полезная таблица решений.

Гибридная модель во второй строке в этой статье означает: оставить Excel / Access входом для UI и отчётов, а бизнес-логику и ввод-вывод вынести во внешнюю единицу выполнения. От полной замены это отличается тем, что экран и порядок действий, которые видит пользователь, не меняют. Конкретную форму разберём в 7.1.

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

flowchart TB
    accTitle: Оси решения о замене
    accDescr: Ось решения — не «VBA устарел», а среда выполнения, эксплуатация, распространение, зависимости, аудит и расширяемость. В гибридной модели экран и порядок действий пользователя не меняют, наружу выносят только логику и ввод-вывод.
    j0["VBA устарел"] -.-> j1["Не ось решения"]
    j2["На что смотреть"] --> j3["Среда выполнения, эксплуатация, распространение"]
    j2 --> j4["Зависимости, аудит, расширяемость"]
    j3 --> j5["Оставить / гибрид / вынести"]
    j4 --> j5

Рис. 15: Ось решения — не старость, а среда выполнения, эксплуатация, распространение, зависимости, аудит и расширяемость.

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

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

Чаще всего пропускают столбец «предпосылки и лицензии». У Office Scripts условия особенно чёткие, поэтому их отдельно разберём в 7.3.

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

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

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

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

flowchart TB
    accTitle: Гибрид: Excel остаётся, содержимое выносят
    accDescr: Вход для экранов и отчётов оставляют в Excel или Access, бизнес-логику, HTTP, криптографию, тяжёлые вычисления и файлы выносят в .NET или отдельный процесс, а VBA сужают до моста и UI. Внешний вид и порядок действий пользователя не ломают.
    x1["Вход экранов и отчётов остаётся Excel / Access"] --> x2["VBA сужают до моста и UI"]
    x2 --> x3["Тяжёлую логику и ввод-вывод — в .NET или отдельный процесс"]
    x3 -.-> x4["Внешний вид и порядок действий пользователя не ломают"]

Рис. 16: Меньше всего ломается схема, где вход оставляют, а содержимое выносят.

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

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

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

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

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

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

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

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

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

flowchart TB
    accTitle: Генерацию отчётов без пользователя вести прямой сборкой файла
    accDescr: Если отчёты нужно массово собирать ночным заданием или службой, подозревать нужно сам запуск приложения Excel. Серверная автоматизация Office не рекомендуется; рекомендуется собирать файлы напрямую, например в формате Open XML.
    y1["Нужна массовая генерация отчётов без пользователя"] --> y2{"По какой оси думать"}
    y2 -.->|"Не рекомендуется"| y3["Гонять приложение Excel"]
    y2 -->|"Рекомендуемое направление"| y4["Собирать файл напрямую через Open XML и аналоги"]

Рис. 17: При запуске без пользователя выбирают не «гонять 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 — не «бесплатная замена VBA, которая прилагается сама». По сравнению с раздачей локальных .xlsm появляются предпосылки OneDrive / SharePoint и лицензии M365. Если решить «переходим на Office Scripts», не проверив это, посреди миграции придётся вернуться к закупке лицензий.

flowchart TB
    accTitle: Что проверить до перехода на Office Scripts
    accDescr: Office Scripts — не бесплатная замена VBA. По сравнению с раздачей локальных .xlsm появляются OneDrive, SharePoint и лицензия M365. Если это пропустить, посреди миграции придётся вернуться к закупке лицензий.
    o1["Раздача локальных .xlsm"] --> o2["Рассматривают переход на Office Scripts"]
    o2 --> o3["Появляются OneDrive / SharePoint и лицензия M365"]
    o3 -->|"Проверить заранее"| o4["Вшить предпосылки в план миграции"]
    o3 -.->|"Если пропустить"| o5["Посреди пути вернуться к закупке лицензий"]

Рис. 18: Office Scripts — не «бесплатная замена VBA»; сначала проверяют предпосылки.

И по функциям это не универсальное решение.

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

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

flowchart TB
    accTitle: Как запускают Office Scripts
    accDescr: Office Scripts не поддерживает события уровня Excel. Запуск в основном ручной или из Power Automate, плюс есть лимиты по числу вызовов и времени синхронной обработки. Это компонент автоматизации M365, а не замена VBA.
    a1["Office Scripts"] --> a2["Запускают вручную"]
    a1 --> a3["Вызывают из Power Automate"]
    a1 -.-> a4["События уровня Excel не поддерживаются"]
    a2 --> a5["Смотреть как компонент автоматизации M365"]
    a3 --> a5

Рис. 19: Модель запуска другая, чем у событийного 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. Взамен эксплуатацию и распространение становится гораздо легче держать в порядке.

flowchart TB
    accTitle: Когда уместны Office Add-ins
    accDescr: Office Add-ins строят на HTML, CSS и JavaScript. Они работают на Windows, Mac, iPad и в браузере и подходят для централизованной раздачи, поэтому стыкуются с отказом от раздачи макросов по ПК и от локальных .xlsm.
    d1["Строят на HTML / CSS / JavaScript"] --> d2["Работают на Windows / Mac / iPad / в браузере"]
    d2 --> d3["Централизованная раздача администратором"]
    d3 --> d4["Уход от модели раздачи локальных .xlsm"]

Рис. 20: Если нужны кросс-платформенность и централизованная раздача, это уже модель Add-ins.

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

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

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

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

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

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

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

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

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

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

flowchart TB
    accTitle: Что выписывают в реестр
    accDescr: На старте поэтапной миграции важнее зависимости, чем объём кода: какие файлы являются входом, какие ссылки, DLL и разрядность, кто каким макросом пользуется и что он выдаёт. Если оставить это неясным, всплывают макросы, которые живут только в конце месяца.
    r1["Опись файлов"] --> r2["Опись зависимостей (ссылки, DLL, разрядность)"]
    r2 --> r3["Опись использования (кто, в каком порядке, какой выход)"]
    r3 -.-> r4["Иначе инцидент с макросом, который жив только в конце месяца"]

Рис. 21: В реестре смотрят не объём кода, а зависимости и способ использования.

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-наработок почти всегда — смесь нескольких зон ответственности.

flowchart TB
    accTitle: Направление миграции выбирают по зоне ответственности
    accDescr: Если делить код не по файлам, а по зонам ответственности, становится видно, что оставить, что облегчить и что вынести. UI и листы пока оставляют в VBA, бизнес-логику — в .NET, генерацию отчётов без пользователя — в Open XML, процессы M365 — в Office Scripts.
    m1["Делят код по зонам ответственности"] --> m2["Видно, что оставить / облегчить / вынести"]
    m2 --> n1["UI и работу с листами пока оставляют в VBA"]
    m2 --> n2["Бизнес-логику — в .NET или отдельный процесс"]
    n1 --> n3["Генерацию отчётов без пользователя — в Open XML"]
    n2 --> n4["Рабочие процессы M365 — в Office Scripts"]

Рис. 22: Если делить не по файлам, а по зонам ответственности, направлений миграции естественно становится несколько.

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

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

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

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

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

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

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

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

flowchart TB
    accTitle: Сначала сравнить при параллельной работе, потом переключаться
    accDescr: Отчёты и сводки не переключают сразу: старую VBA-версию и новую реализацию выдают параллельно, сравнивают даты, округление, форматы и области печати, прогоняют исключения и пустые данные. Так ловят тихое расхождение чисел и форматов.
    h1["Старую VBA-версию и новую реализацию выдают параллельно"] --> h2["Сравнивают выход (даты, округление, форматы, области печати)"]
    h2 --> h3["Прогоняют исключения и пустые данные"]
    h3 --> h4["Переключаются, убедившись, что расхождений нет"]
    h2 -.-> h5["Инциденты приходят как тихое расхождение чисел и форматов"]

Рис. 23: Не переключаться сразу: сначала параллельно сравнить старый и новый выход.

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 сидит немало правил эксплуатации, которые нигде не записаны в коде.

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

flowchart TB
    accTitle: Что бывает, если менять всё сразу
    accDescr: Страшнее конвертации кода — потеря спецификации. В листах Excel и формах Access сидят незаписанные правила эксплуатации. Если сразу менять экраны, отчёты и бизнес-правила, получается «похоже, но отличается только в конце месяца».
    g1["Экраны, отчёты и бизнес-правила меняют все сразу"] --> g2["Теряют правила эксплуатации, которых нет в коде"]
    g2 --> g3["Инцидент «похоже, но отличается только в конце месяца»"]
    g2 -.-> g4["Страшнее конвертации кода — потеря спецификации"]

Рис. 24: Если менять всё сразу, легко потерять бизнес-спецификацию, которой нет в коде.

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

В проектах миграции первым обычно взрывается не сам код 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- или веб-приложение

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

flowchart TB
    accTitle: Ответ на замену VBA
    accDescr: Ответ — не заменить всё и не оставить всё как есть, а разделить по зонам ответственности и постепенно облегчать. Замену безопаснее вести как упорядочивание, а не как перевод.
    q0{"Что делать с VBA-наработками"}
    q0 -.->|"Крайность"| e1["Заменить всё"]
    q0 -.->|"Крайность"| e2["Ничего не менять"]
    q0 -->|"Практичный ответ"| e3["Разделить по зонам ответственности и постепенно облегчать"]
    e3 --> e4["Вести как упорядочивание, а не как перевод"]

Рис. 25: Ответ не на краях, а в разделении по зонам ответственности и постепенном облегчении.

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

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

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

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

12. Источники

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

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

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

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

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

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

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

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

VBA скоро перестанет работать?

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

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

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

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

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

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

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

Об авторе

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

Го Комура

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

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