Here are the steps that I followed to get a Windows 2008 R2 cluster hosting SQL Server to Windows 2012 R2.
In this example we have a 2 node Active / Passive cluster running Windows Server 2008 R2 Enterprise hosting SQL Server 2012 SP2 with CU6, this will work with any version of SQL Server.
Step 1: Document the following:
Drive letter mapping to shared storage on each node, NTFS Shared folders, IP Addresses for LAN and Heartbeat on each node, Name and IP address of the Windows Virtual Cluster Node, Name and IP address of the SQL Virtual Cluster Node, SQL version, patch level, and features installed, The location of the System Databases
Step 2: In Failover Cluster Manager – Evict the passive node, in this example Node 2 is the passive node.
Step 3: Rebuild Node 2 with Windows Server 2012 R2, using the same server name and IP address. Verify that Node 2 can see the shared storage, but do not make them online at this point.
Step 4: Stop the SQL Services on Node 1.
Step 5: Locate the folder containing the system databases and move them to a secure location. Make sure you get all the system database including TempDB, MSDB, report server, and distribution if you have replication.
Step 6: Shutdown Node 1.
Step 7: In Active Directory Users and Computers disable the accounts for the Windows Cluster Node and SQL Cluster Node.
Step 8: On Node 2, Create the Windows Failover Cluster using the previous Windows Cluster Name and IP. At this point the shared drives will be present, verify they have the correct drive letters.
Step 9: Install SQL Server as a cluster using the same name, IP address, include all features required.
Step 10: Patch SQL Server to the correct SP and CU.
Step 11: Stop the SQL Services using SQL Server Configuration Manager.
Step 12: Copy the system database files that you saved from Step 5 over top the system database files from this new installation.
Step 13: Start the SQL Services using SQL Server Configuration Manager, verify all databases and logins are available.
Step 14: Install Windows Server 2012 R2 on Node 1 and join the Windows Failover Cluster.
Step 15: Install SQL Server as a new node to the SQL Cluster, patch to correct level.
Best Answer
I have a largely automated process to upgrade versions and replicate data back to the old version using transaction replication without a snapshot init. I need minimal downtime in this environment so we don't have time to make the databases generate a snapshot and send it back just in case we need to roll back. You might allow yourself downtime but in that case if you will use a snapshot make sure to script out the 'create database' section with all the proper filegroups and options. You'll need to snapshot back to a database. It can create it for you but you're better off doing it in advance.
Be careful of PK constraints if you are not going to init. If you get even 1 row in your old table your PKs which doesn't match, you will get PK conflicts and errors.
Have a backup plan handy so script out snapshot replication or something else like Red Gate Data Compare just in case things go sour.
Test this process repeatedly in staging and automate as much of it as you can. That way it's consistent and easy in the day off. Preferably check your code in.
Ensure you make the databases not writable and that all of your data is fully synced up, while ensuring nothing can write to the old db before you cut over clusters.
You can also look at switching your cluster IP address if you have tons of clients that you can't keep track of, but if you can, it's better to get a new IP. If you change IPs make sure to automate that as well and ensure you update DNS/RDNS and add a CNAME if you need to the new machine with the old name just in case clients connect by IP.
If you have enough downtime capability you can roll back at your leisure. Good luck!