This article is only applicable to customers running AppsAnywhere 2.8 or earlier.

From version 2.9 onwards, AppsAnywhere is provided as a virtual appliance.

This means that unlike previous upgrades, the process is actually a migration from your existing servers to the new virtual appliance based servers.

Your existing AppsAnywhere servers will remain operational until the scheduled migration window, at which point the new servers will take over delivery of your app portal.

Once service is transitioned to your new servers, your old servers can then be retired.

This process refers exclusively to AppsAnywhere servers. Cloudpaging and Parallels RAS servers will continue to be upgraded in the usual way.

The AppsAnywhere team will be in touch via a support ticket to provide an AppsAnywhere Deployment and Migration Guide for each customer.

In addition, the following information is available so that you can plan ahead.

Preparing for Migration

To help you prepare and to support you through this process, the AppsAnywhere team will create a support ticket for all customers, including a Migration Guide.

You will need to create the same number of new virtual appliance based servers, to match the number of existing AppsAnywhere servers that you currently have.

Your Migration Guide document will provide a place to record details of your new servers for sharing with the AppsAnywhere team.

The high-level process is as follows:

  1. Deploy the new virtual appliance, once for each server required.

  2. Complete first-time configuration for each new appliance based server.

  3. Ensure that the Network Requirements are in place (including some new connectivity).

  4. Provide details of your new servers and remote access to the AppsAnywhere team.

  5. Schedule the migration window for your live service with our support team.

If you have any questions about your migration to the AppsAnywhere appliance, our team will be able to help via the support ticket we will create.

Your existing database (and load balancing solution) will continue to be used. The database schema will be updated by the AppsAnywhere team during the migration procedure.

Planning your Migration Window

During migration your AppsAnywhere service will be temporarily unavailable for a short time.

Unfortunately this is unavoidable, so the AppsAnywhere team will make every effort to reduce the length of time that the service is offline.

Customers should notify service users of:

  • Service at Risk Period – number of AppsAnywhere servers x 20 minutes

  • Service Downtime – starting approx. 5 minutes in and lasting until 5 minutes from the end of the Service at Risk Period

One of the benefits of moving to the virtual appliance, is that downtime for upgrades is reduced. We are also working to make it possible for customers to carry out your own upgrades in future, to provide greater flexibility for scheduling and less reliance on the AppsAnywhere team.

As per our Service Level Agreement, migration to the AppsAnywhere appliance will need to take place during our business hours of support.

However, we will work with you to schedule a suitable time, taking advantage of our support personnel in different timezones wherever possible.

Pre-migration Requirements

Customer Contacts

Most of the migration procedure will be carried out by a AppsAnywhere engineer.

However, the following customer personnel will need to be involved and available for the duration of migration window:

  • AppsAnywhere administrator

  • Load Balancer administrator

Contact details must be provided for at least one lead customer contact.

It is also advisable that the following customer personal can be contacted in case of any issues:

  • Hypervisor / server administrator

  • Database administrator

  • Network administrator

  • Active Directory administrator

Remote Access

The AppsAnywhere team will require remote access to all AppsAnywhere servers for the duration of the migration procedure.

Remote access to the new virtual appliance based servers may require a new method of access, as noted under Network Requirements.

More details on options for remote access will be provided in your Migration Guide.

Test Machine

To confirm that migration is successful, your AppsAnywhere engineer will need a test user account and access to a test machine.

This is used to verify that single-sign on is working and that apps can be launched successfully.


Although your pre-existing AppsAnywhere servers will not be changed, it is still advisable to take a server snapshot prior to migration.

A full backup of the AppsAnywhere database must be taken prior to upgrade. This backup can be done by the AppsAnywhere engineer if required, providing the relevant access and permissions are in place.

Migration Procedure

Ahead of the upgrade AppsAnywhere will confirm that all prerequisites are in place.

We will also establish a line of communication with your AppsAnywhere administrator, to be maintained through the migration process.

Your AppsAnywhere administrator will need to coordinate, and ensure that the customer actions noted in the below table are carried out promptly.



Performed By



Backup the AppsAnywhere Database.

Customer or the AppsAnywhere team


Configure your Load Balancer to point to a maintenance page, by draining and taking the AppsAnywhere rules offline.




Disable all services on the existing AppsAnywhere servers (the servers must remain online).

the AppsAnywhere team


Configure the first new AppsAnywhere virtual appliance, and clone the settings to each additional server.

the AppsAnywhere team


Testing of each new AppsAnywhere appliance server individually.

the AppsAnywhere team


Configure your Load Balancer to remove the old servers, add the new AppsAnywhere servers, and bring the rules online.




Testing of AppsAnywhere via the load balancer, and customer sign-off.

Customer and the AppsAnywhere team


Functionality Tests

During migration, services will be tested (including via the load balancer) to confirm functionality.

Tests will be performed from the designated test machine and include:

  1. Login (manual and SSO).

  2. Validation and basic portal functions.

  3. Launch of applications (including Cloudpaging and Parallels RAS where applicable).

  4. Access to the admin interface and confirmation of version numbers.

Issues During Migration

Your AppsAnywhere engineer will keep you informed should there be any issues during migration.

The first action will be to review the deployment logs which detail each step of the process along with any errors that may have occurred.

In almost every case, the deployment logs provide enough information relating to a failure for the issue to be resolved and for migration to be completed successfully.

  1. Review deployment logs for errors

  2. Correct cause of errors where possible

  3. Complete the migration procedure

If there is a problem during the migration process (and there is insufficient time remaining to investigate), your AppsAnywhere engineer will discuss this with you and ask for authorization to commence rollback procedures.

Rollback Procedure

There are two main scenarios in which a rollback is advisable:

  1. A significant problem is encountered during the migration procedure and the remaining window is unlikely to allow for investigation and resolution.

  2. Migration is completed but AppsAnywhere does not function as desired, as determined by the post-upgrade functionality tests.

In either of these cases, service can be reverted to your pre-existing AppsAnywhere servers.



Performed By


Configure your Load Balancer to point to a maintenance page, by draining and taking the AppsAnywhere rules offline (if not already done).



Disable the AppsAnywhere appliances.



Restore the backup of the AppsAnywhere Database.

Customer or the AppsAnywhere team.


Re-enable pre-existing AppsAnywhere server services.

the AppsAnywhere team


Configure your Load Balancer, restoring rules for your pre-existing servers (and removing any rules for the new servers if applicable).



As your existing AppsAnywhere servers will be unchanged, it is highly unlikely that a situation could occur where service is not restored.

However, in a worst case scenario AppsAnywhere engineers can perform a full re-installation of AppsAnywhere 2.8 to your pre-existing servers.

Retiring Old Servers

The AppsAnywhere team recommend that you retain the database backup and pre-existing AppsAnywhere servers (e.g. as a backup or powered down) for at least 2 days following migration.

In the unlikely event that a critical issue arises, you then have the option to rollback, or to investigate the previous service state.

Once the new version of AppsAnywhere is in general use, you can then retire your old servers and delete previous backups.