A server modernization checklist marks each of seven checks on the servers you run today from a dated record, with every mark set against one reference date. A missing record earns the lowest mark, and gaps in support dates and recovery records go to the top of the work order.
Last reviewed 2026-11-14 by Manish Sharma.
This is for the IT head or infrastructure manager at a mid-size firm or group in India or the GCC with servers on site or in colocation (your own servers in a rented data center rack). It is also for the CIO or CFO who signs off the budget. It covers the servers running today, before anyone picks a target platform. For the reasons behind each check, read why keeping servers past support carries a cost. The article quotes no product support dates; those come from each supplier’s own notice.
Filed, Part Filed or Unfiled: Marks on the Server Modernization Checklist
Three marks are possible per check. None goes on the sheet until the checker has opened the record behind it.
- Filed (2): the checker opened the record for every sampled server, it carries a date inside the check’s window, and it meets the test.
- Part Filed (1): the record covers some sampled servers but not all, or its date falls outside the window.
- Unfiled (0): no record exists, the record shows the test missed, or the only answer is a spoken one.
A missing record is Unfiled. The sheet holds no written exceptions, whether for a busy quarter or for a file that someone promises to find later.
Seven checks worth 2 each put the top mark at 14.
Only check 4, firmware, can be N/A. That applies when the firm owns no physical host, because every workload runs on a provider’s hardware. Write that reason on the row. The top mark then drops to 12.
The sheet sets no target total and no bands. A total of 11 can still hide an Unfiled recovery row, and that one row says more about the estate than the sum. Read the rows first, then the total.
One Reference Date, a Server Sample and Two Names
Pick one reference date, for example the first working day of the review month, and set every mark against it. Each window in the checks counts back from that date. A 12-month window on a sheet dated 1 December therefore reaches back to 1 December of the year before.
As a Signisys suggestion, the sample holds every server behind a critical service, plus five more that the signer picks from the inventory. The signer’s picks matter because the owner of one tidy server would otherwise choose only that one.
Two names go on the sheet. The checker opens each record and gives the mark. A separate signer then reviews the marks and signs the sheet. Nobody signs a record they keep or produced, so if the infrastructure lead keeps the firmware log, someone else signs that row.
Records come from the people who run and use each system. The operations team holds monitoring exports and firmware logs, while application owners hold the workload entries and their keep, move or retire marks.
When a record sits with a third party, such as a colocation provider, ask for a dated copy of it. A spoken summary earns Unfiled.
Seven Server Modernization Checklist Checks and the Record for Each
Three tables below hold the seven checks, split two, two and three.
Each check carries one clause on why it matters, and the full reasons sit in the risks article linked above. Each row of the server modernization checklist also states when a check is Filed. It then names the record the checker opens and what an Unfiled mark leaves open.
What Runs Where, and When Its Support Ends
Checks 1 and 2 ask whether the firm knows each server and the date its support stops.
| No. | Check | Filed when | Record to open | If Unfiled |
|---|---|---|---|---|
| 1 | Inventory complete | The checker finds every sampled server in one list, with make, model, serial, site and the workloads it runs | The dated inventory list and its last edit | Otherwise, a server can run a service that no plan counts |
| 2 | Support dates known | Each sampled server shows its hardware support end date against its serial, plus its operating system version and that version’s end date, read from the supplier’s notice inside 12 months | The saved supplier notice, with the date someone read it | If skipped, a server can pass its support end with nobody warned |
For check 1, NIST’s Cybersecurity Framework 2.0 (2024) lists a maintained hardware inventory as outcome ID.AM-01. The test here is narrower. The checker looks up each sampled serial, and if one sampled server is missing from the list, the row is Part Filed. Two lists that disagree also earn Part Filed until one copy becomes the record.
For check 2, the 12-month window is a Signisys suggestion. When a supplier publishes no end date, write that on the row with the date someone asked.
Put warranty status and license status on the same row. A server can sit inside hardware support while its operating system license has lapsed.
Measured Usage and Firmware Level
Checks 3 and 4 ask what each server does under load and what runs beneath its operating system.
| No. | Check | Filed when | Record to open | If Unfiled |
|---|---|---|---|---|
| 3 | Usage measured | CPU, memory, storage and network use for each sampled server covers at least 30 days, ending within 90 days of the reference date | The monitoring export, showing its start and end dates | Otherwise, any sizing rests on a guess about load |
| 4 | Firmware level | Each physical host’s installed firmware level sits beside the maker’s current release, in a comparison dated within 90 days | The firmware log and the maker’s release note it was set against | Without it, a known flaw can sit below the operating system unseen |
For check 3, the 30-day floor and the 90-day window are Signisys suggestions. A single reading earns Part Filed, because one afternoon says nothing about a month-end close or a festive sale peak. Tie the row to the export file itself, with its start and end dates in view.
For check 4, firmware is the low-level software that starts the hardware. NIST CSF 2.0 puts firmware next to operating systems in the outcome group that names firmware and operating systems. That group also covers physical and virtual platforms alike. Old firmware also widens the ways an attacker can reach a server. Log the host’s management controller and storage controller firmware on the same row, since each carries its own release. Virtual machines take the mark of the host they run on, because the hypervisor on that host supplies their virtual firmware. The 90-day window is a Signisys suggestion.
A Dated Recovery Record, a Named Owner and a Keep, Move or Retire Mark
Checks 5 to 7 ask whether each workload comes back after a failure, who answers for it and what happens to it next.
| No. | Check | Filed when | Record to open | If Unfiled |
|---|---|---|---|---|
| 5 | Recovery record | A restore or failover test for each sampled workload carries a date inside 12 months and a written result | The test record and its result | Otherwise, nobody knows if the workload comes back |
| 6 | Workload owner | One named person, not a team, confirmed each workload entry in writing within 12 months | The signed or emailed confirmation | If skipped, no one answers for the next step |
| 7 | Keep, move or retire | Each workload carries one mark with a one-line reason, the date marked and any rule on where its data must stay | The workload list with its mark column | Without a mark, nobody can plan the server’s future |
For check 5, NIST SP 800-34 Rev. 1 (2010), which is US federal guidance, has each plan tested at least once a year in its sample policy and plan templates, and asks for an after-action report for each test. The 12-month window follows that yearly rhythm. For the test day, see the checklist for marking the recovery test day itself.
For check 7, the sheet tests only that a mark exists. It does not judge the mark itself. A workload headed toward running workloads on site and in a cloud together can move in phases. In that case, one line on the row names the phase. Retained workloads also get a fresh look each year.
Key Takeaway A mark on this sheet stands on a record that someone other than its keeper has opened.
Server Modernization Checklist Columns to Copy Into a Sheet
The table below holds blank rows for the seven checks. Each row needs a record name, the servers sampled, a mark and two names. To use it as a server modernization checklist template, copy the rows into a spreadsheet. Then add a header line above them with the firm name, reference date and sites covered.
| No. | Check | Record opened | Servers sampled | Mark | Checker | Signer |
|---|---|---|---|---|---|---|
| 1 | Inventory complete | |||||
| 2 | Support dates known | |||||
| 3 | Usage measured | |||||
| 4 | Firmware level | |||||
| 5 | Recovery record | |||||
| 6 | Workload owner | |||||
| 7 | Keep, move or retire |
In the “Record opened” column, name the file and its date, for example “Inventory export, 2 November”. Then list the sampled servers by name or serial, so a second reader can open the same records later and reach the same mark.
One Estate Marked Row by Row: A Distributor in Ahmedabad and Sharjah
What follows is an illustration, not client data. Picture a distributor with 18 servers across a warehouse site in Ahmedabad and a regional office in Sharjah. The sample holds eight: the three behind critical services, plus five that the signer picked. They run on four physical hosts, two at each site.
| Check | Mark | Record found |
|---|---|---|
| 1 Inventory complete | Filed (2) | One list, with every sampled serial present |
| 2 Support dates known | Part Filed (1) | Operating system dates found, but no hardware dates for the two Sharjah hosts |
| 3 Usage measured | Filed (2) | A 35-day export for all eight servers |
| 4 Firmware level | Unfiled (0) | No firmware log; the Sharjah team recalls updating two hosts, with nothing on file |
| 5 Recovery record | Part Filed (1) | The latest restore record dates from 15 months before the reference date |
| 6 Workload owner | Filed (2) | Emailed confirmations from each named owner |
| 7 Keep, move or retire | Unfiled (0) | No mark on any workload |
The estate scores 8 of 14. The work order below puts check 5 first, because the stale restore record covers all three critical servers. Check 2 comes next, since one Sharjah host without hardware dates runs a critical service. Checks 4 and 7 follow as the Unfiled rows.
Turning Server Modernization Checklist Marks Into a Work Order
Finish marking every row before changing anything.
As a Signisys suggestion, any mark below Filed on check 2 or check 5 for a server behind a critical service goes first, whatever the total says. A critical server with no known support date, or no recent restore, is the gap that can stop a service outright.
After those first rows, close the other Unfiled rows, then the Part Filed ones. Teams that already keep a server refresh checklist can carry these marks into it row for row. A separate guide sets out the build order for closing each gap, from inventory to switch-off.
Some published lists also suggest a quick sort of workloads by business value and effort. That sort works at application level, and this sheet does not use it for servers.
When a gap closes, mark again only the rows that changed, with a new date on each. Run the whole server modernization checklist again after a site move or when a new provider contract starts. Otherwise, run it again a year after the reference date.
Key Takeaway A critical server with an unknown support date or a stale restore record leads the work order, whatever its total.
When the Sheet Is Full: Sizing, Platform Choice and Specialist Help
A full sheet shows that the records exist. However, it does not size new servers, choose a platform or run a recovery test. A server modernization checklist with every row Filed gives those decisions a starting point.
Choosing between platforms, such as a private cloud or a hyperconverged cluster, is a separate decision. That decision is set out in a platform comparison built on five decision rules. Storage also needs its own review, while this sheet counts storage only as usage in check 3.
Outside help fits three cases. Support dates for some servers stay unknown after a round of asking. Owners will not sign their workload entries. Or two rounds of work leave the same Unfiled row in place.
Signisys sells this work, and this paragraph is an offer. We provide help to modernize your server estate through our server and data center practice and our infrastructure and networking services. A specialist can read your marked sheet before you set a budget. No charge, with a fixed scope.
Server Modernization Checklist FAQ
Does a virtual machine need its own row on the server modernization checklist?
Can a screenshot from a supplier’s support portal count as the support date record?
What happens to the marks when a server is switched off during the review?
Should branch and colocation servers go on the same sheet as head office?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.