瑞士联邦政府正在把办公软件迁移从概念讨论推进到规模化试点：计划在 3000 名联邦雇员的工作站上，以开源协作平台和办公套件替代 Microsoft 365，并以 2027 年底作为迁移目标。3000 台工作站约占联邦雇员总量的 7%，联邦总理府为项目投入了 900 万瑞士法郎。
这不是一次直接覆盖全组织的切换。在扩大到 3000 人之前，瑞士方面已经通过「PoC BOSS」进行可行性验证，共有 172 名雇员参与试用 openDesk。这个推进顺序值得关注：先用小规模用户验证技术和工作流程，再扩大到足以暴露组织级问题的规模。
3000 台的意义不只是安装软件
从客户端部署角度看，3000 台并不算特别庞大。真正困难的是办公平台背后的协作边界：文档格式、宏和模板、共享权限、身份认证、邮件与日历、外部单位交换文件，以及用户已经形成的操作习惯。
因此，衡量试点不能只看“软件能否启动”。更实际的指标包括：
- 常用文档能否保持版式、公式和批注；
- 带宏的表格和历史模板有多少需要重写；
- 内外部文件交换是否仍然顺畅；
- 身份、权限和离职回收流程能否被审计；
- 用户完成高频任务所需的时间是否明显增加；
- 遇到兼容问题时，是否存在明确的例外和回退机制。
3000 人约占联邦雇员的 7%，这个比例提供了一个有价值的中间层：范围足够大，可以覆盖多个部门和复杂工作流；同时又没有把整个组织一次性置于迁移风险之中。
预算应花在迁移能力，而不只是许可证
900 万瑞士法郎不能简单理解为购买另一套办公软件的费用。开源产品可能降低许可证依赖，但不会自动消除集成、迁移、培训和运维成本。
一个可持续的预算模型通常需要覆盖文档兼容性治理、身份系统集成、数据迁移、自动化部署、用户支持、安全评估、供应商或社区支持，以及关键业务流程的改造。迁移后还需要保留可量化的运行指标，否则组织很难判断成本究竟是下降了，还是从许可证转移到了人工支持和兼容处理。
另一个边界是“开源”不等于“无需供应商”。政府仍需明确升级节奏、漏洞响应、数据托管、灾难恢复和退出机制。真正降低锁定风险的，是开放格式、可迁移数据、可替换组件和组织自身的运维能力。
可以这样实践：先盘点文件兼容风险
在部署新套件之前，可以先扫描共享目录或用户文档目录，统计常见办公格式，并单独标记宏文件和旧格式。下面的脚本只使用 Python 标准库，不读取文档内容，适合作为初步盘点工具。
将扫描路径替换为实际目录后运行：
#!/usr/bin/env python3
from collections import Counter
from pathlib import Path
import argparse
import csv
OFFICE_EXTENSIONS = {
".docx", ".xlsx", ".pptx",
".doc", ".xls", ".ppt",
".docm", ".xlsm", ".pptm",
".odt", ".ods", ".odp",
}
MACRO_EXTENSIONS = {".docm", ".xlsm", ".pptm"}
LEGACY_EXTENSIONS = {".doc", ".xls", ".ppt"}
parser = argparse.ArgumentParser()
parser.add_argument("root", type=Path, help="Directory to scan")
parser.add_argument("--report", type=Path, default=Path("office-inventory.csv"))
args = parser.parse_args()
counts = Counter()
risky_files = []
for path in args.root.rglob("*"):
if not path.is_file():
continue
ext = path.suffix.lower()
if ext not in OFFICE_EXTENSIONS:
continue
counts[ext] += 1
if ext in MACRO_EXTENSIONS:
risky_files.append((str(path), ext, "macro-enabled"))
elif ext in LEGACY_EXTENSIONS:
risky_files.append((str(path), ext, "legacy-format"))
with args.report.open("w", newline="", encoding="utf-8") as handle:
writer = csv.writer(handle)
writer.writerow(["path", "extension", "risk"])
writer.writerows(risky_files)
print("Format counts:")
for ext, count in sorted(counts.items()):
print(f"{ext:6} {count:8}")
print(f"Risk report: {args.report}")
python3 inventory.py /srv/shared-documents --report office-inventory.csv
这个清单不能代替真实兼容性测试，但可以帮助项目组选择试点样本。例如，宏文件密集的财务团队和只处理普通文档的行政团队，不应该使用同一套迁移假设。
进一步实施时，可以把成功标准写入版本控制，而不是只放在会议纪要中：
pilot:
population: 3000
target_completion: "2027-12-31"
gates:
document_round_trip_success: 0.98
critical_workflows_tested: 1.00
account_deprovisioning_sla_hours: 4
unresolved_severity_1_incidents: 0
exceptions:
require_owner: true
require_expiry_date: true
review_interval_days: 90
这些数值只是可调整的实践示例，并非瑞士项目公开指标。关键在于让每个门槛都有测量方法、负责人和失败后的处理动作。
从试点走向正式迁移
这项试点最值得借鉴的并不是某一个开源产品，而是迁移节奏：172 人的可行性验证回答“能不能做”，3000 人的阶段则要回答“能不能稳定运营和扩大”。
准备类似项目时，可以用四项检查收尾：建立真实文件和工作流清单；按岗位风险选择试点用户；为不兼容场景设置有期限的例外；同时测量许可证、支持、集成和培训的总成本。只有这些数据持续可见，开源替代才会从部署项目变成可治理的长期能力。