Below is a list of frequently asked questions (FAQs).

Can’t find an answer to your question? Contact VirtaMove Support.

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?

 

No, VirtaMove does not migrate IIS binaries. When migrating IIS-based applications, VirtaMove leverages IIS itself and migrates configuration, web content, security, and 3rd-party plugins.

Encapsulating an application in a temporary VirtaMove container makes the application portable, because a container is essentially a directory of files that the VirtaMove runtime interprets. This makes it easy to provision additional cloud instances and to rehost a VirtaMove-prepared application. Scaling out a web-serving tier, for example, is as easy as provisioning new instances and makes it easy to spawn the hosting of the VirtaMove container multiple times.

VirtaMove is hypervisor agnostic and cloud independent. VirtaMove software has no ties to hypervisors or service APIs. This means that the VirtaMove migration solution works and is valuable anywhere the Windows Server operating system exists.

The temporary container houses the application and all associated data files. Therefore, all changes made by the application remain within the VirtaMove container.

Yes. You can create independent VirtaMove containers for each tier of an application set, allowing you to migrate applications to different destination servers. In addition, VirtaMove’s “Config-on-the-Fly” process ensures that identity-related application settings are resolved appropriately on each destination server.

All VirtaMove commands and functions are available from the CLI, making the creation and administration of VirtaMove containers fully scriptable. This allows VirtaMove to integrate with solutions for release and configuration management using any deployment.

VirtaMove understands fundamental windows application concepts like DCOM and Windows side-by-side, and knows how the implementation of these concepts varies for each Windows Server release. VirtaMove can discover, copy, and install an application component in the way that the destination OS expects.

Yes. VirtaMove can be used to migrate applications to new Citrix environments or to standalone servers, if the targeted applications have been traditionally installed and have not already been encapsulated in a virtualization or redirection layer.

By default, VirtaMove uses the SMB protocol (Windows File Sharing), which runs over port 445. The default port for migrations using VirtaMove Source Agent is port 9665; however, the port number is configurable. Any specific firewall or port requirements that the targeted application requires will need to be enabled or configured on the destination server.

The VirtaMove solution offers subscription-based, software products and services that help customers automate the movement and migration of applications from outdated servers to new Windows Server operating systems, servers, and VMs, in a datacenter or on the cloud.

VirtaMove supports movement of COTS and bespoke applications. Given the tens of thousands of custom and Commercial-Off-The-Shelf (COTS) applications installed in the enterprise environment today, VirtaMove does not maintain an exhaustive list of supported applications. However, VirtaMove can migrate over 95% of Windows Server applications installed in the enterprise today. VirtaMove maintains a list of applications that have been successfully migrated using VirtaMove software.

Click here to see our support policies and guidance on applications that are known to be incompatible.

Yes, operating system modernization is a key advantage of VirtaMove. VirtaMove will identify and migrate applications from Windows Server 2003, 2008, & 2012 to WS2012, WS2016, and WS2019. We also move 2016 apps to new WS2016 instances. If you need to up-level your application to a modern Windows OS, we will move it. For more information about up-level migrations and limitations, see VirtaMove Support Policies.

Every 64-bit Windows Server operating system has 32-bit functionality within the WoW64 (Windows 32-bit on Windows 64-bit) subsystem. VirtaMove leverages the subsystem of the destination OS, correctly placing objects and components for proper execution on the new system.

VirtaMove uses a process called “Config-on-the-Fly” to monitor for identity-related characteristics (server name, IP address, etc.) that an application may “internalize” (config files, registry, etc.) and modifies these values to match the values of the destination server.

VirtaMove is installed on the destination server and the migration process is driven from there. However, VirtaMove offers the option of using the VirtaMove Source Agent on source machines in a network to accelerate application migrations.

While VirtaMove virtualizes applications through the migration process, it is not a standalone virtualization platform.

OS copy tools do not migrate existing production applications to a new OS platform. Instead, they make copies of entire servers or virtual machines (VMs) with identical OS characteristics. What’s missing is the ability to take only required applications to a new OS platform. Additionally, there is no way to separate outdated software, event logs, dirty file systems, embedded malware, and all the other baggage that accompanies enterprise applications over time.

VirtaMove provides the ability to move unmodified server applications from older operating systems (such as WS2000 or WS2003) to newer OS versions (WS2008 or WS2012) on new machines. It automatically detects, separates, and migrates applications from the underlying operating system by packaging nearly all types of Windows Server applications in portable containers.

VirtaMove focuses on the application rather than on the entire machine and encapsulates the application into a migration container. Instead of migrating entire server images, VirtaMove allows you to migrate selected applications and their data.

A container consists of only an application and its associated configuration and data. Containers can be moved from host to host. A virtual machine is a complete host (OS + all applications + all event logs, etc.) expressed as software. A container is much smaller and more agile than a VM.