I've built several Clusters in my life. SQL 2000, SQL 2008, and most recently, SQL 2012. I never had any problems when the hardware and storage was properly sized by the SAN or IT team. When it was not, it was a real nightmare.

Let me share with you what I've learned from experience,

#1, measure your workload

Before start moving stuff. Measure your workload. You can use perf. mon for that. Measure CPU, RAM and I/O utilization. Also, if you can attach the new storage to a Windows server, measure I/O as well using SQLIO. This is critical! Because if your storage is not fast enough, you will have performance issues. I faced lot of problems with a SQL2012 Cluster because the storage was not properly sized. The Cluster started failing over unexpectedly and I could not even take SQL backups, that will trigger a failover too. It was a nightmare. The SQL Cluster was properly configured, but the SAN was not.

#2 use same hardware

MS clearly states that you should use identical hardware. Mixing hardware, like servers with different RAM or different CPU models will create issues. Long time ago I face a problem with a SQL 2008 Cluster that IT people built with different CPUs. It experienced random failovers and issues. It took a long time to discover and much more to migrate and fix. So, you are warned 🙂

#3

Use shared storage.

MS also is clear that using share storage is recommended. You are dealing with databases, so writing stuff to disk without corruption is key. Because the way SANs work, they ensure data corruption won't occur. Some cheap storage solutions like file storage and others, can be used, but they write information in a different way and were not designed for SQL clusters, so you may end with a slow Cluster or one that may corrupt your data. So use an MS endorsed array/SAN for your Cluster.

How to migrate? Well... you can build a one node Cluster and backup and restore your databases or even use Mirroring. Then you destroy the old hardware and join that server to the Windows Cluster. This is assuming you will re-purpose existing hardware. Otherwise, you can do the same and build the Cluster 1st and do a side by side migration.

Forget about master, model, etc. You can't move those. But you can script any T-SQL job you may have. Same goes for SQL logins.

Please Google or look here for step by step process of how to build one. It is complex so I can't explain it on a few lines in a simple post. But you need to assign IPs, setup a Domain account for the SQL server service, and much more. So be prepare to work with your network or IT team, you will need them for the initial setup and on going support.