IOS-to-ASA VPN migration: translate the agreement, not the CLI
A crypto map is not an ASA tunnel-group. Which parts of the agreement transfer, which have to be rebuilt, and the checks that prove the service works.
An IOS configuration that arrives as the reference for an ASA migration describes an agreement wrapped in one platform's syntax. Peer addresses, identities and protected ranges are the agreement. The key ring, profile and crypto map chain is how IOS expresses it, while the ASA expresses the same intent through tunnel groups and their attributes. Copying the second part never works, and copying only the first leaves the job half done.
Work through the five steps below in order, and stop wherever the two platforms describe different things rather than different words.
Step 1: separate the agreement from the syntax
Write the handoff as requirements both administrators agree on. Four rows cover almost all of it: where the peer is and which side initiates, how each side proves its identity, what protection is acceptable, and which applications must survive the tunnel. None of those rows mentions a command.
Keep the original text as evidence rather than instructions. A line that exists on one platform and not the other is a syntax difference until you have checked whether the same requirement can be met another way.
| 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 |
Step 2: name the objects on each platform
On IOS XE an IKEv2 key ring feeds an IKEv2 profile, and that profile is attached through a crypto map or an IPsec profile. On the ASA a tunnel group holds the connection profile and its IPsec attributes, and the crypto map points at it, as the connection-profile guide describes. Those are different object graphs with different inheritance, which is why a line-by-line mapping yields a configuration that parses and does not connect.
Build the target objects from the requirement rows rather than from the source lines. If the rows are complete, the target configuration is a design decision. If they are not, no amount of command translation will supply the missing intent.
Step 3: carry identity, not just addresses
Identity is the part that breaks quietly. A peer that authenticates by address behaves differently from one that authenticates by certificate subject or FQDN, and the two platforms record that expectation in different places. Preserve the intended identity and trust chain instead of substituting a shared secret because it is easier to test.
Keep the preshared secret out of comparison notes and tickets. Record who owns it and how it moves through an approved channel, and remember that a placeholder from a documentation example is not the customer's credential.
Step 4: agree the protection before cutover
Do not carry old cryptographic settings forward because they appear in the supplied text. Agree an intersection of suites that both deployed peers currently support, and confirm it with the other administrator before the change window. If that intersection differs from what the existing peer expects, it is a coordinated change rather than a local edit.
Write the agreed set down. Two administrators with different memories of a phone call is how a cutover produces a phase-two mismatch.
Step 5: verify the service, not the syntax
Check the target's effective objects first, then the accepted association, then a real application flow and its reply. Entering a command without error proves syntax and nothing else. A tunnel that comes up and carries no traffic usually means protected ranges or the return route disagree with the other side, which is a requirement-row problem rather than a command problem. Compare the protected ranges on both sides before you touch the crypto map again.
Record what you verified, with which addresses, from which side. That record turns an ambiguous claim that the VPN is up into something the other administrator can check independently.
What to hand back
Send the requirement matrix, a summary of the target configuration and the verification results. State explicitly which source settings you did not carry forward and why. That list is more useful than the translated configuration, because it is where the next disagreement will start.
Keep the source text with the ticket as well. It documents what was asked for, while the matrix documents what was agreed.