Moving VPN access to a new Mac: what to record first
A copied connection name is not a migrated identity. Record the client, profile source and authorization path, then provision and test the new Mac.
Migration fails quietly: the connection appears in the menu bar, the profile imports, and authentication still fails because the new Mac is not an authorized device. The old Mac keeps working, which makes the failure easy to postpone until the old machine is gone. A short inventory taken before the switch prevents most of it. Write down what the access depends on while you can still read it from the working machine.
Inventory the access while the old Mac still connects
Start with the client and the protocol, not with the connection name. The name is a label the old profile chose; the client version, the protocol and the endpoint are what the new machine has to reproduce. Note the exact endpoint hostname as well, because a provider migration can move it without changing the label.
| Item | Where to read it | Why the new Mac needs it |
|---|---|---|
| Client and version | About screen or vendor download page | Profile format and defaults change between major versions |
| Profile source | MDM, vendor portal, exported file | Decides whether import or re-enrollment is supported |
| Identity type | Certificate, account login, SSO | Decides whether it can move or must be reissued |
| DNS and routes | Tunnel settings, split-tunnel rules | Same tunnel can behave differently with different resolver settings |
| Owner | IT, provider or you | Names the party who can approve the new device |
The identity entry carries the most weight. A username and one-time code can be entered on the new Mac, a certificate with an exportable key can sometimes be imported, and a device-bound certificate with a non-exportable key cannot move at all. Record which one you have before planning the cutover. If two of those answers disagree, resolve the disagreement before you copy anything.
Finally, note the expected network behavior: full tunnel or split tunnel, which internal names must resolve, and whether IPv6 is expected to travel inside the tunnel. These become the tests that decide whether the migration worked.
Separate what can be copied from what must be reissued
User-level profiles, server addresses and preferences are usually portable. Private keys, device certificates and enrollment tokens are not, because their value depends on being bound to one machine. Treat those as reissue items and ask the owner for the supported path. Everything else is a candidate for copying. The owner's process, not the migration wizard, decides which category applies.
Stop here if the identity is device-bound and no reissue route exists. Continuing with a copied key either fails at authentication or, worse, leaves the same credential active on two machines with no record of the second one.
Do not park a private key or a recovery code in a note or a chat message during the move. Use the keychain, the password manager or the organization's escrow process, and re-enroll the authenticator rather than copying its seed. A migration note that contains a credential becomes a second copy of the credential.
Provision the new Mac through the supported path
If the Mac is managed, enroll it in the same management system before adding any manual configuration. The management system owns the enforced profile, and a hand-imported profile on top of it creates two sources of truth that disagree after the next policy change.
On an unmanaged Mac, install the client from the vendor's current download and import the profile through the method the vendor documents. Recent macOS releases require approval for VPN configurations and system extensions in Privacy and Security, and an extension may need a restart before the tunnel can start. Apple documents the manual VPN setup path if you need to compare it with the vendor app.
Remove duplicate definitions once the new one works. A stale entry in Network settings and the app's own profile can both point at the same endpoint, and the one that connects is not always the one you think you edited.
Test the paths the new Mac will actually use
Connect and confirm the tunnel is carrying traffic, then check name resolution and routing rather than trusting the menu bar icon. macOS reports resolvers per interface, so the internal DNS server should appear for the tunnel interface and internal names should resolve through it. Both commands below only read state.
scutil --dns | head -40
netstat -rn -f inet | head -20
netstat -rn -f inet6 | head -20Stop if an internal hostname resolves to a public address or if the default route still points at the physical interface when the design expects a full tunnel. Both are signs that the profile imported without its routes or that another configuration is overriding it.
Repeat the test after sleep and after joining a different network. A connection that survives the first login but not a lid close is a migration that will fail in daily use, and catching it before the old Mac is erased is the point of the checklist.
Retire the old Mac and revoke it
Keep the old device connected until the new one passes the tests above. Then revoke the old device through the operator's console or the management system; deleting the app from the old Mac does not revoke its identity, and a copied profile can still authenticate.
After revocation, remove the profiles, sign out of the account and erase the disk if the machine is leaving your control. Check the provider's device list one more time to confirm the old entry is gone and the new one is labeled correctly.
If a shared secret or a team credential was copied during the move, rotate it now rather than waiting for the next scheduled change. The migration is finished when the old identity is dead, not when the new icon turns green.