周五晚上，旧的WiFi控制器再次过载。酒店前台正在办理入住的间隙重置接入点，零售店正在失去支付连接，医院病房报告临床移动性不可靠，或者管理式公寓的居民在支持办公室外排队，因为租户门户已停止身份验证。迁移计划已经推迟，每一个“临时”融通方案现在都留在生产环境中。
这种情况正是遗留系统迁移的起点。问题不在于硬件或软件过时，而在于组织围绕脆弱的基础设施、未记录的依赖关系、手动管理、过期的支持以及无人敢关闭的身份服务构建了运营模式。本指南将 WiFi、身份和多租户网络服务视为独立的迁移目标，而不是应用迁移后才去处理的管道工程。
为什么遗留系统迁移需要一个真正的计划
出现故障的网络栈极少会孤立地发生故障。酒店 WiFi 中断可能会影响客房准入、物业管理系统集成、会员登录以及客户恢复工作流。零售商可能会失去收银机、支付服务、库存系统和客户 WiFi 之间的连接。在医疗保健领域，依赖链可能包括目录服务、RADIUS、证书、护士呼叫集成、临床设备和移动应用程序。在住宅小区中，共享身份验证服务可能需要支持租户、承包商、大厦工作人员、摄像头、电梯和公共设施。
因此，业务案例是运营层面的，而非表面化的。统计事件、身份验证失败、手动重置、停机分钟数、应急工程时间、过期许可证以及稀缺的备件。然后确定这些失败阻止了什么。迁移可以减少管理开销，提高可维护性，更清晰地暴露覆盖和身份验证问题，简化入驻，并为安全团队进行访问审查提供更整洁的基础。
实用规则：如果业务部门无法解释谁拥有身份源、谁批准策略变更、谁可以授权回滚，那么就还没准备好进行切换。
英国公共部门为推迟升级提供了一个极具参考价值的警示。根据一份 2025年英国议会关于遗留系统的书面答复 估计，遗留系统占2024年中央政府部门系统的28%，高于2023年的26%。同样的数据记录显示，60%的政府数字服务已迁移到云端，然而这一进展历时13年，且仍有28%的资产为遗留系统。大多数部门采用云端并没有消除旧有依赖的核心难点。
同等替换往往只是在更新的品牌标识背后保留了相同的弱点。如果旧平台依赖于共享账户、手动 VLAN 更改、脆弱的 RADIUS 路由或单一管理端点，那么将其移至新硬件只会让故障更加难以识别。围绕所有权、依赖性证据、迁移波次、身份信任、并行运行和回滚来制定计划。最终的结果不是硬件更新，而是在不遗漏访客、临床医生、员工或居民的情况下，淘汰失效的运营模式。
在移动单个工作负载之前评估整个资产
首先进行资产清查，而不是查看供应商的产品演示。建立一个经过验证的登记簿，涵盖每一个控制器、接入点、交换机、防火墙、Captive Portal、目录、证书颁发机构、RADIUS服务器、VLAN、SSID和管理控制台。记录位置、所有者、租户或业务单元、型号、固件、支持状态、观察到的流量、身份验证方法、配置来源以及已知的依赖关系。
“已验证”这个词非常重要。从采购记录中整理出的电子表格会遗漏未管理的接入点、已废弃的集成、临时 SSID 以及本地团队安装的设备。请将配置导出数据与观察到的流量、监控数据、服务工单以及与每个站点支持人员的访谈进行对比。
映射人员、设备和信任关系
将身份作为一个独立的清单进行管理。将员工、承包商、访客、患者、学生、居民、IoT 设备和服务帐户分离开来。针对每个群体，记录信任源、入职和离职流程、凭证生命周期、证书所有权、审批路径以及紧急访问方法。
然后测试具有代表性的工作流，而不是通用的连接性。酒店需要测试入住登记、客房进入、宾客WiFi和物业管理系统对接。零售商需要测试销售点连接、会员登录、手持设备和门店故障转移。医院需要测试临床移动性、联网设备、员工身份验证和病房级弹性。住宅区需要测试租户入驻、共享设施、访客访问以及住户之间的隔离。
依据证据做出迁移决策
根据业务关键性、数据敏感性、兼容性风险和紧急程度对每个资产或工作流进行分类。标记不受支持的协议、证书过期、单点故障、未记录的防火墙规则、硬编码的服务帐户以及数据质量差距。分配负责的所有者，并定义通过每个阶段所需的证据。
| 资产或工作流 | 需要收集的证据 | 风险评级 | 迁移批次 |
|---|---|---|---|
| RADIUS 和目录路径 | 身份验证日志、单一事实源映射、故障转移配置、服务所有者 | 如果跨站点共享，则为高风险 | 早期基础批次 |
| Captive Portal 和访客身份 | 重定向流、凭证或个人资料记录、同意记录、CRM 和 PMS 依赖关系 | 在面向访客的环境中为高风险 | 按站点或租户进行试点 |
| 临床或运营 SSID | 设备注册表、身份验证方法、临床工作流测试、支持窗口 | 在关系到服务连续性的地方为关键风险 | 受控、特定于站点的批次 |
| 多租户服务 | 租户隔离规则、iPSK 或等效配置、SSO 流程、支持归属 | 在合同约定隔离的地方为高风险 | 租户群组批次 |
| 接入点和控制器 | 固件、支持状态、加入历史记录、配置备份、物理位置 | 中到高风险，取决于覆盖范围 | 与已验证的服务批次保持一致 |
供应商可以协助发现资产，但没有任何工具能修复不完整的归属关系图。该登记册应成为项目决策的记录。如果某个项目没有所有者、没有依赖性证据或没有回滚路径，它就不属于上线批次。
选择正确的迁移方法
选择与限制条件相匹配的方法。盲目跟风是糟糕的迁移方式，特别是当网络承载着身份和前线业务时。
重新托管在极少更改的情况下将现有服务移动到较新的基础设施上。适用于紧急的硬件或虚拟机管理程序退出、稳定的RADIUS部署，或仍能预测运行但已达到运营边界的平台。虽然速度很快，但它会带入手动流程、许可假设、配置缺陷和技术债务。
Replatform (重构平台) 在保留服务核心行为的同时更改其运行环境。例如，Captive Portal 可能会迁移到托管容器中，或者目录集成可能会迁移到受支持的服务层。当业务逻辑合理但操作平台成本高昂或难以维护时，这是明智的折中路线。
Refactor (重构代码) 更改内部设计。这可能意味着用策略服务替换静态网络规则、公开 API，或者将身份决策与门户呈现相分离。重构能奠定更好的基础，但与“原样搬迁 (lift and shift)”相比，它需要更明确的产品决策和更多的测试。
绞杀者迁移 (Strangler migration) 让新旧服务协同运行，同时每次只路由一个站点、租户、SSID 或工作流。对于 WiFi 和身份资产，这通常是最安全的默认选择，因为团队可以验证共存性、对比策略结果，并将定义的群组退回到旧平台。
| 方法 | 最适合 | 主要优势 | 主要风险 |
|---|---|---|---|
| 重构托管 (Rehost) | 紧急基础设施退出 | 极小的服务变更 | 保留了设计缺陷 |
| 重构平台 (Replatform) | 具有高成本运行时的稳定集成 | 无需重写即可获得更好的可支持性 | 兼容性工作依然存在 |
| 重构代码 (Refactor) | 策略、API 和编排重新设计 | 更强的长期运营模式 | 更高的交付和测试需求 |
| 绞杀者模式 (Strangler) | 共享身份和多站点网络 | 小群体和快速回滚 | 必须设计共存方案 |
一个切实可行的方案可以重新托管稳定的 RADIUS 平台，重新构建访客门户（guest portal）的平台，并重构策略执行。记录每个工作负载所选择的方法、被拒绝的备选方案、共存期、负责人以及退出条件。评估托管专业服务的组织也可以将 Purple 的专业服务产品 与其内部交付模式一起进行评估。
除非环境简单、同步已得到验证且回滚窗口可承受，否则应避免一次性全面切换。在多租户环境中，“一次性全部切换”通常意味着“所有支持呼叫同时爆发”。
在不破坏信任的前提下迁移数据和身份
身份是迁移的支柱。如果它失效了，即使接入点运行良好、交换机正在转发流量，服务对于需要它的人来说依然是不可用的。
首先映射每个身份验证源。包括 RADIUS 服务器、Captive Portal、物业管理系统集成、Active Directory 林、Entra ID 连接、Google Workspace、Okta、共享服务帐户、设备证书以及本地紧急帐户。确定哪些源将保留、哪些将进行临时同步、以及哪些必须在全新服务开始发挥主导作用之前停用。
精心构建共存环境
分阶段进行目录同步。使用稳定的属性匹配身份，在启用访问权限之前解决重复数据，并定义已停用或已离职的用户如何同步到新服务。不要将迁移作为创建第二个未受控身份目录的借口。每个临时帐户都需要有负责人、过期条件和审计追踪。
证书管理也需要同样的严谨性。对证书颁发机构、模板、签发系统、更新所有权、信任链以及使用 EAP-TLS 或 802.1X 的设备群进行盘点。按照受控的顺序轮换证书，从具有代表性的群体开始。在新的信任链通过所有相关设备类别的身份验证和撤销检查之前，请保持旧的信任路径可用。
“凭据迁移就是服务迁移。应将密码重置、证书更新和账户禁用视为会影响客户的变更。”
访客身份需要一个独立的工作流。在业务依赖于它的情况下，保留个人资料、同意书、凭证、忠诚度记录和回归用户之间的关系。测试注册、回归访问、忘记详情、过期、退订以及支持辅助恢复。访客不应该因为他们之前的访问权限消失了，才发现迁移成功了。
规划访问顺序，而非仅仅是设备
在进行广泛的SSID和VLAN更改之前，先移动身份服务。然后迁移特定的SSID、站点、租户或工作流，同时监控身份验证和流量行为。在医疗保健领域，保持临床和联网设备路径与普通员工访问相分离。在住宅环境中，在更改提供隔离服务的系统时，保持租户隔离。在酒店业中，在向所有客房开放新的宾客流程之前，验证物业管理系统的对接。
在评估身份、安全和数据处理要求时，可以使用 Purple 数据与安全概述 作为参考点。工具的选择次于验收证据。在新身份平面开始接收流量之前，请证明身份验证成功、授权正确、证书信任、目录禁用、门户完成、VLAN分配以及服务中断后的恢复。
真正有效的测试、切换和回滚方案
从回滚计划开始倒推构建切换计划。大多数不完善的计划只描述了如何启用新服务，然后添加一条模糊的“必要时还原”指令。这算不上回滚计划。真正的回滚计划需要明确触发条件、决策者、技术行动、沟通责任人和时限。
将并行运行作为测试手段
在限定的时间窗口内，同时运行传统的和新的身份与网络平面。在架构允许的情况下使用影子 RADIUS 请求、镜像 Captive Portal 流程、配置比对以及合成访客登录探测。测试成功和失败的身份验证、过期证书、已停用帐户、漫游、VLAN 分配、DNS 依赖关系、防火墙行为以及目录或 RADIUS 端点丢失的情况。
按业务群组进行测试。一个酒店机翼、一个零售站点、一个经科室批准的设备组或一栋住宅楼，比排除真实集成的实验室测试更有用。保留一份包含时间戳、测试身份、设备类型、策略结果、缺陷和批准记录的证据包。
制定精确到分钟的操作手册
切换顺序应包括：
- 冻结变更： 停止无关的网络、目录、证书和门户变更。
- 快照状态： 导出配置、记录策略版本、保留身份映射，并确认恢复文件可用。
- 迁移群体： 切换特定的站点、租户、SSID 或工作流，而不是含糊的“环境”。
- 观察行为： 监控身份验证、重定向、接入点加入、支持联系、应用事务和租户隔离。
- 扩大或撤销： 仅在指定的负责人确认退出标准后继续。如果触发了触发器，执行排练好的回滚。
该计划说明指出了一些示例，例如身份验证失败率超过 1.5%、Captive Portal 重定向循环以及接入点加入失败率超过约定阈值。只有在您的基线支持这些示例时才使用它们，并在变更窗口期之前与服务负责人共同设定最终触发器。关键不在于选择一个通用的数字，而在于消除事故处理室中的争议。
与负责生产运行的相同人员一起演练回滚。仅存在于文档中的备用方案，在证书、缓存、路由和人员决策在压力下相互作用时，必然会失败。
成本、时间线与合规性现状审查
供应商乐观的交付评估并不是可提交给董事会的预算。请围绕发现、修复、集成、测试、内部员工时间、支持覆盖、许可、沟通、培训、停机风险和应急预案来构建模型。将网络层纳入交付工作：WiFi设计、身份服务、Captive Portal、证书、路由、租户隔离以及逐站切换支持。如果旧平台无限期地保持运行，那么迁移就谈不上便宜。
英国公共部门为延迟工作敲响了清晰的警钟。数字政府现状审查 记录显示，2024年中央政府系统中遗留技术的占比达 28%。审查还发现，警察部队和 NHS 信托基金的遗留系统比例在 10% 到 60-70% 之间，并提到建立在可追溯至 1970 年代的系统之上的关键服务，并指出了 16 个部门的 153 个系统中存在遗留问题。这些数字并不是私营部门的价格清单。它们展示了为什么依赖项发现和修复应该列入交付预算，而不是被削减的开销额度中。
一份关于遗留 IT 成本的 英国公共部门分析报告 指出，遗留 IT 导致的生产力损失占公共部门年度支出的 4 - 7%。请将该数据作为评估您组织内部运营浪费的参考，包括手动身份识别工作、重复的支持调用、失败的访客访问以及网络服务规避方案。切勿将其直接作为保证迁移能节省的费用来展示。
| 行业 | 参考成本范围 | 典型持续时间 | 关键合规驱动因素 |
|---|---|---|---|
| 酒店餐饮与住宿 | 根据站点数量、访客身份、PMS 集成、WiFi 设计和支持覆盖范围确定评估范围 | 围绕入住率和活动进行排序 | 支付安全、隐私、访问记录、供应商保障 |
| 零售 | 根据门店差异、POS 依赖关系、会员身份、WiFi 和交易窗口确定评估范围 | 在非交易高峰期进行试点，然后按群组逐步推广 | PCI-DSS、隐私、端点控制、可审计性 |
| 医疗保健 | 根据临床工作流、设备验证、无线韧性和变更治理确定评估范围 | 较长的规划和验证周期 | 患者安全、隐私、医疗设备保障、连续性 |
| 住宅与学生公寓 | 根据租户隔离、入网引导、共享设施和建筑系统确定评估范围 | 按建筑或资产组合批次推进 | 隐私、合同隔离、访问治理、供应商控制 |
对于访客网络，在确定设计方案之前，需评估同意书、保留期、访问记录、身份处理和租户隔离。使用 Purple 访客 WiFi 合规性检查工具 来审查该状况并识别需要资金支持的差距。
英国国家统计局（ONS）提供了另一个深刻的教训。关于 ONS遗留系统迁移的报道 指出，尽管在替换80%的遗留服务方面取得了进展，但预算限制减缓了其摆脱遗留系统的步伐。同一来源报告称，90%的组织存在 Microsoft Windows 技术债务，60%的组织拥有许多不受支持的 Windows 服务器或桌面，以及51%的组织报告了与技术债务相关的停机时间。生命周期结束的压力并不能免除对业务连续性规划的需求。
根据 PCI-DSS 4.0、ISO 27001、Cyber Essentials Plus、适用的 NIS2 以及行业特定义务来规划项目。合规性审查会暴露薄弱的假设，因此在变更窗口期之前，应先对控制措施、证据、测试和运营所有权进行估价。
迁移后监控与持续退役
上线是问责的开始。一旦新服务承载了生产流量，团队就需要一个基准，以证明迁移是改善了运营，还是仅仅将相同的故障转移到了不同的控制台中。
在多租户隔离至关重要的情况下，跟踪RADIUS身份验证延迟、Captive Portal失败率、接入点加入成功率、证书更新提前期、策略不匹配、支持联系以及租户级服务目标。为每个信号指定一名明确的所有者、升级路线和评审节奏。没有责任人负责的仪表盘只是摆设。
运行稳定性曲线
采用 30 天、60 天和 90 天的评审节奏。第一次评审应捕获配置漂移、遗漏的警报、循环出现的身份验证故障以及支持性临时解决方案。第二次应测试该服务是否在没有迁移团队干预的情况下运行。第三次则应决定遗留平台是否已准备好停用。
不要仅仅因为新平台在安静的周末正常运行就宣告成功。比较不同业务周期、租户组、设备类别和运营事件的表现。酒店业需要考虑入住率变化，零售业需要考虑交易状况，医疗保健需要考虑经批准的临床工作流，而住宅区则需要考虑租户入驻和公共访问。
分阶段受控停用遗留系统
只有在通过退出标准且业务所有者签字确认后，才能停用遗留服务。然后有条不紊地将其移除：
- 行政关闭： 停止变更、关闭支持渠道、归档已批准的配置并更新所有权记录。
- 信任撤销： 撤销过期的证书、禁用旧的服务账户、移除未使用的目录同步，并消除残留的访问路径。
- 网络退役： 移除遗留的 VPN 隧道、策略、集成和管理依赖项，然后回收地址空间和许可证。
- 知识交接： 将最终的架构、决策日志、测试证据、事件历史和操作规程存储在支持团队可以找到的地方。
一份 英国政府对传统资产复杂性的分析 将传统系统描述为陈旧、脆弱、无法支持且限制了转型。该来源已经确立了这一问题的规模。您在迁移后的工作是确保旧资产不会继续作为一个无人管理的网络安全边界存在。
Purple为访客、员工和多租户环境提供基于云的WiFi身份验证和基于身份的网络连接，并集成了目录服务和网络平台。请访问 Purple 评估其身份、访客访问、分析和迁移功能是否符合您的遗留系统迁移计划。
