Translate the workload into a server brief
| Area | Evidence to prepare |
|---|---|
| Compute | Observed busy periods, concurrent activity and services competing for resources. |
| Storage | Working set, growth, log activity and measured storage response under load. |
| Network | Required client and provider paths, limits and change responsibilities. |
| Operation | Remote administration, maintenance approval and incident escalation. |
Separate the production platform workload from auxiliary reporting, backup and integration jobs. A larger specification may be unnecessary if a different service is creating the contention.
Evaluate a failed machine as well as a running one
Ask who diagnoses a hardware fault, authorises replacement and restores the environment. Identify the configuration, credentials and usable data needed on the replacement machine. A dedicated server with untested backups still has an unresolved recovery dependency.
Review maintenance windows and the effect of planned restarts. If spare or alternative capacity is part of the proposed scope, document how it is prepared and activated. Treat an advertised hardware support service separately from a demonstrated application restoration procedure.
Use repeatable acceptance evidence
Agree a representative workload and observe the application together with CPU, memory, storage and network behaviour. Include routine operational jobs and record the versions, conditions and known limits of the exercise. Acceptance should refer to the tested workload rather than a generic account-capacity claim.
Bring the evidence to the MT5 requirements review, then choose dedicated or virtual infrastructure on that basis. The platform deployment arrangement must also establish who may install, configure and administer the relevant software.