Checklist · free
Infrastructure health checklist
For IT and infrastructure leaders who want a quick look at the capacity, support and lifecycle risks across their servers, hypervisors, network, firewalls, storage and backup, before a deadline makes the decision for them.
Inventory and lifecycle
| # | Question | Why it matters |
|---|---|---|
| 1 | Do you have a current inventory of every server, host, switch, firewall and storage array, with its version and support status? | You can't plan upgrades or spot risk in systems you can't see. Every other answer on this list depends on it. |
| 2 | Which server operating systems are near or past end of support, and is there a plan for each one? | End-of-life systems stop receiving security patches. They also hold up migrations and audits. |
| 3 | Are there legacy systems that can't be upgraded because an application depends on them? | These need an isolation or retirement plan, or they quietly become the oldest and riskiest part of the estate. |
| 4 | When do support and maintenance contracts end on your arrays, switches and firewalls? | End-of-support dates set your timeline. Replacing hardware takes lead time you may not have if you find out late. |
| 5 | Is a hardware refresh due in the next 12 to 24 months? | Platform choices and cluster sizing are easier to get right before new hardware is bought, not after. |
| 6 | When is your next virtualization renewal or licensing decision, and have you compared the options? | Licensing changes are pushing many organizations to rethink their hypervisor. A comparison turns a default renewal into a real decision. |
Capacity and performance
| # | Question | Why it matters |
|---|---|---|
| 7 | How much storage capacity is used and free, and how fast is your data growing? | Arrays that fill up cause outages and rushed purchases. Growth rate tells you how much time you really have. |
| 8 | Are applications reporting slow storage or performance problems? | Performance complaints are often the first sign an array or cluster is outgrowing its design. |
| 9 | Are host, cluster and storage capacity reviewed on a regular schedule? | Regular reviews catch capacity limits early, while there is still time to plan rather than react. |
Configuration, patching and firmware
| # | Question | Why it matters |
|---|---|---|
| 10 | Are Windows and Linux servers patched consistently and built to a common configuration baseline? | Patching and hardening drift apart by platform. A shared baseline makes gaps visible and builds repeatable. |
| 11 | Is firmware current on your switches, storage and firewalls? | Firmware fixes security and stability issues in devices that are easy to forget once they are running. |
| 12 | Have audits or insurers raised findings on patching, hardening or perimeter controls? | Findings usually point to the exact systems that need attention first. |
Network and firewalls
| # | Question | Why it matters |
|---|---|---|
| 13 | Is your network documentation current across every site, including diagrams and device configurations? | Undocumented configurations make outages harder to diagnose and changes riskier. |
| 14 | Do your sites run several network vendors with no common configuration standard? | Mixed designs built site by site slow down troubleshooting and projects. |
| 15 | Do you know where your single points of failure are in the network and storage design? | One component with no alternative can stop a whole service when it fails. |
| 16 | When were your firewall rule bases last reviewed? | Rule sets grow for years. Unused and overly broad rules widen the attack surface. |
| 17 | Do your firewalls run in high-availability pairs, and has failover actually been tested? | A standby that has never taken over is an assumption, not a safeguard. |
Backup and recovery
| # | Question | Why it matters |
|---|---|---|
| 18 | Which backup tools protect which environments (on-premises, Microsoft 365, cloud), and where do they overlap or leave gaps? | Several tools with overlapping coverage often hide systems that nobody is backing up. |
| 19 | Are recovery time and recovery point objectives (RTO and RPO) documented, and who set them? | Without agreed targets, there is no way to tell whether your backups are good enough. |
| 20 | When did you last test a full recovery of a critical system? | Running backups and proving recovery are different things. Untested recovery targets are guesses. |
| 21 | Are any backup copies immutable or isolated from the production network? | Ransomware targets backups. A protected copy that can't be changed is your last line of recovery. |
| 22 | Is data replicated to a second site for disaster recovery? | Replication is what keeps a site-level failure from becoming a business-level one. |
How to read your result
Mark each question you could not answer with confidence, or where the answer was "no" or "I don't know".
- 0–4 marked: Your estate is in good shape. Keep the inventory current and revisit this list before each renewal or refresh.
- 5–10 marked: You have real gaps, probably clustered in one or two groups. Start with the group that has the most marks, and put a date against each end-of-support item.
- 11 or more marked: Risk is likely building faster than it is being managed. Start with questions 1, 2 and 20: a full inventory, an end-of-life plan and a tested recovery.
Any mark on questions 2, 4 or 20 deserves attention first, because those are the risks with a deadline or no safety net.
If you marked five or more items, or any of questions 2, 4 or 20, contact Kalosys today. Your note goes straight to the engineers who run our infrastructure practice.