Reporting complexities of a Windows Server migration can be simplified by following against two KPIs.
The obvious thing to track whilst running a Windows Server migration project is how many servers are being tackled on a weekly basis. This is the most effective, simple KPI to report to the project board. The problem with this is that it is likely there will be a lot of preparation work prior to servers being migrated.
New servers will need to be provisioned, storage will need to be allocated, back-ups, archives and testing needs arranging. All of the stakeholders will need to get used to your continuous changes. As many changes are on a trial and error basis, even after comprehensive testing, the CAB board will need to be prepared for the numerous change requests that may complicate and affect their reporting statistics negatively. Necessary preparation will mean that the project momentum or the perception of it will be slow for the first phase.
In addition to the number of Windows Servers being migrated it is obvious that you will need to track the applications and services running upon these servers. These can be standard Microsoft applications and roles or Line of Business (LOB) applications. The applications run at a higher level than the OS and hardware, you know that already. The dependencies, knowledge and effort to remove or migrate these applications needs to be tracked. And it's likely once you tracking all applications and servers it becomes difficult to manage. For the project board you need to report the progress of the servers, but to IT it is likely the status of the applications are of paramount importance. Each application is it's own mini-project within your work stream, each with their own beginning, middle and end and all with dependencies and effectively its own RAID log.
Once the project is really in motion we work on the basis that a single, experienced server resource can organise the migration or decommission of three server types within a week. You may have tens or hundreds of servers or exactly the same type, so it is possible that more than three actual servers are migrated - but we generally see no more than three "types" or roles managed within a week. Even if you managed more Windows server types, the nature of change, CAB and risk avoidance and the "cats cradle" of large infrastructures means that you would not implement change across all of them in a short period.
Therefore the project team needs to be pragmatic, driven and able to push beyond the inertia that a multiple-technology project presents. It's a lot more difficult than it seems, especially as some of the depencies start to build-up. Therefore I would recommend you review and assess each application load and each server on a daily basis and keep pushing each one forward, even if it means small steps.
In summary track and report upon your project from a server-level and keep an addition eye at the application level. The application level is too technical for the project board and discussions at this level will almost certainly complicate matters. In addition ensure you review and track each server type and application on a daily basis.