Your application is in the cloud, the hosting invoice is paid and the provider reports that its platform is healthy. Customers still cannot place orders. A deployment changed the application's configuration, and nobody is sure whether the hosting company, the development supplier or your internal team should respond.
Cloud services can remove substantial infrastructure work. They do not remove the need to decide who owns the customer journey. That distinction becomes especially important when a growing company connects its website, ERP, identity provider and AI services through several suppliers. Every component can have an owner while the complete business process has none.
Buy an operating model as well as capacity
A cloud proposal often starts with service names, storage capacity and estimated monthly charges. Add another page describing how the system will be operated. It should answer who approves changes, receives alerts, restores information and decides that the business is working again after an incident.
Use actual tasks rather than broad labels. “Security managed by supplier” is too vague to explain who removes a departing employee's access or reviews a new integration permission. “Backups included” does not establish who performs a restore, where the restored system runs or how the recovered records are checked.
For a customer ordering portal, list the dependencies needed to complete one order: sign-in, catalogue, pricing, payment where applicable, ERP submission and confirmation. Follow the same exercise for a staff member resolving a failed order. The resulting map often exposes gaps that a list of hosting resources misses.
Understand the responsibilities that remain with you
Microsoft's shared-responsibility guidance distinguishes infrastructure, platform and software services. The division changes with the service model, but customers continue to have responsibilities for data, identities and the configurations they control. That distinction is an architectural guide, not a replacement for the actual agreement. See Microsoft's cloud responsibility model.
Translate that principle into a named owner for each operational task. A managed database can reduce the work of maintaining a database server, while the application team still needs to understand its schema changes, queries and data access. A hosted identity service still requires your company to decide which people should have which roles.
Make the distinction visible to nontechnical decision-makers. A director approving a cloud migration should understand what work disappears, what remains and what new coordination is required. Otherwise, the expected saving can be overstated and the remaining work can go unbudgeted.
Assign responsibility across supplier boundaries
Take the failed-order example and organise a short tabletop exercise. The website reports success, but the order is missing from the ERP. Who checks the request record? Who can inspect the integration? Who contacts the customer, and who is authorised to replay the transaction?
Document a primary owner and a fallback for each step. Include the information each supplier needs to investigate, such as timestamps and correlation references. Agree how that information can be shared without sending an unnecessary copy of customer records to every participant.
One party should coordinate the business incident even when the underlying fault belongs to another supplier. This does not mean that one supplier accepts unlimited responsibility for everything. It means the customer has a coherent response while the technical teams work out where the fault sits.
Match service choices to the team that will run them
Consider the capacity and experience available after the project team leaves. A design that depends on specialist intervention every week may be unsuitable for a company with a small internal team, even if its estimated infrastructure bill looks attractive.
Ask each proposed managed service which tasks it removes and which limits it introduces. Discuss supported runtimes, maintenance behaviour, scaling boundaries, network requirements and available recovery options. Record the reasons for selecting the service so a future maintainer can understand the trade-off.
Portability also deserves a practical discussion. Your business may reasonably accept a provider-specific feature because it delivers value. Still, identify how you would export the data, reproduce essential rules and regain access if the current supplier relationship changed. A theoretical claim that the system can move anywhere is less useful than a demonstrated export and a documented dependency list.
Define recovery around business records
An available server does not prove that the last hour's orders are accounted for. Decide what evidence is needed before normal work resumes. For an ordering portal, that might include comparing accepted requests with ERP orders and identifying requests that need a customer follow-up.
Distinguish infrastructure recovery from reconciliation. Restoring a database can bring back records, but external systems may have continued processing while the application was unavailable. The support team needs a method for finding incomplete work without creating duplicates.
Discuss recovery targets with the people who experience the consequences. The acceptable interruption for an internal reporting page may differ from the acceptable interruption for dispatch. Record those differences and test the important journeys. Avoid buying the same resilience design for every application simply because it makes the proposal easier to standardise.
Make monthly reviews explain the service
A useful service review combines spending, incidents, changes and outstanding risks. Review whether the system continues to meet the needs that justified it. An increase in cost may be reasonable if the business is completing more valuable work; a flat bill can still conceal poor performance.
Look at repeated work as well as major outages. Recurring manual corrections, delayed integrations and inaccessible diagnostic information can consume substantial staff time without generating a dramatic incident report. Agree which of those problems will be addressed through maintenance and which require a separate development decision.
Keep ownership records current when staff or suppliers change. Include renewal dates, access arrangements and the location of operational documentation. A cloud system should not depend on one former contractor being the only person who knows which account controls it.
A practical cloud review with Worktechlabs
Worktechlabs can help review an application's hosting, integration and support arrangements, starting with the journeys that matter to your customers. A useful starting package includes an architecture sketch, recent incidents, a cost summary and a list of current suppliers.
The first outcome can be a responsibility map with a prioritised set of changes: close an access gap, improve a diagnostic trail, rehearse a restore or simplify an integration. Connect that work to an agreed support arrangement and a realistic delivery plan. Cloud value becomes easier to assess when the company can explain who keeps the service working and how it will respond when something fails.
Official guidance reviewed on 7 October 2026. The examples describe proposed operating practices; responsibilities and service commitments must be agreed for the actual workload.
