Home » FAQs

Frequently Asked Questions

The core of VirtaMove’s business is migrating applications from older windows operating systems to new ones.  While applications may not be supported by the vendor for a variety of reasons, this does not mean that the application will not work on the new operating system. Even in the case of an application that has a dependency on .NET 1.0, the app may still run successfully on a newer operating system. In all cases, if the application works in the VirtaMove migration container then it will work once the container is Dissolved.

Any application that is targeted for migration can have configuration and/or preferences changes made to it at any stage during the migration, while the application is in the container or once Dissolved.

Yes. VirtaMove Maestro, a GUI-based migration orchestration tool, provides capacity planning data and reporting functions for a target server. Data includes CPU, available memory, disks, and storage.

Yes. VirtaMove supports migration of applications to MS Azure. See also this FAQ.

For information about server requirements, 3rd party application support, and other requirements, see VirtaMove Support Policies.

Yes. There may be a business case for running a migrated application in a container on the new target server; for example, isolation or recovery. There may be a small performance overhead associated with running an app in a container, and there will be a small maintenance fee for doing so in your annual VirtaMove subscription.

In a VirtaMove migration, the application and its dependencies are placed in a temporary container. The application is virtualized, allowing it to remain separated from the underlying operating system of the destination server. The Dissolve function reinstalls the application and its components on the underlying operating system, as if they had been installed via traditional methods. Dissolving removes the reliance on the VirtaMove virtualization runtime. The application appears alongside traditionally installed applications.

Running an application in a VirtaMove temporary container incurs a performance impact of 1-10%. Applications that are compute-orientated may be closer to 1%; applications with heavy file IO may be closer to 10%. This performance impact is typically offset because the destination server hardware is newer and faster than the source server hardware.

Once an application is migrated to the destination machine, you’ll start with exercising or using the services and the entry points of an application (shortcuts present on the source server). An application is considered migrated when the Application Owner or a Subject Matter Expert has tested the application to their satisfaction.

Calculating the amount of time that a VirtaMove migration will take is a factor of application size and complexity, as well as network speed and bandwidth availability between the source and destination servers. The more network latency, the longer a migration will take. Many hops on a network, a low transfer rate, or high packets loss could reduce performance and increase migration time. VirtaMove includes a tool that will test a network for possible latency.

The amount of time that VirtaMove migration will take also depends on operational flexibility, use of migration best practices, and resources assigned to a migration. For information about time estimates, see Moving Apps from 100 Legacy WS2008 Servers: How Long Will it Take and How Much Will it Cost?