There is no rule that the website developer must also host the website. The better question is whether the organisation wants one supplier accountable for the application and its hosting environment, or whether infrastructure is already managed elsewhere. The tender should make that operating model explicit.
Define who owns the environment
If hosting is included, state whether the client will have administrator access, how accounts are registered and what happens at contract termination. The organisation should not become trapped because a supplier controls the only account.
Specify operational requirements
Availability expectations, backups, security controls, SSL, monitoring, resource limits and support should be described at a practical level. Avoid asking for impressive infrastructure terminology that is unrelated to the website workload.
Protect DNS and email continuity
Website hosting changes can affect DNS and, if handled carelessly, email. The project plan should identify which DNS records must remain unchanged and who approves changes during migration.
Ask about restoration, not only backups
Tender responses should explain how recovery works, not just state that backups exist. Recovery responsibility and expected restoration procedure matter when something actually fails.
Plan the exit before signing
Portability is part of good procurement. Define what data, files, database exports, credentials and configuration information will be supplied if the hosting or support relationship ends.
What to do next
Use this as a working checklist for your organisation, then adapt it to the actual platform, risk and procurement context. If you are preparing a website project, takeover or ongoing support requirement, WebNT can review the scope with you before implementation begins.