Skip to main content

Tutorial: How to Migrate an Access Server Installation


There are considerations and preparations that you should carefully look at before migrating an Access Server installation. Here's more information.


This tutorial provides helpful steps for migrating an Access Server installation to a new server and includes information about upgrading Access Server during the process.

  • An installed Access Server.

  • Knowledge of your server's license type (covered in step 1).

  • Knowledge of how clients connect — via IP address or hostname (covered in step 2).

  1. Sign in to the Admin Web UI.

  2. Click Configuration > Activation.

  3. Take note of your activated license key to determine the type. For description and examples of the license types available, refer to License keys for Access Server.

  4. Now that you know your license type, refer to the appropriate section below to understand how it affects an upgrade/migration.

Subscription license key

A subscription license key offers the easiest user experience for upgrading and migrating Access Server. You can activate a subscription license on more than one server at a time, and you can activate it on the old and new servers simultaneously as you migrate.

Fixed license key

A fixed license key requires you to work with our support team to reissue the license key for the new server because they are locked to one server. You can contact us before your server migration, as the old license key will still function for up to two weeks, giving you time to migrate your settings to the new server and test things out.


We only assist in solving problems with license keys if the license keys are still valid.

AWS tiered subscriptions

You can purchase your connections through AWS when you launch a per-licensed Amazon AWS image. Amazon's system then manages licensing and billing for your instances. You can set up a new instance and migrate your data there.

For example, if you want to switch from a 10 connected devices instance to a 25 connected devices instance, you would backup your old instance's Access Server configuration, restore it to the new instance, update the DNS recording pointing to your Access Server or reattach the old elastic IP to the new instance, and then take the old instance down (to avoid incurring extra costs).

Perpetual licenses

Perpetual licenses are our oldest license keys, which we no longer sell. We honor the original license terms, including that they don't support upgrades. However, because you lose this license key when you upgrade, we recommend purchasing a new subscription license key.

Your users and clients can connect to your Access Server in two ways:

  1. Using the server's IP address.

  2. Using a fully-qualified domain name (FQDN) or hostname.


You can connect to the Admin Web UI and Client Web UI for your Access Server using either the IP address or a hostname.

Which of the ways above your users and clients connect will determine how impacted they'll be by a server migration. Refer to the section below that fits your setup:

If your clients connect using the IP address, this will likely change when you migrate servers, and clients will no longer be able to connect. Existing client installations will need to download new connection profiles—unless you can associate the same IP address with the new server (such as with an Elastic IP in AWS).

We recommend setting up a proper hostname, such as, so you don't have to update clients and connections should the server's IP address change:


If you're on Amazon AWS and your old server has an Elastic IP, you can disassociate the Elastic IP from the old instance and associate it with the new instance. Then, you don't need to update any DNS record or IP settings.

If your clients connect using the hostname, you’ll only need to update the DNS A record with the new IP address once you’ve migrated servers.


It is worth noting that an FQDN DNS address is required to install and work with a properly validated and signed SSL certificate on your Access Server, and we recommend this.

Once completed, you have a backup of configuration files in /usr/local/openvpn_as/. They all end in .bak and contain everything unique about your Access Server installation.


If you have an Access Server subscription, this is included in the above backups and works on the new server when you restore the data. Fixed license keys can’t be backed up or copied over, and the only way to migrate those is to contact support and request a fixed license key reissue.

If you use PAM, LDAP, RADIUS, or SAML authentication:

The backup commands create a backup file of users and passwords for local authentication.

If users authenticate with PAM, their passwords are stored in the operating systems. The backup commands in the tutorial don’t back up PAM users or passwords.

Passwords for user authentication with LDAP, RADIUS, or SAML are stored in those systems and are not involved in the Access Server migration process. Ensure the new installation can reach those systems when you migrate.

  • Restore the backup files to your new Access Server installation:


    You can’t combine Access Server configurations. When you run these commands to replace configuration files with the backups, any configuration on the new server is wiped out and replaced by the contents of the backup files.


    There are a few caveats to note for your configuration backup:

    1. If you restore a configuration backup to another server, you might have your system configured in a specific way that doesn't work on the new server installation. For example, if you set Access Server to listen on a specific IP address, you may run into issues where the web interface won’t respond if the new server’s IP address is different. To resolve this, check the section on resetting the interface and port for the web services to listen on to default settings. You can reconfigure your settings once you have access to the Admin Web UI. Alternatively, you can manually configure the web server settings using the command-line tools.

    2. The configuration database also contains the setting on how many TCP daemons and UDP daemons to launch. If this is set higher than available CPU cores, Access Server may become unstable. So if you have restored this configuration on a different server, and the amount of CPU cores is different from the server the configuration backup came from, adjust this on the Network Settings page in the Admin Web UI or use our reset commands for the OpenVPN daemons.

    3. If you’re using an Amazon AMI, you can either update the DNS record to point to the new public IP or move the elastic IP (if you have that—it's not available for every system on Amazon) to the new server instance. Then, you can take the old instance down.

Access Server 2.10.0 and newer no longer creates the system user, openvpn. Instead, it’s created as a local user in Access Server’s user database.

  • If you migrate configuration from Access Server 2.9.6 and older, you need to create this system user with these commands:

    adduser openvpn
    passwd <SET_PASSWORD>

Before you switch over to the new server and shut down your old server, you can test a connection from your machine using the local hosts file.


The local hosts file lets you manually map FQDN entries or hostnames to IP addresses. There are programs for your operating system (such as Hosts File Editor for Windows) to edit the hosts file to point a specific hostname to a specific IP. Using your preferred method, follow these steps:

  1. Open the hosts file with administrator privileges.

  2. Add the IP address of your new VPN server.

  3. Point it to your hostname, such as

  4. Test your connections to the new server:

    • Can you access the Admin and Client Web UIs?

    • Can you connect to the VPN server with your existing OpenVPN Connect connection profile?

  5. Once your tests pass, you can update the DNS record to point to your new server so all users switch over.

Finally, update the DNS record to point to your new server so all users switch over.