The configuration of an existing server tells you what was purchased. It does not tell you what an application needs. Before moving a workload, separate its actual demand from the capacity it happens to have today. A short, repeatable sizing exercise gives both your team and your infrastructure provider a better starting point.
Start with the business transaction
Describe what people do with the application before listing its specifications. A reporting job, an internal document system, and a public ordering service can use the same operating system while placing very different demands on infrastructure. Write down the busiest user journey, the cost of delay, and the hours when the application matters most. Identify a business owner who can explain what acceptable performance looks like. A useful statement might be that a month-end report must finish before the finance team starts work. This is more actionable than asking for a server that is simply fast. Keep the description next to the capacity measurements so the numbers retain their business context.
Measure across the actual demand cycle
Choose an observation period that includes normal activity and a meaningful peak. Record processor use, memory pressure, disk activity, storage consumption, and network traffic. Use consistent time intervals and preserve timestamps. An average can conceal a brief but important surge, while a single busy sample can overstate sustained demand. Note scheduled jobs, backups, software updates, and user activity alongside unusual measurements. If a monthly event is important but has not been observed, record it as an open assumption. Do not turn an unmeasured period into a confident estimate. Keep the raw measurements available so a later configuration review can compare similar periods.
Find the bottleneck before adding capacity
A slow request does not automatically require more processors. Walk through the path from the user to the application, its dependencies, and its data. Look for waiting on storage, an exhausted connection pool, a serialized task, or an external service. Compare response times with resource activity at the same timestamps. Change one meaningful variable at a time when practical, and define the expected improvement before testing it. If extra capacity does not change the user outcome, preserve that result. It can prevent an expensive configuration from becoming the default answer to a problem that belongs elsewhere in the system.
Account for what travels with the application
List runtime versions, licenses, service accounts, scheduled tasks, mounted storage, certificates, and external connections. Record which items are essential for startup and which are needed only during particular workflows. Include growth in data volume and any temporary space used during processing. Check whether a software license depends on a host, processor count, or other infrastructure property. The migration plan needs those constraints before a configuration is selected. Keep confidential credentials out of the inventory itself; record the owner and the approved retrieval process. A complete dependency list is often more useful than another round of hardware specifications.
Choose headroom deliberately
Headroom is an operating decision, not a universal percentage. Document which demand changes the initial configuration needs to absorb and how quickly capacity can be changed. Consider the effort of a resize, any maintenance window, software behavior, and the uncertainty in your baseline. Distinguish predictable growth from a temporary event. Ask for the available configuration increments and the procedure for increasing or reducing resources. Then agree a review date and the evidence that would trigger a change. This makes the initial deployment a measured starting point rather than a permanent guess. Avoid presenting a planning estimate as a performance commitment.
Compare sizing candidates
For order-processing workloads, measure the web tier, database, and scheduled imports together. When average CPU use looks modest but searches slow down during an import, investigate whether the two activities compete for CPU, memory, or storage access. Include the start and finish times of each scheduled job so the busiest periods can be identified accurately. Collect observations from both periods before choosing a larger machine. Record the query, elapsed time, concurrent activity, and resource behavior so the comparison can be repeated. If the database waits on storage, a CPU increase alone may not address the constraint.
Put two candidate configurations beside the same acceptance criteria. Include the normal transaction, the import, and a combined run. Keep the application version and data set consistent. Ask which changes require a restart and how to return to the previous configuration. After the test, record whether each candidate met the agreed application goal and what tradeoffs remain. A useful decision record can fit on one page: observed constraint, proposed configuration, test evidence, expected demand change, review date, and owner. If the evidence is incomplete, identify the missing measurement explicitly. This makes a sizing conversation actionable while tying the selected configuration to the evidence collected for that workload.
Validate the move with the same workload
Before cutover, select a small set of representative transactions and define how they will be evaluated. Capture the baseline, data size, test conditions, and application version. Run comparable checks in the proposed environment, including dependencies and background jobs. Have the application owner review the results. After migration, compare another normal and peak period against the original observations. Record what changed and why. The final planning brief should include a resource baseline, important constraints, a validation method, a capacity review owner, and unresolved assumptions. Bring that brief to a CloudCPO compute discussion so the proposal can respond to the workload instead of relying on an old server label.