Choose the arrangement that fits your ownership needs
Managed hosting can be convenient when you want one commercial relationship for capacity and routine operation. Server management can fit when the business already owns infrastructure accounts or needs to select providers independently. Either arrangement can work well if the interfaces are clear. Write down who pays the infrastructure bill, who can approve capacity changes and who can recover the account. Avoid an arrangement where both sides assume the other controls a renewal or an emergency access route.
Map responsibility by technical layer
List physical infrastructure, virtual machine, operating system, database, web server, application and external services separately. A provider handling hardware does not automatically maintain the software installed on it. AWS’s shared-responsibility model is one explicit example of this distinction; its details depend on the selected service and should not be treated as another provider’s contract. For your proposal, assign an accountable owner to each layer and name the contact when an issue crosses the boundary.
Separate monitoring from response and repair
Ask what is checked and what happens after an alert. A server responding to a ping does not prove that login, checkout or a customer portal works. Define which customer-facing journeys are monitored, whether someone acts outside normal hours and how an urgent issue reaches the responder. Distinguish an acknowledgement target from a restoration target. Neither term should imply that every incident can be resolved within a fixed time regardless of its cause.
Compare recovery using a realistic failure
Describe a concrete situation: a database was accidentally changed, the server cannot boot or a provider account is unavailable. Ask which copies can be restored, who holds the necessary credentials and where the replacement system would run. Specify acceptable data loss and interruption, then check whether the proposed backup and recovery process can support them. Request evidence of a relevant restore exercise. An enabled backup setting is not the same as an agreed recovery service.
Define backup and recovery work
Connect backup coverage, restore procedures and recovery targets before comparing support packages.
Explore Define backup and recovery workBuild a comparison with all recurring responsibilities
Include infrastructure charges, management, software licenses, backup storage and support options in the comparison. Identify capacity changes that need approval and work that needs a separate estimate, such as a platform migration or major application upgrade. Ask who maintains integrations with email, DNS and certificates when those sit outside the hosting account. Record what happens when an incident requires help from the application developer. The cheapest line item may leave the business coordinating the most work.
Accept the service with a responsibility sheet
Before moving a workload, require a named inventory, account ownership record, access procedure, maintenance process and escalation path. Confirm backup coverage, recovery responsibilities and the handover process if the service ends. Use one relevant operational exercise to check the promised boundary, such as tracing a failed application request from monitoring to the responsible team. Revisit the sheet when a database, domain or external service is added. Coverage should change deliberately as the system grows.
Review server management scope
Use the agreement checklist to turn general service wording into explicit obligations.
Explore Review server management scopeExplore managed hosting
Compare operating requirements alongside the infrastructure that will run the workload.
Explore Explore managed hosting