Capacity planning for SQL Server consolidation

My company has a small SQL environment for LANDesk and they want to migrate all the servers to a single SQL cluster per region. What I want to know is, how do I determine the capacity for such a scenario? I have obtained the database growth per individual server (All Landesk) and can I take this data as a rough estimate for the consolidation in to the single SQL cluster? The Windows team tells me that the data from these servers is kinda wonky and might not give an accurate result what they want.

The new cluster in question already has a couple of databases but it is not at it's fullest capacity yet. Once they start adding the remaining data from the servers, it should reach it's full capacity. I have been running Perfmon on this for a while and for checking database growth I used the below TSQL code from sqlskills.com

SELECT
[database_name] AS "Database",
DATEPART(month,[backup_start_date]) AS "Month",
AVG([backup_size]/1024/1024) AS "Backup Size MB",
AVG([compressed_backup_size]/1024/1024) AS "Compressed Backup Size MB",
AVG([backup_size]/[compressed_backup_size]) AS "Compression Ratio"
FROM msdb.dbo.backupset
WHERE [database_name] = N'AdventureWorks'
AND [type] = 'D'
GROUP BY [database_name],DATEPART(mm,[backup_start_date]);

Is there anything I can do to get an accurate result? The LANDesk team doesn't want me to use the older servers and the only option I have is to use the new cluster where they plan to migrate all the data and I only have 6 months worth of data on this. Should I ask them questions like number of years this new cluster be used? etc...

Thank you all for your answers. Here is what I have from the PAL tool

I used the PAL tool to determine perfmon data and these are some of the warnings it gave

1)Response time greater than 25ms
2) Less than 10% Idle Time - the disk queue has at least 1 outstanding I/O 90% of the time
3)Greater than or equal to 64 KB IO sizes. Generally, the larger the IO size, the more data can be transferr

Like Randolph mentioned, disk is the kind of the last thing you need to worry about. If it's clustered as you mentioned, you can easily add storage to accommodate data growth.

The things that are harder to add and cost real money are:

CPUs (Licensing)
Memory (If you're on standard edition, you're limited to 128 GB)

In a consolidation scenario, you need to get a baseline of CPU use (easy perfmon--SQL Server CPU) and memory--harder (you'll want to track to page life expectancy as it relates to total memory use by SQL). Finally, you'll want to tack IOPS--the performance component of storage--if your source environments are on SQL 2014 or higher, there is a counter you can check (disk read/write IO/sec) to get that data. The disk data will simply be cumulative, whilst the CPU and memory data will need to evaluated. In a consolidated environment, you'll probably use a little less CPU and memory.

Finally, for a shared environment like this, you probably want to use Enterprise Edition with Resource Governor so you can prevent the "noisy neighbor" problem.

StackExchange Database Administrators Q#154325, answer score: 5