Migration Paths for Migrating to a Failover Cluster Running Windows Server 2012 R2
Applies To: Windows Server 2012 R2
This topic provides guidance for migrating specific cluster roles to a failover cluster running the Windows Server 2012 R2 operating system by using the Copy Cluster Roles Wizard in Failover Cluster Manager. The topic covers supported migration paths, provides an overview of wizard-based migration, and notes which cluster roles require special handling during migration.
Migration paths for specific migrations
The following table lists the operating system versions on a source failover cluster that can be migrated to a failover cluster running Windows Server 2012 R2 for each clustered service or application. Migrations between failover clusters created with physical computers and failover clusters that are created from virtual machines (also known as guest clusters) are supported.
Supported migrations for clustered roles and resources to a Windows Server 2012 R2 failover cluster
Clustered role or resource |
From Windows Server 2008 R2 SP1 |
From Windows Server 2012 |
From Windows Server 2012 R2 |
|---|---|---|---|
Cluster Registry settings |
Yes |
Yes |
Yes |
Cluster Shared Volume (CSV) volumes |
Yes |
Yes |
Yes |
DFS Namespace (DFS-N) |
Yes |
Yes |
Yes |
DFS Replication (DFS-R) |
Yes |
Yes |
Yes |
DHCP Server |
Yes |
Yes |
Yes |
Distributed Network Name (DNN) |
No |
Yes |
Yes |
File Server |
Yes |
Yes |
Yes |
Scale-Out File Server for application data |
No |
Yes |
Yes |
Generic Application |
Yes |
Yes |
Yes |
Generic Script |
Yes |
Yes |
Yes |
Generic Service |
Yes |
Yes |
Yes |
Virtual Machine |
Yes |
Yes |
Yes |
Hyper-V Replica Broker |
No |
Yes |
Yes |
IP addresses (IPV4, IPV6, IPv6 tunnel addresses) |
Yes |
Yes |
Yes |
iSCSI Target Server |
Yes |
Yes |
Yes |
Internet Storage Name Service (iSNS) |
Yes |
Yes |
Yes |
Message Queuing (MSMQ), MSMQ triggers |
Yes |
Yes |
Yes |
Network Name resources |
Yes |
Yes |
Yes |
NFS shares |
Yes |
Yes |
Yes |
Other Server |
Yes |
Yes |
Yes |
Physical Disk resource |
Yes |
Yes |
Yes |
WINS Server |
Yes |
Yes |
Yes |
Note
In Windows Server 2012 R2, you can designate a virtual hard disk (.vhdx file) as shared storage for multiple virtual machines that are configured as a guest failover cluster. This new type of guest cluster, known as a shared VHDX guest cluster, enables scenarios such as Microsoft SQL Server Failover Cluster Instance (FCI) guest clusters. The Copy Cluster Roles Wizard supports migration of the roles in the table above (except for the Virtual Machines role, which cannot exist in a guest cluster) between shared-VHDX guest clusters running the released version of Windows Server 2012 R2. However, if you created a shared-VHDX guest cluster in Windows Server 2012 R2 Preview, you cannot use the wizard to copy the cluster roles to a shared VDX guest cluster running the released version of Windows Server 2012 R2.
Cluster roles that cannot be migrated
Some services and applications that can run in a failover cluster on Windows Server 2012 R2 cannot be migrated by using the Copy Cluster Roles Wizard—in some cases because they were not supported on earlier versions of clustering. The Copy Cluster Roles Wizard in Windows Server 2012 R2 cannot be used to migrate the following clustered roles:
Microsoft SQL Server—For upgrade guidance for SQL Server, see the whitepaper SQL Server 2012 Upgrade Technical Guide.
Microsoft Exchange Server—For upgrade guidance for Exchange Server, see Understanding Upgrade to Exchange 2010.
Print Spooler from Windows Server 2008 R2—In Windows Server 2012 R2 and Windows Server 2012, the print spooler is no longer a clustered resource. Instead, high availability is defined as a highly available virtual machine running on a single cluster node. The Print Server role is installed on a single virtual machine, which can be migrated to other nodes automatically or manually. For more information, see High Availability Printing Overview.
Remote Desktop Connection Broker from Windows Server 2008 R2—In Windows Server 2012 R2 and Windows Server 2012, the active/passive clustering model for the RD Connection Broker role service, used in earlier versions of Windows Server, is replaced by the Active/Active Broker feature, which eliminates the need for clustering and provides a fully active/active model. For more information, see the blog entry RD Connection Broker High Availability in Windows Server 2012.
Volume Shadow Copy Service tasks
Task Scheduler tasks (Windows Server 2012 R2 and Windows Server 2012 only)
Cluster Aware Updating (CAU) settings (Windows Server 2012 R2 and Windows Server 2012 only)
Roles restricted to a single instance per cluster
For the following roles, only one instance per failover cluster is supported:
DHCP Server
WINS Server
iSCSI Target Server
Hyper-V Replica Broker (Windows Server 2012 R2 and Windows Server 2012 only)
For those roles, the Copy Cluster Roles Wizard will not attempt to create a second role instance if one instance already exists on the target cluster.
Migrations for which the Copy Cluster Roles Wizard performs most or all steps
For the following clustered services or applications, The Copy Cluster Roles Wizard performs most or all steps for a migration to a Windows Server 2012 R2 failover cluster:
Distributed File System (DFS) Namespace
Generic Application
Generic Script
Generic Service
IPv4 Address, when migrating within the same subnet
IPv6 Address or IPv6 Tunnel Address
Internet Storage Name Service (iSNS)
Network Name (other than the cluster name)
If Kerberos authentication is enabled for the Network Name resource, the migration wizard prompts you for the password for the Cluster service account that is used by the old cluster.
NFS
Physical Disk (resource settings only; does not copy data to new storage)
Windows Internet Name Service (WINS) (Extra steps might be required if you migrate to new storage, and you use a different drive letter on the path to the new database.)
For more information about the Copy Cluster Roles Wizard, see Create a Failover Cluster. For step-by-step instructions for performing a migration between two multimode failover clusters, see Migration Between Two Multi-Node Clusters. For step-by-step instructions for performing a stand-alone migration while upgrading a single failover cluster, see In-Place Migration for a Two-Node Cluster: Migration to Windows Server 2012 R2.
Migration within mixed environments
The Copy Cluster Roles Wizard can migrate clustered resources within mixed environments. For example, the wizard accommodates the following differences in the source and destination environments:
Migrate static IP addresses to a cluster using DHCP.
Migrate IPv4 resources into an IPv6 environment.
Migrate across routed subnets.
Migrate a physical cluster to a guest (virtual) cluster (with the exception of Hyper-V clusters, which must run on physical computers).
Migrate between different editions of the operating system (for example, from Windows Server Enterprise to Windows Server Datacenter), between x86 and x64 processor architectures, and from a cluster running Windows Server Core or Microsoft Hyper-V Server to a cluster running a full version of Windows Server.
During migration, the wizard allows you to address name conflicts between resource groups, resources, and share names and to address drive letter collisions. The wizard resolves the conflicts as part of the post-migration repair process.
Important
The Copy Cluster Roles Wizard moves resources, not data. If you plan to migrate to new storage, you must move the data and folders yourself.
Additional steps for a wizard-based migration
Some additional steps typically are needed before or after you run the wizard, including the following:
Install server roles and features that are needed in the new cluster. In most cases, you must install the role or feature on all nodes of the cluster. For example, before you migrate a highly available virtual machine, you must install the Hyper-V server role on each cluster node.
Copy or install any associated applications, services, or scripts on the new cluster (all nodes).
If a migrated role or feature uses the same storage, take the services and storage offline on the old cluster and then make the storage available to the new cluster.
If a migrated role or feature uses new storage, ensure that any data and folders are copied to new storage. Verify permissions on any shared subfolders that were migrated.
If the new cluster is on a different subnet, provide static IP addresses.
If the new cluster uses a different volume letter, update drive path locations for applications.
Configure Task Manager tasks on the new cluster. (Windows Server 2012 R2 or Windows Server 2012 only)
For a virtual machine, install the latest integration services on the virtual machine. Configure Volume Shadow Copy Service (VSS) backups. For a migration from Windows Server 2012 R2 or Windows Server 2012, configure Hyper-V Replica settings.
Configure Cluster Aware Updating (CAU). (Windows Server 2012 R2 and Windows Server 2012 only)
Failover Cluster Copy Roles reports
The wizard provides a Failover Cluster Copy Roles Pre-Copy Report (formerly the Pre-Migration Report) and a Failover Cluster Copy Roles Post-Copy Report (formerly the Post-Migration Report), which provide important information. We recommend that you review both reports while performing a migration:
The Pre-Copy Roles Report explains whether each resource that you plan to migrate is eligible for migration.
The Post-Copy Roles Report contains information about the success of the migration, and describes additional steps that might be needed before you bring the migrated resources online.
Note
Two resource groups are never migrated: Cluster Core Resources Group and Available Storage Group. You can ignore these resource groups in the Failover Cluster Copy Roles reports.
Clustered role and feature migrations that require extra steps
This section provides guidance for migrating clustered roles and features that require additional steps before or after you run the Copy Cluster Roles Wizard to perform a migration between clusters.
Clustered DFS Replication migrations
Before you migrate clustered Distributed File System (DFS) Replication (also known as DFS-R or DFSR) to a cluster running Windows Server 2012 R2, you must add the new cluster to the DFS replication group to which the old cluster belongs, and then wait until DFS Replication synchronizes the data to the new cluster. After data synchronization is complete, you can decommission the old cluster. For step-by-step guidance, see Migrate File and Storage Services to Windows Server 2012 R2 and File and Storage Services: Post-migration Tasks.
To migrate clustered instances of DFS Replication to a cluster running Windows Server 2012 R2
Obtain the name of the cluster to which you will migrate. In Active Directory, this is the name that is used for the computer account of the cluster itself (also called the cluster name object or CNO). Add this name to the replication group that you will migrate. For more information, see Add a member to a replication group.
Wait until DFS Replication finishes synchronizing the replicated data to the cluster to which you will migrate.
If you plan to decommission the cluster from which you migrated, remove its network name from the replication group. If necessary, destroy the cluster.
For more information about DFS Replication in Windows Server 2012 R2, see DFS Namespaces and DFS Replication Overview. For step-by-step instructions for migrating DEF Replication, see Migrate File and Storage Services to Windows Server 2012 R2.
Clustered DHCP migrations
When migrating clustered Dynamic Host Configuration Protocol (DHCP) to a cluster running Windows Server 2012 R2, the Copy Cluster Roles Wizard migrates resources and settings, but not the DHCP database. For information about how to migrate the DHCP database, see DHCP Server Migration: Migrating the DHCP Server Role. The information in the topic also applies to migrations from Windows Server 2008 R2 or Windows Server 2012 to Windows Server 2012 R2. The topic includes information about migrating from a cluster.
Note
Although the migration of the clustered DHCP role is supported, in Windows Server 2012 R2 there is the option to use DHCP failover. DHCP failover provides redundancy and load balancing without clustered DHCP. For more information, see Migrate to DHCP Failover and Understand and Deploy DHCP Failover.
Clustered DTC migrations
Before you begin the migration of clustered Distributed Transaction Coordinator (DTC) to a cluster running Windows Server 2012 R2, you must make sure the list of transactions stored by DTC is empty. This is referred to as draining the transaction logs. If you do not drain the logs, the information in the logs (the transaction state information for unresolved transactions) will be lost during the migration. Unresolved transactions include Active, In Doubt, and Cannot Notify transactions.
To drain DTC transaction logs of unresolved transactions
Stop the application that creates transactions on the clustered instance of DTC that is being migrated.
On a node of the cluster that you are migrating from, click Start, point to Administrative Tools, and then click Component Services. (In Windows Server 2012 R2, open Component Services directly from the Start screen.)
Expand Component Services, expand Computers, expand My Computer, expand Distributed Transaction Coordinator, and then expand Clustered DTCs.
Expand the clustered instance of DTC that you are migrating, and then click Transaction List.
View the transaction list to see if it is empty. If there are transactions listed, then either wait for them to be completed or right-click each transaction, click Resolve, and then select Forget, Commit, or Abort.
For information about the effect of each of these options, see Transaction State Resolution After System Failure.
For additional information, see View Transaction Information.
Clustered File Server and Scale-out File Server migrations
Several methods are available for migrating a scale-out file server or traditional clustered file server to Windows Server 2012 R2. For all methods, there are trade-offs among required downtime, migration duration, resource usage, and required hardware. The best method for your environment depends on hardware and resources you have available, the volume of data to be moved, the number of clustered file servers that are affected, and service requirements.
Choosing the best migration method for your file server
When you plan your clustered file server migration, consider these methods:
Virtual machine storage migration
Copy Cluster Roles Wizard - Migrate to a new multi-node cluster
Copy Cluster Roles Wizard – In-place migration
Migrate storage pools
Note
For a fuller discussion of storage upgrade options as an integral part of upgrading your private cloud infrastructure, view the presentation Upgrading Your Private Cloud with Windows Server 2012 R2, presented at TechEd 2013.
Virtual machine storage migration
Introduced in Windows Server 2012, virtual machine storage migration enables you to the virtual hard disks used by one clustered file server to another clustered file server while the virtual machine remains running. This is known as storage migration. After you migrate storage for each virtual machine, you migrate the virtual machines to the new Windows Server 2012 R2 failover cluster. For more information, see Virtual Machine Storage Migration Overview.
This method is useful for moving to new storage if you have the resources available to maintain required service levels on all of the virtual machines during migration.
Migration method: Virtual machine storage migration
Advantages |
Disadvantages |
|---|---|
Live-migrate storage without any downtime for the virtual machines. |
The process moves lots of data over the network, using lots of resources. If you are migrating a large number of virtual machines, and don’t have the network capacity to gracefully handle the large loads, this can have a large impact on performance. You must move to new storage. |
Copy Cluster Roles Wizard - Migrate to a new multi-node cluster
With this method, you set up a new Windows Server 2012 R2 failover cluster, migrate the File Server role to the new cluster, and then take the file server offline while you redirect storage to the new cluster. The wizard does not move data; if you migrate to new storage, the wizard updates the storage settings for the role, but you must move the data and files manually during the migration. For step-by-step instructions, see Migrate Between Two Multi-Node Clusters: Migration to Windows Server 2012 R2.
Use this method if you have too much data to move over the network without unacceptable impact on the performance of your clustered file servers.
Migration method: Copy Cluster Roles Wizard – Migrate to a new multi-node cluster
Advantages |
Disadvantages |
|---|---|
This method is much faster than storage migration. In a large enterprise with hundreds of clustered file servers, the migration can take hours rather than days. |
Downtime is required. You must take the File Server roles offline on the old cluster while you redirect the storage to the new cluster, However, this method is faster than moving VHDs over the network, and you can schedule the downtime for a maintenance window, when you will experience a limited interruption in service but will not risk degrading service for running virtual machines over long periods. Additional hardware is required to create the new failover cluster. |
Copy Cluster Roles Wizard – In-place migration
If you do not have the hardware available to create a new multi-node Windows Server 2012 R2 failover cluster before you migrate the cluster roles, you can perform an in-place migration. In an in-place migration, you use hardware from an existing cluster to create the new cluster, evicting one node to use as the first node in the new cluster.
For a two-node cluster, you would evict one node, perform a clean installation of Windows Server 2012 R2 on that node, create a new single-node failover cluster with that node, and then migrate the File Server role from the old cluster to the new cluster. At that point, you must take the File Server roles offline on the old cluster while you redirect storage to the new cluster. When the migration is complete, you then destroy the old cluster, install Windows Server 2012 R2 on the other cluster node, and add that node to the new cluster. For step-by-step instructions, see In-Place Migration for a Two-Node Cluster: Migration to Windows Server 2012 R2.
Migration method: Copy Cluster Roles Wizard – In-place migration
Advantages |
Disadvantages |
|---|---|
No new hardware required. Data is not migrated over the network. |
Downtime is required: you must take the File Server roles offline on the old cluster before you can redirect storage to the new cluster and then bring the roles and the storage online on the new cluster. While migrating a two-node cluster in place, you take on the added risk of losing high availability for your file servers from the time when you remove the first node from the old cluster until you add the second node to the new cluster. Service can be degraded on the nodes that remain online during the migration, particularly if you are migrating large numbers of clustered file servers. |
Storage pool migration
If you are migrating from a Windows Server 2012 failover cluster that uses storage pools, you can minimize the impact of migration by migrating one storage pool at a time, from the old cluster to the new cluster. With storage pools, instead of managing each disk individually, you add physical disks to one or more pools and then create virtual disks from the available capacity. You then create volumes on the virtual disks, as if they were physical disks. When you run low on the available capacity in the pool, add physical disks to the pool to create bigger pools with more capacity for more virtual disks.
Storage Spaces uses commodity drives that are attached via Serial-Attached SCSI (SAS), Serial ATA (SATA), or USB. When it is time to change from the old cluster using the storage to the new cluster using the storage, you might need to change the cabling. If you are reusing hardware (that is, you are performing an in-place migration), when you evict a node from the old cluster, you need to disconnect that server’s connection to the disks. When it is time to change the storage from the old cluster to the new cluster, disconnect the storage from the old cluster before you connect the storage to the new cluster, so that only one cluster is connected to the disks at one time. When you connect the storage to the new cluster, the Storage Spaces and associated storage pools becomes available to the new cluster so that the migration can complete.
For more information about using Storage Spaces and storage pools, see Storage Spaces Overview, What's New in Storage Spaces in Windows Server 2012 R2, and Deploy Clustered Storage Spaces. For a video presentation from TechEd 2013 that demonstrates Storage Spaces basics and new features, see Storage Spaces: What’s New in Windows Server 2012 R2.
Migration method: Storage pool migration
Advantages |
Disadvantages |
|---|---|
No downtime is required. High availability is maintained throughout migration. |
Data moves over the network. A four-node cluster is required to enable you to maintain two nodes on both the old and new clusters during migration. |
Additional tasks for file server migration using the Copy Cluster Roles Wizard
If you choose to use the Copy Cluster Roles Wizard to migrate your file server, be aware of the following requirements:
If you plan to migrate to new storage, keep in mind that if the migrated files and folder inherit permissions from their parents, during migration it is the inheritance setting that is migrated, not the inherited permissions. Therefore it is important to make sure that the parent folders on the source server and the destination server have the same permissions to maintain the permissions on migrated data that has inherited permissions. After the file server migration, it’s important to verify the folder permissions after the migration. Sometimes folder permissions reset to Read-only during a file server migration.
You do not need to migrate the quorum resource. When you run the Create a Cluster Wizard in Windows Server 2012 R2 or Windows Server 2012, the cluster software automatically chooses the quorum configuration that provides the highest availability for your new failover cluster, and it dynamically updates the quorum configuration if you add or evict nodes. You can change the quorum configuration on the new cluster if necessary for your specific environment. However, Dynamic Quorum is not in effect on a Windows Server 2008 R2 failover cluster. If you evict a node to perform an in-place migration, you will need to update the quorum configuration.
Clustered FSRM migrations
To migrate the File Server Resource Manager (FSRM) classification, storage reporting, and file management task configuration on a clustered file server running Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 to a failover cluster running Windows Server 2012 R2, you must export the configuration from one FSRM server node in the cluster and then import the configuration to another FSRM server. These steps must be performed locally on one node of the cluster. You then fail over the other nodes until this process is complete. For step-by-step instructions, see Migrate File and Storage Services to Windows Server 2012 R2.
Important
When you migrate the configuration, FSRM requires that you use the same drive letters on both the source and destination servers.
Clustered Message Queuing (MSMQ) migrations
When you migrate a clustered instance of Message Queuing (also known as MSMQ) to a cluster running Windows Server 2012 R2, it’s important to take the following precautions to ensure that the data is preserved and you can bring the service online on the new cluster:
Before you migrate, you should back up the data that is associated with clustered instances of Message Queuing. This ensures that you can restore service-specific Message Queuing data if it is accidentally deleted during migration. For more information about Message Queuing backup and restore, see Backing up and restoring messages.
During the migration, it’s important to make sure that the migration is complete before you delete either clustered instance of Message Queuing (old or new). Otherwise, service-specific data for Message Queuing might be deleted from the shared storage, which prevents the remaining Message Queuing resource from coming online. After the migration is complete and you are ready to delete a clustered instance of Message Queuing (old or new), first remove the disk resource from that clustered instance and take the disk offline. Then delete the clustered instance of Message Queuing.
Other Server migrations involving resource types not built into failover clusters
Before you use the Copy Cluster Roles Wizard to migrate an application that uses a clustered resource type that is not built into failover clustering, be sure to add the resource type to the new cluster. You can then use the Copy Cluster Roles Wizard to migrate your clustered application. In this situation, the Copy Cluster Roles Wizard attempts a "best effort" migration.
To add a resource type to a failover cluster running Windows Server 2012 R2
Open Failover Cluster Manager from the Start screen of any node in the cluster running Windows Server 2012 R2.
If the cluster to which you want to migrate is not displayed, in the console tree, right-click Failover Cluster Manager, click Connect to Cluster, select the cluster that you want to migrate to, and then click OK.
In the console tree, right-click the cluster, and then click Properties.
Click the Resource Types tab, and then click Add.
Specify the following information for the resource type:
Resource DLL path and file name: The path and file name of the resource dynamic-link library (DLL) that the Cluster service should use when it communicates with your service or application.
Resource type name: The name that the Cluster service uses for the resource type. This name stays the same regardless of the regional and language options that are currently selected.
Resource type display name: The name that is displayed for the resource type. This name might vary when you make changes to regional and language options.
Migration of highly available virtual machines
You can use the Copy Cluster Roles Wizard to migrate highly available virtual machines created in Hyper-V from a Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 failover cluster to a cluster running Windows Server 2012 R2. Using the wizard, you migrate the Virtual Machine clustered role, select highly available virtual machines to migrate, and update virtual network settings for the virtual machines on the new cluster.
Migrating HAVMs by using the Copy Cluster Roles Wizard has the advantage of not copying VHDs over the network, so migration completes fairly quickly and downtime is limited. However, the wizard cannot migrate virtual machines to new storage. Also, if you migrate one virtual machine on a Cluster Shared Volume (CSV) volume, all virtual machines on that volume are migrated. And downtime is required: after you copy the Virtual Machine roles to the cluster, you must take the virtual machines on the old cluster offline, unmask the storage to the old cluster, mask the storage to the new cluster, then bring the storage online on the new cluster, and then start the virtual machines on the new cluster.
Warning
It is very important that you not turn on the migrated virtual machines on the new cluster before you take the virtual machines offline on the old cluster. Running a virtual machine on both clusters at the same time might corrupt the virtual machine.
For step-by-step instructions for migrating highly available virtual machines from a Windows Server 2012 failover cluster to a Windows Server 2012 R2 failover cluster by using the Copy Cluster Roles Wizard, see Copy Cluster Roles Wizard in Hyper-V Cluster Using Separate Scale-out File Server Migration, or, if your virtual machines are stored on Cluster Shared Volume (CSV) volumes, see Hyper-V Cluster Using Cluster Shared Volumes (CSV) Migration. You can use the same procedures to migrate virtual machines from CSV volumes on a Windows Server 2008 R2 cluster to a Windows Server 2012 R2 cluster.
Alternate methods for migrating HAVMs to a Windows Server 2012 R2 failover cluster
Depending upon your environment and the service requirements for the migrated workloads, you should consider two alternate methods for migrating highly available virtual machines:
Cross version live migration – Windows Server 2012 R2 introduces a new method for migrating a highly available virtual machine from a Windows Server 2012 cluster to a Windows Server 2012 R2 cluster. Using cross version live migration, you can migrate virtual machines to the new failover cluster without any downtime. If the virtual hard disks (VHDs) are stored on a Scale-out File Server share that is accessible to both clusters, you don’t have to copy files over the network. However, depending on factors such as the amount of memory configured for the virtual machine, migration can be slow, and resource consumption during the live migrations can be high.
Export/Import method - You also can migrate individual virtual machines by using the Export and Import actions in Hyper-V Manager (also available in Windows PowerShell). The Export/Import method lets you migrate virtual machines one at a time and control the method by which they the VHDs are copied to the new cluster. The virtual machine must be taken offline during the export and import, and you must re-enable Hyper-V replication on the virtual machine after migration.
For a comparison of migration methods for migrating HAVMs to a Windows Server 2012 R2 failover cluster, see Hyper-V: Migration Options.
Note
You must use the Copy Cluster Roles Wizard or the Export and Import actions to migrate from a Windows Server 2008 R2 cluster to a Windows Server 2012 R2 cluster. Cross version live migration is only available when you migrate from Windows Server 2012.
Additional tasks for using the Copy Cluster Roles Wizard to migrate HAVMs
When you migrate HAVMs by using the Copy Cluster Roles Wizard, a few extra steps are required:
You must merge or discard all shadow copies before you migrate the volumes that are attached to the virtual machines. Before you begin working with shadow copies, you should back up volumes.
After you migrate the virtual machines to the new cluster, install the latest Hyper-V integration services on the new virtual machines.
After you migrate, The Copy Cluster Roles Wizard does not migrate the following settings. You will need to configure the settings on the new cluster after migration.
Hyper-V Replica settings
Important
If you using Hyper-V Replica with the workload that you are migrating, see the “Hyper-V Replica” section of Hyper-V: Migration Options for special considerations when migrating from Windows Server 2012 to Windows Server 2012 R2.
Volume Shadow-Copy Service (VSS) tasks
Cluster-Aware Updating (CAU) settings
Additional references
Failover cluster basics:
Instructions for migrations that use the Copy Cluster Role Wizard:
Migrate Between Two Multi-Node Clusters: Migration to Windows Server 2012 R2
In-Place Migration for a Two-Node Cluster: Migration to Windows Server 2012 R2
Hyper-V: Hyper-V Cluster Migration (Migrating highly available virtual machines from Windows Server 2012 or Windows Server 2012 R2)
Migrating individual roles and features:
High availability for Microsoft Exchange Server 2013: Deploying High Availability and Site Resilience
High availability for Microsoft SQL Server 2014: High Availability Solutions (SQL Server)
High availability for Microsoft SQL Server 2012: Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery (whitepaper)