Office 换成 64 位，旧宏和加载项不一定能直接沿用。决定能否迁移的，是自动化流程依赖了哪些组件，以及这些组件能否在新的 Office 环境里完成原来的工作。采购时只问“支持 Excel 吗”，或验收时只看表格能否打开，都不足以回答这个问题。
下面以 Windows 桌面 Office 为范围，给企业 IT、采购和业务负责人一份依赖核对方法。它不等于把桌面宏迁到在线办公平台；后者还要单独评估运行机制和重建成本。
先确认 Office 的位数，别只看电脑配置
64 位 Windows 不等于安装了 64 位 Office。微软在位数选型说明中明确：没有 64 位替代版本的 32 位 COM 加载项，可以继续在 64 位 Windows 上的 32 位 Office 中运行；若要迁移，应向加载项供应商确认对应版本。
因此，先为每条关键业务流程记录当前和目标环境：Office 产品、版本与位数，操作系统，以及加载项、控件和外部程序版本。把“员工换了新电脑”和“Office 运行环境改变了”分开登记，才容易定位后续差异。
把“一个表格”拆成一张依赖清单
建议按业务任务建台账，而不是按文件数量抽样。下面四类信息需要一起收齐：
- 文件与业务结果：模板在哪里、谁负责维护、运行后应该生成什么、由谁确认结果正确。
- 宏与声明：是否调用 Windows API，是否含 Declare 声明，是否有代码维护者能检查返回值、参数及相关数据类型。
- 加载项与控件：名称、版本、位数、安装来源和供应商支持范围。写“已安装”时，还要记录它是否成功加载。
- 外部依赖：是否连接数据库、调用其他程序或使用本地文件路径；把所需驱动、访问条件和维护责任人写清楚。
微软的64 位 VBA 说明指出，64 位 Office 中的 Declare 声明需要 PtrSafe，但仅加上这个词并不能保证正确。用于指针、句柄的值还需要适合的类型，例如 LongPtr；返回值、参数和关联结构都可能需要检查。这是针对具体代码的审查工作，不能把所有 Long 批量替换后就宣告迁移完成。
测试一笔业务，留下每个断点
假设财务部门有一份月末结算模板：加载项读取数据，宏生成明细，再导出给复核人员。以下是设计测试的例子，不代表任何产品已经通过这些步骤。
- 安装与加载：在目标 Office 环境安装约定版本的组件，确认加载项出现且可以调用。失败时记录组件名称和错误信息，先查供应商支持范围。
- 执行：使用经脱敏的固定输入，跑完取数、计算、生成和导出。只运行宏的第一段，不能证明后续调用可用。
- 对账：由业务负责人核对关键金额、记录条数、输出字段及异常提示。没有报错，也可能生成了错误结果。
- 再次使用：关闭并重新打开输出文件，交给实际接收角色完成复核，确认下一环节无需临时补救。
每条结果标记“通过、失败、未测”，同时保留输入样本版本、环境版本、复现步骤和责任人。季末才运行的流程也要列入清单，不能因为最近没人打开过就默认不重要。
采购与实施约定也要对应到这张台账：谁提供目标版本的加载项、谁修改自建宏、谁承担第三方组件费用，以及失败时如何恢复业务。如果供应商只承诺 Office 安装成功，企业仍需为自建自动化安排验收负责人；两者的交付范围应在切换前说清。
什么时候迁移，什么时候先保留
可以进入小范围迁移：关键组件已有目标位数版本，宏代码完成必要调整，业务负责人核对完整输出通过。随后再安排受控试点与切换，避免把某一份样本成功扩大成所有流程兼容。
应暂缓这一条流程：关键 32 位组件没有替代版本，或缺少源码、维护者及可重复的测试。先确认现有 Office 版本仍受支持、现有环境可维护，再决定是否暂留 32 位环境；不能用“暂留”延长已经失去支持的系统寿命。
适合另立重建计划：自动化长期无人维护，或业务准备改变数据处理方式。应把现有输入、输出与例外规则整理成需求，明确重建费用和接替时间，不把它藏进一次普通软件升级里。
比较办公套件时，把协作和自动化分开询价
一份文件需要多人查看、编辑和管理权限，不代表其中的桌面 VBA 或 COM 依赖也能原样搬过去。评估石墨办公套件私有部署（以下简称办公套件）时，可以先列清文档协作需求，再逐项讨论原有自动化如何保留、调整或由其他系统承接；具体能力以交付版本和验证结果为准。
带着关键模板、依赖清单和预期输出预约演示，让方案讨论落到“哪条流程怎样继续运行”，而不是停在“支持哪种文件格式”。
在企业文档中验证
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。