Below is a list of frequently asked questions (FAQs).
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.
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.
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 re-host an VirtaMove-prepared application. Scaling out a web-serving tier, for example, is as easy as provisioning new instances and hosting 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.
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.
Yes, operating system modernization is a key advantage of VirtaMove. VirtaMove will identify and migrate applications from Windows Server 2003, 2008, & 2012 to WS2008, 2012, & 2016. 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.
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.