Migrating a VPN: Licenses, Features and Policy as One Record

Sessions that still work on the old concentrator feel like evidence that the migration is mostly done. They are one inventory item, and the least interesting one. What the cutover needs is a record that ties the target gateway, the supported client, the purchased entitlement and the enforced admission policy into a single artefact somebody owns. Without it, the migration is a series of assumptions that each look reasonable alone.

Four Columns, Not One Checklist

What the hardware can carry, what the contract allows and what the rule set permits are three separate questions, and mixing them produces a plan nobody can audit. Keep them in separate columns and make each one cite its source. A device that accepts a connection proves that a device can connect, and it explains nothing about feature scope or counting basis. Three columns that disagree are far more useful than one paragraph that sounds confident.

The record is finished when all four columns are filled by someone entitled to fill them. A column signed by the wrong owner is a rumour with a date on it.

Platform and Entitlement

Record the supported gateway, the client operating systems, the authentication path and the management tooling. Do not keep an obsolete client alive simply because its old profile still opens, since that profile is a compatibility claim the vendor may no longer honour. Check the current support statement against the release you plan to deploy.

For entitlement, record the product, the license type, the term and the counting basis, then reconcile it through the account owner. Inferring rights from a historical session counter is how an organisation discovers a shortfall after the cutover rather than before it.

Vendor ordering guides illustrate why the distinctions matter. Cisco's Secure Client ordering guide, for instance, splits Advantage, Premier and VPN Only tiers, each with its own measure and feature scope. Use the current agreement rather than translating an old label mechanically.

Features and Enforced Policy

List the capabilities the deployment actually needs: permitted tunnel modes, device assessment, authentication integration and any other module. Check support and entitlement for each one separately, because a feature can be supported and unlicensed, or licensed and unsupported on the chosen release. A row that says yes to both questions is the only one that counts.

Where the target is an ASA, the feature column is read off the box rather than out of a contract, so capture the gateway before cutover day. show vpn-sessiondb summary gives the live session inventory and the counts your entitlement is measured against, show vpn-sessiondb detail anyconnect shows which client type and profile each attributed session actually used, and show running-config webvpn captures the gateway configuration those sessions depend on, which is the one part of the record no licence document can contain.

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

After cutover, run the same three on the new gateway and diff them against the captured copies. Session counts moving is expected; a client type or a webvpn stanza appearing on one side and not the other is the finding, and it belongs in the record with an explanation rather than in a ticket comment. Save the raw captures as well as the diff, because the next reviewer will want to see what was compared. On another vendor the equivalent is that platform's own session table and profile export, in a format that will not line up, so compare the questions asked of it rather than the text.

Then map users and devices to the target's rules, resource permissions and rejection behaviour. A license that enables a feature is not a configuration that exercises it, and the gap between those two is where most migration surprises live.

Write the rejection cases down with the same care as the permitted ones. A plan that only proves an administrator can connect has tested the easiest path and none of the boundaries.

Accept on Both Sides of the Decision

Before cutover, run an approved acceptance plan across the intended client types, the authentication methods and the resources. Include a device or identity that must be rejected, and confirm which rule selected it and what the resulting session may reach. Agree the deny cases before the change window opens, so nobody can quietly drop them under time pressure. A plan with no deny case has tested the happy path and nothing else.

Keep a rollback path and a management route that does not depend on the thing being migrated. Preserve the configuration and the identity records securely, and leave obsolete cryptographic settings behind rather than carrying them forward. Never paste license identifiers or user records into public notes.

Have the owner sign the entitlement and the policy mapping together. The finished record answers two questions at once: what the organisation is licensed to deploy, and which rules actually admit and constrain its users.