InfoPath 2007表单维护与迁移：从部署到避坑的完整指南

简介：Microsoft InfoPath 2007 官方数据手册的中文 DOC 版，面向需要评估或实施企业电子表单方案的信息化主管、Office 高级用户及系统集成人员。文档系统介绍了 InfoPath 2007 在表单设计、数据验证、浏览器与移动设备填报、自动版本更新、Word/Excel 转换以及 PDF/XPS 归档等方面的核心功能，并结合 InfoPath Forms Services 说明了与 SharePoint Server 2007 工作流集成、XML 标准兼容及信息权限管理等内容；同时重点提到与 Outlook 2007 的整合体验、对 Firefox/Safari 浏览器的支持，以及无需编写代码即可完成的提示与条件格式工具，可作为技术选型、部署规划与员工培训的参考资料。资源包内含 1 个 doc 文件，总大小约 849KB，属于轻量级单文档资料。目前已有 129 人浏览学习。文档内容源自微软官方预览材料，结构完整，重点突出新功能、部署选项与典型应用场景，适合快速建立对 InfoPath 2007 能力边界的整体认识，也有助于推动企业内部从纸质表单向电子化、流程化表单升级。

1. 一份 2007 年的 Datasheet，为什么今天还有人在翻

手头出现Microsoft InfoPath 2007 Datasheet_CN_Final.doc这类文件的人，通常不是在做技术选型，而是在翻旧账：公司服务器上还挂着 MOSS 2007 或者 SharePoint 2010，表单库里跑着几张十年前做的 InfoPath 表单，突然某天审批流报错、浏览器里打开是空白，或者审计要求整理资产清单，于是这份当年没人细看的 Datasheet 被重新翻了出来。InfoPath 2007 是 Microsoft Office 2007 家族里的表单设计工具，用来做结构化数据录入、审批流页面和 SharePoint 集成的场景。它解决的问题非常聚焦：让非程序员也能快速设计一张带校验规则、能提交到列表或数据库的表单。今天看这份文档，真正的价值不是再学一遍 InfoPath，而是借它理解老系统的边界，想清楚继续维护还是迁移。这篇笔记就按这个思路，从产品结构、表单制作、服务器部署到避坑和迁移，把落地路径一次性讲透。

2. 读 Datasheet 先读结构：InfoPath 2007 的表单模板、数据连接与三种发布归宿

2.1 XSN 不是文档格式，是打包工程：理解表单模板的内部结构

InfoPath 2007 的设计产出是一个扩展名为.xsn的文件，很多人把它当成和 Word 文档一样的东西，双击打开看到的是表单界面，就以为那是一个“文档”。实际上.xsn是一个打包工程，里面装了表单的定义、数据架构、视图样式和规则。我一般拿到别人移交的 xsn 文件，第一件事不是双击打开，而是用 InfoPath Designer 执行“文件”菜单里的“保存为源文件”，把这一个包解成一组文件再看。

解出来之后，表单模板里通常会有以下几类文件，清单和作用如下：

把这个包拆开的意义在于：InfoPath 的表单逻辑是分层的，字段结构在 XSD 里，交互规则在 XSF 清单里，显示样式在 XSL 里。遇到表单打不开、发布失败或者要迁移，直接改 xsn 包等于改一个黑匣子，先把层拆开才能定位问题。我见过太多人试图用压缩工具直接解开 xsn 改 XML 再打包回去，10 次有 9 次弄坏模板结构。正确做法是始终从源文件工程重新生成 xsn。

另外需要注意，InfoPath 2007 的模板兼容模式有三个层级：兼容 InfoPath 2003、兼容 InfoPath 2007、以及支持浏览器填写的 Forms Services 模式。Datasheet 里写的“浏览器兼容”指的不是任意网页浏览器都能打开，而是必须有 SharePoint Server 企业版的 InfoPath Forms Services 支撑。读 Datasheet 时如果忽略这个前置条件，后面所有部署都会踩坑。

2.2 数据连接选型：SharePoint 列表、Web 服务与数据库怎么取舍

InfoPath 表单的数据连接决定了这张表能不能真正用起来。2007 年代最常见的四种数据连接方式，每种都有明确适用场景，也存在各自的限制。设计之前先把数据源选对，比后面调规则重要得多。

SharePoint 列表是最常用的数据源。表单提交时直接创建列表项，或读取某个列表的数据作为下拉选项。好处是权限跟着 SharePoint 走，审批流也好对接；坏处是列表的字段类型和 InfoPath 字段类型之间会做一次映射，比如查阅项（Lookup）处理起来很别扭，日期和时间会带上时区，排序规则也受列表视图限制。建议只在数据量不大、字段不超过二三十列的场景用列表直连。

Web 服务是灵活性最高的方式。InfoPath 2007 支持以 Web 服务作为数据连接，通过 SOAP 协议读写后端业务数据。在 Dynamics CRM 本地部署这类企业系统里，InfoPath 表单经常通过组织服务接口拉数据、提交数据。这种方式能绕过 SharePoint 列表的字段限制，也能在后端做复杂的校验和业务逻辑。代价是需要一个稳定的 Web 服务和一份结构清晰的 WSDL，接口一变更，表单模板就要跟着改。

数据库直连是看起来省事、实际最受限的方案。InfoPath 2007 的数据连接向导里可以选 SQL Server 或 Oracle，但浏览器表单模式下数据库连接只能通过 UDC 文件间接使用，而且 InfoPath 对 SQL 数据源的支持停留在基础读写层面，多表关联、存储过程、事务都得靠 Web 服务包一层。如果表单既要发布到浏览器又要连数据库，我的建议是放弃数据库直连，改用 Web 服务或者 SharePoint 列表加后端定时同步。

这四种连接方式的对比，按选型优先级排下来是：

读那份 Datasheet 的时候，可以对着表格反推当年的系统架构到底是怎么设计的。如果表单主要数据源是 SharePoint 列表，说明方案核心在协作流程；如果数据源是 Web 服务，那 InfoPath 只是门面，后台系统才是重点。

2.3 发布目标决定设计约束：客户端表单、浏览器表单与 InfoPath Forms Services

InfoPath 2007 建好的表单模板，发布目标会反过来约束设计阶段能做什么、不能做什么。很多老表单在客户端好好的，发布到服务器浏览器里就打不开或交互失效，根本原因是发布目标没在设计之前确定。

第一种发布目标是客户端表单，用户通过 InfoPath Filler 填写。Filler 是随 Office 2007 安装的独立程序，体验接近桌面应用，功能最完整，ActiveX 控件、COM 组件、附件上传、复杂的代码逻辑都能跑。用 Filler 就必须给每台填写表单的机器装 Office 和 InfoPath，许可证和分发工作量都不小。

第二种是发布到 InfoPath Forms Services，用户直接在浏览器里打开填写。这要求 SharePoint Server 企业版场启用了 InfoPath Forms Services 服务，表单模板还要经过管理员上载并批准。浏览器表单在功能上是有阉割的，InfoPath 2007 的浏览器模式不支持 ActiveX 控件，部分规则操作受限，附件处理能力很弱，打印依赖专门配置的打印视图。设计时如果不知道这点，很容易做出“设计器里正常，浏览器里翻车”的表单。

第三种是作为独立模板通过电子邮件分发，或者放到文件共享里由 Filler 打开填写。这种模式适合离线场景，表单模板里嵌入 XML 数据，填完再通过邮件提交或合并。缺点是没有服务端统一管理，数据散落在个人手里，审计和回溯困难。

三种发布目标的差异，直接对应 Datasheet 里最常被忽略的三行信息：客户端要求、服务器组件要求、浏览器支持范围。技术选型时我通常用一张小表帮助判断局面：

从维护角度看，三种方式里浏览器表单最省心，不用给终端装客户端，但服务器端的依赖最重。老项目里如果浏览器表单突然不能用，大部分情况不是表单文件坏了，而是 SharePoint 服务器上 Forms Services 的某个环节出了问题。这个坑后面专门展开。

3. 照抄这份配置做一张可用表单：字段设计、规则与发布向导的关键选项

3.1 准备一套能跑 InfoPath 2007 的环境：Office 安装与 Visual C++ 运行库

想重新打开和修改十年前的表单，首先要有一台能跑 InfoPath 2007 的机器。常见误区是以为装了新版 Microsoft Office 就能打开 xsn，实际上从 Office 2013 开始 InfoPath 不再随 Office 发布，Office 2016 及更新版本里根本没有 InfoPath 组件。要处理 2007 的表单，就只有两条路：找一台装了 Office 2007 或 2010 的旧机器，或者在虚拟机里搭一个完整的 Windows 7 加 Office 2007 环境。

在 Windows 10 或 Windows 11 上安装 InfoPath 2007 时，最容易遇到的是安装程序卡住或报错，日志指向缺少运行库。很多情况下是 microsoft visual c++ 2005 SP1 或 2008 SP1 的 redistributable 没有提前安装，Office 2007 的中文版安装包对系统组件的检测又比较老，新系统上经常出现检测不出来或者装不上的问题。我的建议是安装顺序严格按：.NET Framework 3.5（含 2.0 和 3.0 支持）→ Visual C++ 2005/2008 运行库 → Office 2007。装完 Office 之后再单独确认 InfoPath 组件是否被勾选，Office 2007 默认企业版安装不一定包含 InfoPath，需要在自定义安装里把 InfoPath 设为“从本机运行”。

环境就绪后，还有一个容易被忽略的步骤：在 InfoPath 的“信任中心”里检查“启用来自 Internet 的表单模板”和“允许浏览器表单提示”这两个选项。调低安全级别会带来风险，但调太高会让旧表单一打开就被拦截。实际维护中我一般会把“我的电脑上的表单模板”设为完全信任，Internet 来源设为提示，够用就好。

3.2 用“请假申请”走通表单设计：字段类型、默认值与验证条件

环境准备好之后，用一个最典型的“请假申请”表单来走通整个设计流程。这个例子能覆盖 InfoPath 2007 的核心功能：字段绑定、默认值、数据验证和规则操作。新建表单时选择“表单模板”里的“空白表单”，然后按下面的字段表添加数据。

在设计器中每加一个控件，InfoPath 会自动在 data source 里生成对应字段，但字段类型经常需要手动改。比如“员工编号”如果直接接受文本，能够输入任意字符，所以要打开“文本框属性”，在“数据类型”里选择“数字”，再设置最小值 100000、最大值 999999，同时勾掉“允许空字符串”以外的多余选项。日期字段的默认值选“当前日期”，这样用户新建表单时不用手动填开始日期。

验证规则是 InfoPath 2007 里最值得花时间的地方。选中“结束日期”控件，打开“属性 → 数据验证 → 添加规则”，设置条件为“结束日期 < 开始日期”，错误消息写“结束日期不能早于开始日期”。这个验证规则会在用户离开该字段时立即触发，也会在提交时阻止表单。规则表达式里的字段引用要写对，InfoPath 的公式生成器会自动插入 XPath 引用，不建议手动敲路径，容易把字段映射弄乱。

除了验证规则，还可以加上“提交”行为。在“工具 → 提交选项”里选择“提交到 SharePoint 列表”，指定目标列表为“请假申请”，并勾选“覆盖写入现有列表项”。这样用户填完点提交，表单数据就作为新列表项写入 SharePoint。注意提交选项里的“包含数字签名”不要随便勾，一旦启用签名，浏览器表单模式下验证会比较复杂，运维阶段容易变成麻烦的来源。

3.3 发布到 SharePoint 表单库：四步向导里的参数与推荐值

表单设计完成并保存为.xsn后，下一步是发布到 SharePoint 服务器。InfoPath 2007 的发布向导有四个关键页面，每一步的参数直接影响表单能不能在浏览器里打开。

第一步选择发布位置，选“SharePoint 表单库”。如果选错成“Web 服务”或“共享文件夹”，后面浏览器填写功能就没法启用。第二步输入 SharePoint 站点地址，发布向导会用当前 Windows 身份验证连接站点。第三步选择“创建新的表单库”，填写表单库名称和描述，比如“请假申请登记”。这一页最关键的选项是底部的“在此表单库中启用浏览器填写表单”，必须勾上，否则用户只能装 InfoPath Filler 才能填。

第四步是“发布向导”的最终确认页，里面会显示模板的“浏览器兼容性”评估结果。如果设计时用了浏览器不支持的控件，这里会有警告。我遇到最多的是“文件附件”控件和不支持的数据连接，设计阶段是绿色，向导一跑就变黄色。看到黄色警告不要硬发，回到设计器把不支持的功能换掉，比如附件控件改成列表项的附件列，由 SharePoint 自己管理附件。

发布完成后，还要做一件事：管理员需要在 SharePoint 中央管理里批准该表单模板。如果发布之后马上用浏览器打开表单库，大概率看到“找不到表单模板”的错误。原因是在 SharePoint Server 企业版环境下，InfoPath Forms Services 默认只渲染已经“启用”的模板。流程是在“中央管理 → 应用程序管理 → 管理表单模板”里找到新上传的模板，状态改为“已启用”。这一步必须在服务器上操作，普通站点集管理员没有权限。

发布时的“数据连接”设置也在这条链路里。如果表单数据源指向 SharePoint 列表，发布向导会自动建立跨站连接并提示输入连接凭据；如果指向外部 Web 服务，向导会要求在 UDC 文件里指定访问方式。这里的常见坑是用了默认的“自动”数据连接，发布后模板引用的是本地设计时的连接地址，服务器上一换域名就失效。保险做法是在“工具 → 数据连接”里把连接方式改成“通过 SharePoint 上的数据连接文件”，先由管理员上传 UDC，再在模板里引用。

4. 放上服务器之后的六件工作：Forms Services 部署、权限与模板更新

4.1 浏览器表单空白页的根因：Forms Services 没有启用或模板没升级

表单发布完，浏览器里打开一片空白，这是 InfoPath 2007 运维里最高频的问题。第一嫌疑是服务器上 InfoPath Forms Services 服务没有启用。SharePoint Server 2010 以及 2007 的 MOSS 企业版，默认都不启用 InfoPath Forms Services，需要在“服务器场功能”里单独激活。查询方法很简单：进入“中央管理 → 系统设置 → 管理服务器上的服务”，看“InfoPath Forms Services”服务是否已启动。

第二个高发原因是站点集功能里没激活。即使场功能已经打开，每个站点集还要在“网站集功能”里激活“InfoPath Forms Services”网站集功能。很多管理员只做了一半，服务启动、场功能开启，但站点集功能漏了，结果就是表单库能显示，点进去浏览器渲染失败。

还有一个经常被忽略的版本匹配问题。InfoPath 2007 发布的浏览器表单模板，如果服务器装的是 SharePoint Server 2010，模板格式可以沿用，但要通过“兼容性检查”确认没有使用 Forms Services 不支持的属性。到 SharePoint 2013 时代，InfoPath Forms Services 还在但被标记为不再迭代的功能，老模板经常在 HTTP 响应上出问题，表现为页面加载后白屏、控制台报脚本错误。

排查顺序我按这个来，能解决八成空白页问题：

4.2 半信任与管理员审批：数据连接为什么要走 UDC

InfoPath 2007 的表单默认运行在“半信任”模式下，这意味着表单不能随意访问任意数据源，所有跨域数据连接都必须经过管理员批准。这个设计经常导致一种现象：表单设计者在自己的机器上测试一切正常，发到服务器之后，某些下拉框、某些数据提交动作就是不行，没有任何报错，或只在日志里看到安全异常。

原因是表单模板发布后，数据连接的权限被限定在模板的信任级别里。半信任模板访问外部数据源时，InfoPath Forms Services 会查找用户数据连接文件库中的 UDC 文件。UDC 文件的本质是一个 XML 描述，告诉服务器这个连接指向哪个地址、用什么身份验证方式。管理员要先在“中央管理 → 应用程序管理 → 管理数据连接文件”里上传 UDC，并保证它所在的文档库允许表单访问。

处理这个问题的常规路径是：在 InfoPath 设计器里，把数据连接的“数据源类型”改为“通过 SharePoint 上的数据连接文件”，填管理员给的连接文件名称；然后由管理员上传对应 UDC，再重新发布模板。模板里不再直接存储服务器地址，而是通过 UDC 间接获取。好处是以后数据库服务器换 IP，只改 UDC 文件一个地方，不用重新设计发布所有表单。

Full Trust 模式可以绕过 UDC，但我不建议在浏览器表单里用。Full Trust 要求对模板做强名称签名，并需要在服务器上部署代码访问安全策略，一旦签名证书过期，所有表单立刻不可用。企业里维护这种依赖的成本比 UDC 高一个数量级，能用半信任解决的问题，不要为省事上 Full Trust。

4.3 模板更新要留后悔药：版本管理与发布后回滚

InfoPath 2007 表单模板的更新机制，很多运维同事都会在第一次操作时翻车。表单改好之后重新发布，向导会把新版本推送到 SharePoint，但这不代表旧版本没了。中央管理的“管理表单模板”页面里，同一模板会积累多个版本，管理员需要手动指定启用哪一个版本。

实际操作中最容易踩的坑是：直接“重新发布”覆盖原模板，而没有在发布之前导出源文件和旧版 xsn 备份。一旦新模板在浏览器里渲染异常，想回滚却发现旧版本已经不可恢复。这是没有后悔药的局面，服务器上虽然可能保留旧版本，但大多数情况发布行为会让旧版本被标记为“已停用”，再次启用时又会连带数据连接状态变化。

我的做法是给每张表单建一个维护文件夹，命名规则是“表单名_日期_版本号”，里面同时保存原始 xsn、导出源文件、以及发布时记录的 SharePoint 地址和表单库名称。每次发布前先完成本地测试，发布后在表单库里用测试账号验证浏览器打开、填写、提交三个动作。更新流程固定成四步：导出源文件备份 → 设计器修改并本地测试 → 发布向导完成发布 → 管理员重新“上载并启用”模板。

模板回滚的正确方式是在中央管理里找到该模板的历史版本，选择旧版本并执行“激活”。如果模板被多个表单库引用，激活版本的变化会同步影响所有引用位置，回滚前务必走变更审批流程，而不是直接点按钮。这个习惯在 InfoPath 2007 这种老产品上尤其重要，因为它的回滚机制不像现代低代码平台那么友好。

5. InfoPath 2007 维护避坑清单：翻过车的五个现场与处理办法

下面这五条是从实际维护里攒出来的血泪经验，覆盖中文环境、浏览器渲染、工作流集成和迁移时的典型陷阱。每条都按“现象 → 原因 → 处理”写，遇到类似问题可以直接对着做。

5.1 中文环境里签名提示乱码，表单存不进 SharePoint

现象：用户填写完表单，点“提交”后提示“此表单的数字签名无效”，或者列表项已经创建但内容显示为乱码。这种现象在中文站点和中文域名环境下特别容易出现，英文环境极少见。

原因：InfoPath 2007 的数字签名功能依赖 CryptoAPI 对表单 XML 做哈希和签名，当表单模板包含中文字段名或中文站点路径时，某些版本的签名生成器对编码处理不完整，服务器端收到签名后重新计算哈希对不上。另一个常见原因是服务器上的代码页和客户端不一致，中文 Windows 默认 GBK，客户端提交 UTF-8 编码的 XML，在 IIS 层被强制转换了。

处理：对绝大多数内部表单，直接关闭数字签名功能。在 InfoPath 设计器“工具 → 提交选项”里取消“包含数字签名”，重新发布。如果业务上确实要防篡改，建议改用 SharePoint 列表项的“强制审批”配合审计日志，而不是依赖 InfoPath 的数字签名。另外确认 SharePoint 网站的请求筛选里maxAllowedContentLength值够大，默认 30 MB 一般够用，但有些大表单加上签名后会超限，报的却是签名错误。最后把站点和服务器区域设置统一为中文简体，不要混用中文和英文区域。

5.2 浏览器表单打印总是少一列：打印视图和浏览器渲染不一致

现象：同一个表单在 InfoPath Filler 里打印一切正常，在浏览器表单里打印出来的纸张上少一列，或者表格右边被截断，用 Microsoft Print to PDF 导出时更明显，右半部分直接丢失。

原因：浏览器表单渲染时使用的是一套 HTML 输出逻辑，而打印输出是另一套打印视图逻辑。InfoPath 2007 设计器里默认有“打印视图”，这个视图和用户填写的“数据视图”是分离的，如果打印视图没有单独调整列宽和分页，浏览器打印时会沿用数据视图的分页，宽度超过打印纸可见区域的内容就被截断。

处理：在设计器底部视图切换栏里选择“打印视图”，逐列检查宽度，重点看表格总宽度是否超过页面设置的可打印宽度。把打印视图的宽度控制在 190 mm 以内（A4 纸默认边距下），并在打印视图中显式设置分页符。如果表单包含多行重复表，还要在打印视图里为重复节添加“在每页顶部重复标题行”属性。改完后重新发布，并在浏览器里用打印预览验证一次，不要只在设计器里看效果。

5.3 带 InfoPath 表单的审批流在 SharePoint 升级后全部失效

现象：原有 SharePoint 2007 或 2010 上运行良好的审批流，表单任务页面用的是 InfoPath 模板。服务器升级到 SharePoint 2013 或之后，点击任务链接触发 404 或“无法找到表单模板”，审批流流程还在跑，但任务点不开。

原因：SharePoint 2013 改变了工作流任务的渲染方式，从 2010 工作流升级到 2013 工作流时，旧的任务编辑表单如果绑定到 InfoPath 模板，关联的表单模板没有同步迁移到新的工作流任务表单架构里。加上 InfoPath Forms Services 在 2013 里被标记为“尽量不用”，很多升级向导会跳过 InfoPath 相关设置。

处理：先确认工作流本身是 2010 模式还是 2013 模式。如果还是 2010 工作流，把 InfoPath 任务表单重新绑定一次；如果已经迁移到 2013 工作流，InfoPath 任务表单已经不在支持范围内，需要改用 SharePoint 2013 的默认任务表单或者转到 Power Automate 重做审批流。最实际的建议是趁这次失效把审批流从 InfoPath 表单迁移出去，因为留在 InfoPath 上的每一次升级都会再次踩同一个坑。

5.4 Dynamics CRM 本地部署里的 InfoPath 表单控件消失

现象：Microsoft Dynamics CRM 本地部署环境里，实体表单用 InfoPath 做了自定义布局，某一天打开 CRM 记录，自定义的表单区域变成空白，或者显示“无法加载 InfoPath 表单”。CRM 版本从 2011 升到 2015 或 2016 后问题集中爆发。

原因：Dynamics CRM 2011 和 2013 支持用 InfoPath 作为实体表单的编辑界面，但从 CRM 2015 开始，微软逐步移除了 InfoPath 集成，到 CRM 2016 里 InfoPath 表单已经被正式废弃。如果组织一直停留在 2011 或 2013，升级时没有先迁移自定义表单，旧表单在新版本里自然失效。

处理：迁移方案是把 InfoPath 自定义的表单字段和布局重新在 CRM 的“表单设计器”中做一遍。因为 InfoPath 表单里的字段本质上还是实体属性，数据不会丢，只是界面载体变了。迁移时对照“实体 → 表单 → 信息”里记录的字段列表，逐个找回布局。建议在升级之前先用解决方案导出原 InfoPath 表单里的字段映射表，否则升级后界面空白，字段清单只能靠猜。

5.5 想迁移模板却打不开旧 XSN：先导出源文件而不是直接改包

现象：从 SharePoint 表单库下载了一个.xsn模板，在装有 InfoPath 2010 或 2013 的机器上双击，提示“此表单模板是使用较新版本的 InfoPath 创建的”或者反过来提示“无法识别的模板格式”，但模板明明就是 InfoPath 2007 做的。

原因：.xsn不是单一文档，它的打开依赖 InfoPath 版本和模板的实际格式。服务器上运行的可能是 2007 格式模板，客户端装的 InfoPath 2013 虽然能打开 2007 模板，但如果模板在服务器上经过了“重新上载”操作，内部 manifest 的版本标记可能被改写。另外有些人尝试用压缩工具解开 xsn 直接改 XML，改坏了格式以后，InfoPath 再也不认。

处理：用“文件 → 保存为源文件”的方式导出整个工程，再从源文件工程中恢复模板。具体操作是打开 InfoPath 设计器，选择“打开”并指定下载的 xsn 文件，如果设计器能打开，就立刻另存为源文件到本地文件夹；如果设计器打不开，就用版本匹配的机器（通常是 2007）先把模板转为兼容格式，再交到新版设计器处理。迁移过程中不要直接修改 xsn 包内部的二进制文件，所有字段层面的改动回到源文件里的 XSD 和 XSL 再做。

6. 给 InfoPath 2007 规划退路：模板迁移评估与一张能直接用的检查清单

InfoPath 2007 的维护是典型的技术债场景，越往后拖成本越高。新系统不用它，老系统里还能用，但每次 Office 升级、SharePoint 升级、Windows 更新都像是在走钢丝。我的习惯是趁系统还能运行，把每一张表单的信息摸清楚，做一次迁移评估，而不是等到服务器换掉才手忙脚乱。

评估之前先建立一张表单资产清单，逐项记录以下信息：

填写完清单后，按迁移成本和业务风险排序。高优先级是每日大量使用、依赖浏览器表单、且审批流还绑在 SharePoint 2010 上的场景；低优先级是离线邮件分发、月度使用一次的简单采集。迁移时不必一步到位，常见做法是先用 SharePoint 列表加简单的页面布局替换占用最大的表单，再逐步把带业务逻辑的表单迁到 Power Apps 或 Dynamics 365 模型驱动应用。

迁移中的常见错误是试图把 InfoPath 的规则原样搬到新平台。InfoPath 的规则是在客户端或服务器端对 XML 数据做转换，Power Apps 里的逻辑是事件驱动的表单逻辑，两者思路完全不同。正确做法是重新梳理业务规则本身，而不是逐条翻译旧规则。字段校验这类简单逻辑可以直接对应，但复杂计算和跨表单数据联动，应该剥离开来单独设计。

如果你现在的处境是在维护一个还在用 InfoPath 2007 的老系统，我的建议就一句话：先导出所有 xsn 源文件，再开评估会。做这两件事不花多少成本，却能避免将来整个表单库无法打开时两手空空。希望这篇笔记能帮你把老表单这个包袱平稳放下。

本文还有配套的精品资源，点击获取