Responsibilities defined by the selected service
Cloud, hosting & technical support
Give your systems a clear plan for daily operation
Putting an application online is only the beginning. Someone still needs to manage access, updates, backups and incidents. A useful hosting and support arrangement makes those responsibilities visible, so your team knows what is covered, who owns each account and what happens when a service needs attention.
Discuss your projectA shared delivery plan
From an operational inventory to clear day-to-day ownership
We propose these stages to establish and review an agreed hosting or support arrangement. The scope names the covered systems and responsibilities. Migration, backups, monitoring and ongoing assistance are included only as specified in that agreement.
We agree the stages, outputs and responsibilities in your project scope. Select a stage to explore the work and decisions.
Lava: delivery workYour team: inputs & approvalsTogether: acceptance & priorities
A worked example · illustrative
An alert is the start of a response—not the whole response.
Illustrative operational flow: connect monitoring to ownership, recovery and verification within the agreed support scope.
- ObserveCollect the agreed health or incident signal→
- TriageIdentify impact, priority and responsible owner→
- Act & recoverFollow the authorized runbook or escalate→
- VerifyCheck service behavior and data as applicable→
- LearnDocument the cause and prevention work→
Operational tasks, changes and escalation routes
Business priorities, access and required approvals
From scope to operation
The work at each stage
Open each stage to see the work, your role, the deliverables and the check before moving forward. Feedback can return a decision to an earlier stage.
Map the current environment
Identify the services your business depends on and who controls them.
What Lava does
Review applications, hosting, domains, dependencies and administrative access; record known problems and operational gaps.
Your team provides or approves
Provide authorised access, supplier contacts and the business impact of interruptions to each important service.
Stage outputs
- System and dependency inventory
- Access and responsibility map
Ready to move forward when…
Important services have identifiable owners and unexplained dependencies are recorded for investigation.
Review loop Revisit the inventory when an unlisted service changes the proposed operating arrangement.
Agree the operating requirements
Choose an approach that fits the application and the business responsibilities.
What Lava does
Compare suitable hosting options and define scoped access, backup, monitoring and maintenance arrangements; include migration planning only where agreed.
Your team provides or approves
Confirm tolerable downtime and data loss, storage constraints, budget assumptions and support contacts.
Stage outputs
- Proposed operating design
- Responsibility and recovery requirements
Ready to move forward when…
The proposal distinguishes provider responsibilities, Lava’s work and the duties retained by your team.
Review loop Return to requirements when a provider restriction prevents the intended operating or recovery approach.
Prepare and check the setup
Configure the agreed environment before it carries operational responsibility.
What Lava does
Set up the included hosting, deployment, certificates, access controls and backup or alert configurations.
Your team provides or approves
Confirm account ownership, authorise required service changes and provide application-specific configuration decisions.
Stage outputs
- Configured environment and deployment record
- Access, backup and alert configuration record
Ready to move forward when…
The setup matches the agreed design and required dependencies are available for testing.
Review loop Revisit the design when configuration reveals an incompatibility or unexpected dependency.
Verify the operational controls
Test the arrangements that will be relied on after handover.
What Lava does
Check agreed access, deployment and alert scenarios; carry out a representative restoration where included.
Your team provides or approves
Confirm the recovered or deployed application meets business needs and verify the alert recipients and escalation route.
Stage outputs
- Operational verification results
- Recovery findings and unresolved limitations
Ready to move forward when…
Agreed checks have recorded results; untested recovery assumptions remain identifiable as unverified.
Review loop Return to configuration when restoration, notification or access checks reveal a gap.
Respond with clear decisions
Use an agreed incident scenario or a covered incident to make response responsibilities practical.
What Lava does
Triage symptoms, record impact and coordinate the response within scope; request approval before disruptive actions.
Your team provides or approves
Confirm business priorities and authorise required actions through the agreed decision maker.
Stage outputs
- Incident or rehearsal record
- Response checks and remaining actions
Ready to move forward when…
Agreed service checks establish the current status, with owners and next steps for unresolved items.
Review loop Escalate or pause when permissions, coverage or recovery steps are unclear; revise the operating plan.
Review and hand over care
Make the responsibilities and instructions usable by the people taking over.
What Lava does
Review recurring issues and proposed changes; update scoped operating instructions, supplier dependencies and escalation responsibilities.
Your team provides or approves
Confirm ongoing owners, decide improvement priorities and review how to report incidents with useful context.
Stage outputs
- Operational handbook and account register
- Support coverage and escalation record
Ready to move forward when…
The nominated owners can find the instructions and explain who handles a representative incident.
Review loop Revisit procedures when the handover exposes an ownerless task or unclear supplier boundary.
Start with the systems you rely on
The first step is an inventory of the websites, applications, domains and external services involved. We identify how they connect, who can administer them and which interruptions would affect essential work. This establishes the priorities before selecting a hosting model or proposing a support arrangement.
The work can suit a new deployment, a move from an existing host or an organisation that needs clearer operational ownership. A managed platform can reduce some infrastructure work, but it does not automatically remove responsibility for application configuration, user access or business data.
What an operational scope can include
The proposal names the systems and responsibilities covered. Depending on the environment and requirements, it can include:
- A review of the existing setup, dependencies and administrative access, with a documented target environment and migration approach where needed.
- Configuration of agreed hosting, domains, certificates and deployment processes, using accounts with clearly defined ownership.
- A backup arrangement that identifies what is protected, where copies are held, how long they are retained and how restoration will be checked.
- Monitoring and alerts for selected service conditions, with named recipients and an agreed process for investigating incidents.
- Planned maintenance and support procedures, including update responsibilities, escalation contacts and operational handover documentation.
Agree the operating rules before an incident
| Decision | What needs to be explicit |
|---|---|
| Managed service or self-managed environment | Compare control, maintenance workload, application requirements and provider restrictions. The service model changes the division of responsibilities. |
| Backup and recovery | Choose how much recent data loss and downtime the business can tolerate, then assess the arrangements and restoration work needed. |
| Support coverage | Define covered systems, contact channels, working hours and response expectations. A response target is different from a guaranteed resolution time. |
Verify the setup and leave a usable handover
Your team provides authorised access, service contracts, known issues and contacts for other suppliers. We need to know which information is important, where it may be stored and which changes require business coordination. The hosting decision should consider location, access controls, dependencies and ongoing charges; provider subscriptions and support fees should be distinguishable.
For a migration, agree the cutover, checks and rollback conditions before moving traffic. For ongoing operation, verify the relevant deployment process, alerts and a representative restoration where included. Handover records account ownership, recovery instructions and escalation paths. The agreed scope should make clear whether application fixes, content changes, new features and third-party outages are covered or require separate work.
Questions before starting
Can you support a website or application built by someone else?
An initial assessment is needed. Support depends on access, documentation, technology, licence restrictions and the condition of the system. The proposal can identify what is supportable and any prerequisite remediation.
Does cloud hosting mean our data is automatically backed up?
Do not assume it does. Check the actual service configuration, coverage, retention and restore process. A backup should be judged by what can be recovered, not simply by whether a successful job was reported.
Is round-the-clock support included?
Coverage is defined in the agreement. Confirm operating hours, incident channels, escalation and response expectations before relying on a service. Availability guarantees or particular recovery targets should only be stated when explicitly agreed.
Handover & ongoing care
Ongoing care: review what the service actually covers
Support hours, response expectations and maintenance duties follow the agreement. A response target is distinct from a resolution guarantee, and a completed backup job is distinct from a verified restoration.
- Keep access, alert recipients and recovery instructions current as systems change.
- Review incidents and proposed changes against the covered systems and responsibilities.
Sources & further reading
A useful next step
Bring one real workflow.
A sample document, the systems you use and the decision you need to make are enough to start a focused conversation.
Talk to Lava ↗