# Keep the software running after launch Running software needs an owner after launch. We agree who watches the important journeys, who responds when they fail and how maintenance fits alongside new work. - Systems: 24 - Uptime: 99.98% - On-call: 24/7 ## Launch changes the work Once people depend on a service, a broken integration can stop their day even when the application itself is online. Someone needs to notice that failure, understand its effect and restore the work. A handover document alone does not provide that responsibility. We start by mapping the user journeys and the systems behind them. Together we decide which failures need immediate attention, which can wait for working hours and who has authority to make changes during an incident. ## Establish an operating baseline Before taking responsibility, we check access, deployment and recovery. Backups need a demonstrated restore path. Alerts need a person who can act on them. We record external dependencies and the limits of what our team controls. We agree service boundaries and measurement with you before setting targets for your environment. A useful reliability discussion starts with the work users must be able to finish, rather than a percentage detached from their experience. ## Timing and taking responsibility Onboarding follows the state of the system. If nobody can produce a repeatable release or restore a backup, those gaps must be addressed before a confident handover. We show the findings as we go, so you can see the difference between accepted responsibility and work still needed to make it safe. We agree the start of support coverage, escalation contacts and review cadence in writing. There should be no uncertain interval in which the previous team has left and the new team assumes someone else is watching. ## Keep routine work funded Dependencies change, certificates expire and small faults accumulate. We make that work visible in the same planning process as product changes. Incidents lead to proportionate follow-up, with a person and time assigned to each agreed repair. Your team keeps administrative control of accounts. We maintain operating notes as part of changes and practise recovery where a failure would cause material disruption. Read [why ownership starts at go-live](https://sunclue.com/insights/go-live-is-where-ownership-starts/) for the responsibilities to settle before launch. ## When the system needs a larger change Sometimes repeated operational work points to a structural problem. We separate immediate service care from a proposed migration, explain the evidence and agree the additional scope. [Modernisation](https://sunclue.com/services/transform/) then proceeds with continuity of service as an explicit requirement. ## Questions ### Is this a round-the-clock support contract? Coverage is agreed explicitly. Response arrangements, escalation and the systems covered belong in the engagement agreement, including any round-the-clock on-call requirement. ### Can you take over software another team built? Yes, after a review of access, releases, monitoring and recovery. We identify gaps before accepting responsibility and agree what must be repaired first. ### How are improvements prioritised? We review production evidence and business needs with you. Repeated incidents, risky dependencies and work that blocks users compete openly with feature requests for the available time. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Build a product people can use](https://sunclue.com/services/build/) - [Get a stalled project moving again](https://sunclue.com/services/rescue/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All services](https://sunclue.com/services/) --- [Canonical HTML page](https://sunclue.com/services/own/) ยท [Sunclue reading guide](https://sunclue.com/llms.txt)