Plan Infrastructure Around Business Workloads
Build an infrastructure brief around dependencies, capacity, ownership and recovery so hosting decisions serve the business rather than start with server specifications.
Is this the right guide for you?
- What information belongs in an infrastructure requirements brief?
- How do application dependencies affect infrastructure choices?
- How should I estimate capacity without guessing server sizes?
- Which responsibilities remain with my business when hosting is outsourced?
- How do continuity needs change an infrastructure design?
- What should an infrastructure handover demonstrate?
On this page
Infrastructure is the operating foundation for applications and business information. A good plan explains the workload, its dependencies and its operating responsibilities before selecting machines or hosting services. The same application may need a different design when users, data sensitivity, availability expectations or support arrangements change. Treat those differences as requirements rather than assumptions hidden in a price comparison.
Describe the workload and its dependencies
List user groups, access locations, business hours and the transactions the system must complete. Map connections to identity, databases, file storage, email and external services. A dependency outside your team’s control still affects your service. Document who owns it and what happens when it is unavailable. Microsoft’s migration planning guidance emphasizes dependencies when grouping workloads; the same discipline helps avoid moving an application while leaving a critical connection unplanned.
Size from evidence and uncertainty
Collect current usage where a system exists: concurrent activity, storage growth, processing peaks and response times for important actions. For a new service, state assumptions and design a representative load test. Do not convert a staff count directly into a server size. Distinguish expected load from exceptional peaks, and agree which conditions trigger a capacity review. Include network quality and client devices in the discussion when users experience delays that a larger server would not resolve.
Assign operation and continuity
Write down responsibility for patching, backups, recovery, monitoring, identity, certificates and supplier escalation. A managed platform changes the split of work but does not remove the need to understand it. Agree the tolerable interruption and data-loss window for each critical workflow, then test whether the proposed arrangement can support those objectives. AWS reliability guidance treats disaster-recovery objectives and testing as planning concerns. A second copy of data is not, by itself, evidence of a usable recovery process.
Test the operating handover
Ask the receiving team to explain how they detect a failed service, obtain access, roll back a change and restore an essential record. Keep an inventory and an escalation path that remains available during an outage. Record known limits and the cost implications of growth rather than describing the system as infinitely scalable. Continue with cloud migration, observability or backup recovery. Bring the workload brief to IT Services so a technical proposal can be evaluated against business needs.
Primary references and further reading
Connect the idea to your business.
Start with your goals, existing systems and constraints before choosing a solution.
IT Services