IOS 到 ASA 的 VPN 迁移：要迁移的是约定，不是 CLI
crypto map 并不等同于 ASA 的 tunnel-group。约定中哪些部分可以迁移、哪些必须重建，以及证明服务确实可用的那些检查。
作为 ASA 迁移参考送到手上的 IOS 配置，描述的是一份包在某个平台语法里的约定。对端地址、身份与保护范围才是这份约定。密钥环、配置文件与 crypto map 组成的链条，是 IOS 表达约定的方式；ASA 则用隧道组及其属性表达同样的意图。照抄第二部分从来行不通，而只抄第一部分会让工作只做了一半。
按顺序走完下面五个步骤，凡是遇到两个平台描述的是不同事物、而不只是不同措辞的地方，就停下来。
第 1 步：把约定与语法分开
把交接写成两位管理员都认可的条目。四行几乎能覆盖全部：对端在哪里、由哪一侧发起，每一侧如何证明自己的身份，可接受什么样的保护，以及哪些应用必须能在隧道里存活。这些行里没有任何一行提到命令。
把原文当作证据，而不是当作指令。某个平台上存在、另一个平台上不存在的行，在你确认同一需求能否用别的方式满足之前，只是一个语法差异。
| Requirement | What must be agreed |
|---|---|
| Peer delivery | Outer endpoint, address family, NAT view, initiating side |
| Authentication | IKE version, expected identities, credential method and delivery |
| Data protection | Permitted suites, protected ranges, intentional translation |
| Application | Routes, return routes, resources beyond the tunnel |
第 2 步：在两个平台上分别命名对象
在 IOS XE 上，IKEv2 密钥环供给 IKEv2 配置文件，而该配置文件通过 crypto map 或 IPsec 配置文件挂接。在 ASA 上，隧道组容纳连接配置文件及其 IPsec 属性，crypto map 指向它，正如连接配置文件指南所描述的那样。这些是继承关系不同的对象图，因此逐行映射得到的配置能通过解析，却连不上。
从需求行而不是从源配置行来构建目标对象。如果这些行是完整的，目标配置就只是一个设计决策。如果不完整，再怎么翻译命令也补不出缺失的意图。
第 3 步：迁移的是身份，不只是地址
身份是最容易悄悄出问题的部分。按地址认证的对端，与按证书主题或 FQDN 认证的对端行为不同，而两个平台把这份预期记录在不同的地方。要保留预期的身份与信任链，而不是因为共享密钥更好测试就替换成它。
把预共享密钥留在比对笔记和工单之外。记录它归谁所有、如何通过批准的渠道流转，并记住：文档示例里的占位符不是客户的凭据。
第 4 步：在切换前就把保护谈定
不要因为旧加密设置出现在提供的文本里，就把它沿用下去。商定一套双方已部署对端当前都支持的套件交集，并在变更窗口之前与另一位管理员确认。如果这个交集与现有对端的预期不同，那就是一次协调变更，而不是本地改动。
把商定的集合写下来。两位管理员对同一通电话记忆不同，正是一次切换产生第二阶段不匹配的原因。
第 5 步：验证服务，而不是语法
先检查目标端的生效对象，再检查已接受的关联，然后检查一次真实的应用流及其回程。命令敲进去不报错，只证明语法，别的什么也证明不了。隧道起来了却不承载流量，通常意味着保护范围或回程路由与对端不一致，那是需求行的问题而不是命令的问题。再次改动 crypto map 之前，先比对两侧的保护范围。
记录你验证了什么、用了哪些地址、从哪一侧验证。这份记录能把「VPN 已经起来」这种含糊说法，变成另一位管理员可以独立核查的东西。
要交回什么
交回需求矩阵、目标配置摘要和验证结果。明确说明哪些源设置没有沿用，以及为什么。这份清单比译好的配置更有用，因为下一次分歧会从那里开始。
同时把源文本和工单放在一起。源文本记录当初要求了什么，而矩阵记录双方商定了什么。