把 Excel VBA 宏迁移到 Power Automate ── 用 Office Scripts 替换的范围,与继续保留为 VBA 的范围

· 更新日期: · · Power Automate, VBA, Excel, Office, Office Scripts, 业务自动化, 云端流程, 现有资产利用, 迁移, 技术咨询

“这项业务是用 Excel 宏在跑,但做的人已经不在公司了。能不能迁移到 Power Automate 这种东西上?”——我经常收到这样的咨询。一方面,用 VBA 编写的日常汇总、报表制作至今仍在正常运转;另一方面,因作者离职或 VBScript 弃用的消息,不少负责人对 VBA 资产的未来感到不安。

先把结论说在前面:“把 VBA 迁移到 Power Automate”,准确地说,其实是“把部分 VBA 改写成 Office Scripts 并从 Power Automate 调用”“部分用连接器替换”“部分继续保留为 VBA”这几件事的组合。并不存在能把 VBA 宏原样搬到云端流程中运行的机制。本文将参照 Microsoft Learn 的一手资料,梳理哪些处理可以迁移到哪里,哪些应该继续保留为 VBA。

1. 先说结论

  • 无法从 Power Automate 的云端流程直接运行 VBA 宏。 Excel Online (Business) 连接器可以处理 .xlsm 文件,但无法运行其中的宏,能运行的只有 Office Scripts。1
  • Office Scripts 并不是 VBA 的完全替代品。 它仅限 Excel 使用,无法操作其他 Office 应用,也无法实现事件驱动、UserForm、COM/OLE 联动以及本地文件访问。23
  • 反过来,凡是在工作簿内部就能完结的整理、汇总、转录处理,都很值得转换为 Office Scripts。配合 Power Automate,就能实现按计划启动、或以收到邮件为触发条件的自动执行,从而实现 VBA 做不到的“不打开 Excel 也能运行”的自动化。2
  • 如果只是向表格中添加、获取行这类操作,不写脚本、直接用 Excel Online (Business) 连接器的操作处理即可。不过要先确认必须是表格、默认 256 行、最大 25MB 等限制。4
  • 对于无论如何都需要 VBA 的处理,还有一个选项:用桌面流程的 Run Excel macro 操作直接启动现有的 VBA。可以在不改写 VBA 的前提下,只自动化启动及前后的联动。5
  • Office Scripts 需要商用或教育版的 Microsoft 365 许可证以及 OneDrive for Business。VBA 则无需额外许可证,这一点是迁移判断的前提条件。62

2. 梳理 VBA、Office Scripts、Power Automate 之间的关系

首先梳理一下登场角色。这里名称相近的概念很多,是混乱的根源。

桌面一侧云端一侧Run script添加/获取/更新行Run Excel macro调用Power Automate桌面流程现有 VBA 宏Power Automate云端流程Excel Online Business连接器Office Scripts用 TypeScript 操作 ExcelExcel 表格OneDrive / SharePoint 上的工作簿本地 / 文件服务器上的工作簿
  • Office Scripts 是用 TypeScript 操作 Excel 的脚本功能,可在 Excel 网页版、Windows 版(2210 及以上版本)、Mac 版上运行,并可从 Power Automate 的云端流程中调用。它与 VBA 的根本区别在于:VBA 面向桌面设计,而 Office Scripts 面向云端与跨平台设计。26
  • Excel Online (Business) 连接器 用于从云端流程操作 OneDrive for Business 或 SharePoint 上的 Excel 文件,拥有对表格进行行操作的动作,以及执行 Office Scripts 的“运行脚本(Run script)”操作。7
  • 桌面流程(Power Automate for desktop) 是操作 Windows 上应用程序的 RPA,其 Excel 操作组中包含一个可以运行 VBA 宏的操作。5

VBA 能做到、而 Office Scripts 做不到的事

这是迁移判断中最重要的部分。以下依据 Microsoft Learn 的《Differences between Office Scripts and VBA macros》整理而成。2

VBA 能做到的事 Office Scripts 的处理情况
操作 Word、Outlook、Access 等 Excel 以外的 Office 应用 不可以。Office Scripts 仅限 Excel 使用,无法用于其他 Office 应用
通过 COM / OLE 与其他应用、外部组件联动,调用 Win32 API(Declare) 不可以。脚本只能访问工作簿本身,无法访问所在主机
Workbook_Open、Worksheet_Change 等事件驱动机制 不可以。不支持 Excel 级别的事件,执行方式只有手动执行或 Power Automate 调用两种
通过 UserForm 实现的自定义对话框、输入界面 不可以。如果需要工作簿之外的 UI(对话框或任务窗格),属于 Office 加载项的范畴3
本地文件夹的文件操作(打开、保存、获取列表) 不可以。跑到工作簿之外的处理需要交给 Power Automate 一侧的连接器(OneDrive、SharePoint 等)完成
涵盖桌面版 Excel 专有功能在内的广泛 Excel 功能 部分不可以。VBA 覆盖的 Excel 功能范围更广,Office Scripts 的定位大致是覆盖网页版 Excel 的使用场景

调用外部 Web 服务这一点也需要注意。Office Scripts 本身支持有限的外部调用,但经由 Power Automate 执行时,脚本内部发起的外部 API 调用(fetch)会失败。外部联动应该设计在流程一侧的连接器或 HTTP 操作中,而不是放在脚本内部。26 不过,用于调用任意 API 的通用 HTTP 操作属于高级连接器,仅凭 Microsoft 365 许可证无法使用。8 如果对接的服务已提供标准连接器,应优先使用;如果确实必须调用自有 API,则需要把高级许可证的额外成本纳入迁移决策。

看完这份清单,想必不少人会觉得“我们的宏几乎全都中招了”。确实,多年积累下来的 VBA 宏,通常都会包含通过 Outlook 发送邮件、遍历文件夹、通过 UserForm 接收输入这类内容。不过,在放弃之前,不妨先把处理拆解开来看看。例如一个“从文件夹收集文件、整理工作簿、再用邮件发送”的宏,文件收集和邮件发送正是 Power Automate 连接器擅长的工作,只要把工作簿整理部分改成 Office Scripts,整体上就能实现迁移——这种情况相当常见。

3. 决策表 ── 按使用场景在五个选项中做选择

迁移目标并不只有“转换为 Office Scripts”这一个选项。实务中可以从以下五个选项来考虑。

选项 适合的场景 前提・限制
(1) 继续保留为 VBA 个人或小团队的日常手工作业。确实必须用到 UserForm、事件、与其他应用联动等功能,且负责人在执行时在场也不觉得困扰 无需额外许可证。2不过要通过盘点来管理依赖特定人员、脱离管控的宏所带来的风险
(2) 转换为 Office Scripts,从云端流程执行 在工作簿内部就能完结的整理、汇总、转录处理。希望按计划启动,或以收到邮件、表单为触发条件。工作簿可以放在 OneDrive / SharePoint 上 需要商用/教育版 Microsoft 365 许可证。6事件、UserForm 等需要重新设计
(3) 用 Excel Online (Business) 连接器直接处理 仅涉及表格的行添加、获取、更新、删除这类简单处理,例如“把表单回复追加写入 Excel” 前提是处理对象已经是表格。存在默认 256 行、最大 25MB 等限制4
(4) 用桌面流程直接启动现有 VBA 没有余力改写 VBA,但希望自动化启动及前后处理(放置文件、发送通知)。工作簿位于企业内部文件服务器 需要 Windows 主机。从云端流程启动需要连接所有者持有 Power Automate Premium 许可证(无人执行则需要 Process 许可证)910
(5) 用 .NET 重新构建 大量数据处理、复杂业务逻辑、必须具备自动化测试或 Git 管理、以报表生成为主要目的 开发成本最高,但长期可维护性与性能最好。报表可以用 Open XML 等方式脱离对 Excel 的依赖

该选哪一个,大致可以按下面的流程来决定。

不能其他应用的 UI 操作 / COM 联动涉及格式 / 多个工作表 /业务逻辑不能仅限企业内部服务器没有有 / 需要性能与测试选定一个 VBA 宏处理是否在工作簿内部就能完结?Excel 之外的部分能否用连接器替代?例如发送邮件、收集文件拆解处理:Excel 部分 → Office Scripts其余部分 → 流程的连接器是否有余力改写 VBA?工作簿能否放在OneDrive / SharePoint 上?是否只需要对表格进行行操作?用 Excel Online Business连接器直接处理转换为 Office Scripts用 Run script 执行用桌面流程直接启动 VBA用 .NET 重新构建

需要注意的是,(4) 并不是“迁移的终点”,而是一种延命措施。VBA 本体依赖特定人员、缺乏版本管理的课题依然原封不动地留着。尽管如此,作为“先自动化启动、消除人工执行失误,同时逐步把 VBA 内部逻辑迁移到 Office Scripts 或 .NET”的争取时间的手段,它已经足够实用。

4. 实现方式 ── Run script 操作与连接器的限制值

运行脚本(Run script)

要从云端流程运行 Office Scripts,需要用到 Excel Online (Business) 连接器的两个操作。Run script 用于运行保存在 OneDrive(默认保存位置)中的脚本,Run script from SharePoint library 则用于运行保存在团队 SharePoint 库中的脚本。7

典型的结构大致如下。

  1. 触发条件:计划(Recurrence)、收到邮件、提交表单等
  2. 用 OneDrive / SharePoint 连接器定位目标工作簿
  3. 用 Run script 执行 Office Scripts,并接收返回值
  4. 用返回值发送 Teams 通知或邮件

脚本可以接收参数并返回值,因此能够实现诸如“从流程传入检索关键字,让脚本返回工作簿内对应的数据,再由流程一侧把它做成邮件”这样的数据往来。另外,原本 Excel 一侧的“脚本按计划执行”功能目前处于临时停用状态,官方建议改为用 Power Automate 的流程来实现按计划执行。11

先确认限制值

从 VBA 迁移过程中最容易踩坑的地方,是云端执行特有的限制值。桌面版 VBA 实质上不存在的上限,在这里是明确存在的。

限制 出处
Office Scripts 单次请求・响应大小 最大 5MB 6
单个范围(Range)的单元格数 最大 500 万单元格 6
Run script 调用次数 每位用户每天 1,600 次,且每 10 秒最多 3 次 64
同步处理超时时间 120 秒 6
传递给 Run script 的参数大小 最大 30,000,000 字节(约 28.6MB) 6
连接器可处理的 Excel 文件大小 最大 25MB 4
连接器单次请求大小 最大 5MB 4
连接器 API 调用次数 每个连接 60 秒内 100 次 4

如果要用 Excel Online (Business) 连接器直接操作表格,还需要确认以下几点。4

  • 行操作以表格为前提。 “添加行(Add a row into a table)”“获取行(Get a row)”等操作被设计为需要指定表格(ListObject),无法处理只是写在普通单元格范围里的数据。VBA 时代那种“从 A1 单元格开始随手写数据的工作表”,在迁移前需要先转换成表格。
  • List rows present in a table 默认最多只返回 256 行。 要获取全部行,需要启用分页设置。默认能获取的列也仅限前 500 列。
  • 写入生效可能有最长约 30 秒的延迟。 此外,使用连接器之后,文件有可能会被锁定最多 6 分钟。
  • 不支持多个客户端同时写入。 如果一边让工作簿在桌面版 Excel 中保持打开,一边用流程写入,这类做法会成为冲突和数据不一致的原因。
  • 支持的格式是 .xlsx 与 .xlsb(二进制工作簿)。.xlsm 只能在 Run script 操作中通过文件浏览器选择,在其他操作中使用则需要指定文件 ID。不过如前所述,其中的 VBA 宏不会被执行。含有 ActiveX 控件或表单控件的 .xlsm 有可能无法在连接器中正常工作,因此事先验证必不可少。1

如果把“每晚汇总数十万行数据的宏”原样改写成 Office Scripts,会正面撞上 5MB 限制和 120 秒超时。这种规模从一开始就分流给 .NET(选项 5)会更稳妥。

用桌面流程启动 VBA

如果决定继续保留 VBA,可以用桌面流程的 Launch Excel 打开工作簿,再用 Run Excel macro 操作指定宏名称(参数以分号分隔)来执行。如果要使用个人宏工作簿(PERSONAL.XLSB)中的宏,需要在 Launch Excel 的高级设置中启用“新建 Excel 进程并嵌套运行(Nest under a new Excel process)”和“加载加载项和宏(Load add-ins and macros)”。5

要从云端流程启动桌面流程,需要注册主机并建立桌面流程连接:有人执行需要连接所有者持有 Power Automate Premium 用户许可证,无人执行则需要在主机上具备 Power Automate Process 许可证(或旧版 Unattended RPA 附加组件)。910 关于错误处理、无人执行的前提条件等桌面流程整体设计,在另一篇文章「用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工,以及错误处理设计」中有详细说明。

5. 许可证与前提条件

Office Scripts 并不是“Excel 自带的免费功能”,这一点应该在迁移判断的早期阶段就确认清楚。

  • 使用与创作 Office Scripts 需要商用或教育版的 Microsoft 365 订阅许可证(Office 365 Business / Business Premium / ProPlus / ProPlus for Devices / A3 / A5 / E1 / E3 / E5 / F3)以及 OneDrive for Business。启用组织内共享链接,以及开启了连接体验的互联网连接,同样是前提条件。6
  • 从 Power Automate 使用 Office Scripts 同样需要 Microsoft 365 商用许可证。 E1 和 F3 可以通过 Power Automate 执行脚本,但无法使用 Excel 内置的 Power Automate 集成功能(例如 Excel 的“自动化我的工作”功能)。7
  • 个人/家庭版 Microsoft 365 中的 Office Scripts 仍处于预览阶段,需要加入 Microsoft 365 Insider 计划才能使用,不能作为业务使用的前提。6
  • 客户端方面,可在 Excel on the web、Excel for Windows(2210 及以上版本)、Excel for Mac 上运行。6
  • 另一方面,VBA 内置于桌面版 Excel 中,不需要特别的许可证。2

也就是说,在“公司内部的 Excel 是永久许可版(买断版),并未订阅 Microsoft 365”这样的环境中,Office Scripts 这个选项从一开始就不存在。这种情况下,迁移方向就只能局限于通过桌面流程实现启动自动化,或者用 .NET 重新构建。

安全性方面的差异也值得了解。VBA 宏以与 Excel 相同的权限运行,因此能访问整个桌面;而 Office Scripts 能访问的只有工作簿本身,登录用户的身份验证令牌也不会传递给脚本。管理员可以按租户、按组来控制 Office Scripts 的使用权限,以及在 Power Automate 中的使用权限。对于一直为宏的安全管理而头疼的 IT 部门来说,这种易于统一管控的特性,正是迁移的好处之一。2

6. 迁移的推进方式 ── 盘点、分类、分阶段迁移

实际迁移建议按以下三个阶段来推进。

第一阶段:盘点。 列出哪个工作簿中有什么样的宏,由谁负责管理。由于可以沿用应对 VBScript 弃用时的同一套步骤,具体做法请参考另一篇文章「为 VBScript 弃用做准备:VBA·企业内部工具排查指南」。通常在盘点阶段就会发现两三成“已经没人在用的宏”,仅仅把这些排除在迁移对象之外,就能减少不少工作量。

第二阶段:分类。 把剩下的宏对照第 3 章的决策表逐一归类。这里的诀窍是,不要以“一个宏”为单位,而是按处理单元来拆分。例如“收集文件 → 整理 → 发送邮件”这样的宏,可以拆分成 (3) 连接器 + (2) Office Scripts + 邮件连接器的组合。即便拆分之后依然依赖 VBA 的部分(例如 UserForm 的交互输入、对其他应用的 COM 操作等),才是 (1) 继续保留或 (4) 通过桌面流程延续的候选对象。

第三阶段:分阶段迁移。 不要一下子改写所有宏,而是先排出优先级。

  1. 优先从执行频率高、且在工作簿内部就能完结的宏入手。这样迁移效果大,也有助于熟悉 Office Scripts。虽然 VBA 与 TypeScript 是不同的语言,但 Office Scripts 同样具备操作录制(Action Recorder)功能,可以用与 VBA 宏录制相似的感觉来搭建初稿。2
  2. 迁移后的流程与原有流程并行运行一段时间,与 VBA 版本的结果进行比对。因转换为表格、日期格式差异等原因造成的偏差,在这个阶段可以被找出来。
  3. 决定继续保留为 VBA 的部分,要“在管理之下保留”。 明确执行手册和负责人,条件允许的话,尽量改为通过桌面流程启动,以留存执行日志。

关于 VBA 整体的未来走向,以及究竟在什么场景下可以继续使用 VBA 的思路,整理在「什么是 VBA——局限性、未来走向、该替换的场景与现实的迁移方式」中;把报表生成迁移到 .NET 时的方式比较,整理在「Excel 报表输出的实现方法 - COM / Open XML / 模板」中。另外,如果选择从 .NET 通过 COM 操作 Excel 这种结构,会遇到进程残留这一经典问题,因此也请一并确认「C# 操作 Excel 时 EXCEL.EXE 残留的问题 ── COM 引用释放模式与替换判断」。

7. 总结

对于“能不能把 VBA 迁移到 Power Automate”这个问题,答案是:“无法把整个宏原样移植过去,但只要把处理拆解开来,大部分都能找到迁移目标。”

在工作簿内部就能完结的处理,转换为 Office Scripts 并从云端流程调用;单纯的行操作直接交给连接器;涉及其他应用联动或 UserForm 的部分,继续保留为 VBA 或通过桌面流程延续;大量数据或复杂逻辑则分流给 .NET。只要提前做好这样的分类,迁移就不需要一口气完成,可以从使用频率高的宏开始,按顺序一点点推进。

反过来,如果不做分类,一上来就打算“全部改写成 Office Scripts”,就会接连撞上事件与 UserForm 的壁垒、5MB/120 秒的限制、必须是表格的约束,最终陷入停滞。迁移能否成功,与其说取决于改写的技巧,不如说几乎完全取决于动手之前的盘点与分类。与其把 VBA 资产当作“迟早要丢弃的东西”,不如把它当作“分类后善加利用的东西”,这样最终反而最省钱。

相关文章

相关咨询领域

合同会社小村软件(KomuraSoft LLC)承接从盘点基于 Excel / VBA 运转的现有业务,到设计向 Power Automate、Office Scripts、.NET 分阶段迁移的方案,提供以善用现有资产为前提的咨询服务。

参考链接

  1. Microsoft Learn, How to use macro-enabled files in Power Automate flows。关于 .xlsm 文件内的宏无法从 Power Automate 运行、只有 Office Scripts 有效,只有 Run script 操作能在文件浏览器中选择 .xlsm,以及含有 ActiveX/表单控件的文件有可能无法正常工作的说明。  2

  2. Microsoft Learn, Differences between Office Scripts and VBA macros。关于 Office Scripts 仅限 Excel 使用且只能访问工作簿本身、不支持事件、COM/OLE 仅 VBA 支持、Office Scripts 需要商用/教育许可证而 VBA 标配于桌面版 Excel,以及操作录制与安全管控方面的差异的说明。  2 3 4 5 6 7 8 9 10

  3. Microsoft Learn, Differences between Office Scripts and Office Add-ins。关于 Office Scripts 只能与工作簿交互,如需对话框或自定义 UI 控件则需要 Office 加载项的说明。  2

  4. Microsoft Learn, Excel Online (Business) - Connectors reference。关于最大文件大小 25MB、单次请求 5MB、List rows 默认 256 行及分页机制、获取列的默认 500 列上限、Run script 每 10 秒 3 次・每天 1,600 次的限制、最后一次使用后最长 6 分钟的文件锁定、写入生效最长 30 秒的延迟、每个连接 60 秒内 100 次的节流限制、不支持同时编辑,以及支持的文件格式的说明。  2 3 4 5 6 7

  5. Microsoft Learn, Run macros on an Excel workbook。关于用桌面流程的 Run Excel macro 操作执行 VBA 宏、执行 PERSONAL.XLSB 中的宏需要在 Launch Excel 中启用“Nest under a new Excel process”“Load add-ins and macros”选项的说明。  2 3

  6. Microsoft Learn, Platform limits and requirements with Office Scripts。关于所需许可证列表与 OneDrive for Business 要求、支持的平台(Excel on the web / Windows 版 2210 及以上 / Mac)、请求・响应 5MB 限制、范围 500 万单元格限制、Run script 每天 1,600 次的限制、120 秒超时、参数 30,000,000 字节限制、经由 Power Automate 执行时外部 API 调用(fetch)会失败,以及个人/家庭版仍为预览阶段的说明。  2 3 4 5 6 7 8 9 10 11 12

  7. Microsoft Learn, Run Office Scripts with Power Automate。关于 Run script / Run script from SharePoint library 这两个操作、在 Power Automate 中使用 Office Scripts 需要 Microsoft 365 商用许可证、E1・F3 可以从 Power Automate 执行但无法使用 Excel 内置的集成功能的说明。  2 3

  8. Microsoft Learn, Guidance: Migrate from classic workflows to Power Automate flows in SharePoint。关于 Power Automate 的通用 HTTP 操作属于高级连接器的说明。 

  9. Microsoft Learn, Trigger desktop flows from cloud flows。关于从云端流程启动桌面流程所需的前提条件(已注册的主机、桌面流程连接、与执行方式相应的许可证)的说明。  2

  10. Microsoft Learn, A failed license check on a desktop flow run。关于桌面流程的有人执行需要连接所有者持有 Power Automate Premium 用户许可证,无人执行则需要 Unattended RPA 附加组件或 Power Automate Process 许可证的说明。  2

  11. Microsoft Learn, Office Scripts in Excel。关于 Excel 自带的脚本按计划执行功能目前处于临时停用状态,官方引导改用 Power Automate 的流程来实现按计划执行的说明。 

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

与本文相近的主题页面。以本文为起点,可以进一步了解相关服务和其他文章。

本文与以下服务页面相关联,欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

现有的 VBA 宏可以直接从 Power Automate 运行吗?
无法从云端流程直接运行。Excel Online (Business) 连接器可以处理 .xlsm 文件本身,但无法运行其中的宏,能运行的只有 Office Scripts。另一方面,桌面流程(Power Automate for desktop)中有 Run Excel macro 操作,可以把通过 Launch Excel 打开的工作簿中的 VBA 宏原样运行。如果只想在不改动 VBA 代码的前提下自动化启动这一步,走桌面流程是现实的选择。
Office Scripts 能完全替代 VBA 吗?
不能。Office Scripts 仅限 Excel 使用,无法操作 Word、Outlook 等其他 Office 应用。由于脚本只能访问工作簿本身,因此也无法进行本地文件操作或 COM/OLE 联动,也没有 Workbook_Open 这样的事件驱动机制,也没有 UserForm 那样的自定义对话框。反过来说,凡是能在工作簿内部完结的整理、汇总、转录类处理,都可以替换为 Office Scripts,并配合 Power Automate 实现按计划执行或以事件触发执行。两者并非替代关系,而是各自覆盖不同的范围,这样理解更准确。
使用 Office Scripts 需要什么许可证?
需要商用或教育版的 Microsoft 365 许可证(Office 365 Business / Business Premium / ProPlus / E1 / E3 / E5 / F3 / A3 / A5)以及 OneDrive for Business。从 Power Automate 运行 Office Scripts 同样需要 Microsoft 365 商用许可证,E1 和 F3 虽然可以通过 Power Automate 执行,但无法使用 Excel 内置的 Power Automate 集成功能。这与 VBA 标配于桌面版 Excel、无需额外许可证形成对比,因此在决定迁移之前,需要先确认自身的许可证情况。
仅凭 Excel Online (Business) 连接器就能完成自动化吗?
简单处理可以完成,但有不少限制需要留意。行的添加、获取、更新、删除都以对象范围已经是表格(ListObject)为前提,List rows present in a table 默认最多只返回 256 行,需要启用分页才能获取更多。文件大小上限为 25MB,单次请求最大 5MB,写入生效有时会有最长约 30 秒的延迟。实务上的分工是:表格中少量行的读写直接交给连接器,涉及单元格格式或跨多个工作表的处理则交给 Office Scripts。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心,擅长难以复现的故障调查,以及既有资产仍在运行的项目。

返回博客列表