Cloud
The technology domain this engagement operates — capabilities, architectures and the full picture.
Managed Cloud
Your cloud platform, operated — patching, cost, capacity and incidents under one rhythm.
The operating model
Managed cloud is the ongoing operation of your cloud estate: keeping platforms patched and in support, backups taken and verified, costs reviewed while they are still decisions rather than surprises, capacity ahead of demand, and incidents worked to resolution. The cloud capability pages describe architectures and migrations — projects with an end. This is the service that has no end date, which is precisely its point.
The recurring failure in cloud operations is not outage but drift: costs that grow without a decision, configurations that wander from baseline, backups that run but are never restored. The rhythm below exists to make drift visible on a schedule, because drift discovered by an auditor or an invoice is the expensive kind.
The rhythm of the engagement
What actually happens — by day, by week, by month, by quarter. If a provider cannot describe this, they are selling a tool, not a service.
Daily
Monitoring and alert response within the coverage window; backup job verification — ran, completed, and the failures chased same-day rather than noticed at restore time.
Weekly
Cost review against budget and the trend line, with anomalies investigated while the spend is still small; patch and change window planning for the week ahead.
Monthly
Service review: incidents and their causes, posture drift against the agreed baseline, capacity against growth, cost against forecast, and the actions register.
Quarterly
A restore test on a service you choose — measured, not assumed; a right-sizing and commitment review with the licence and reservation consequences priced; and a baseline review as the providers change under everyone.
How escalation works
Severity definitions and response objectives are agreed at onboarding and written into the runbook — they are commitments made to you, not marketing figures published here.
Severity 1 — service down or data at risk
A production service unavailable or data integrity in question. Worked continuously under the agreed authority until restored; named contacts engaged directly; written timeline follows.
Severity 2 — degraded or exposed
Performance degradation with user impact, or a posture finding that is exploitable rather than theoretical. Worked ahead of routine operations; changes proposed through the change process unless pre-authorised.
Severity 3 — routine
Requests, non-urgent findings and scheduled work, handled within the window in agreed order — and visible in the same queue you can read, because a hidden backlog is a dispute in waiting.
Onboarding, phase by phase
Sequenced so that value starts before the last phase finishes. Dates go into the plan we agree together; phases are what the plan is made of.
Access and inventory
Scoped operational access under your identity model, an account-by-account inventory, and the statement of what is in service scope and what is explicitly not.
Baseline and runbooks
The posture baseline agreed and measured, backup coverage verified by an actual restore, and runbooks written for the incidents your estate can actually have.
Change and authority
The change process joined to yours — windows, approvals, emergency path — and the authority matrix for what we may do without asking.
Live operation
The rhythm begins; the first monthly report measures onboarding itself against the inventory and baseline from the first two phases.
What we run, and what stays yours
A managed engagement fails quietly when this table was never written. Ours is agreed before the service starts.
| Area | NexMena | You |
|---|---|---|
| Platform operations and patching | Plan, execute in windows, report | Approve windows; own application-layer testing |
| Cost | Monitor, investigate anomalies, recommend with numbers | Decide — spend commitments and reservations are yours to sign |
| Backup and restore | Run, verify, test on the quarterly cycle | Set the recovery objectives the tests are measured against |
| Architecture change | Propose when operations expose the need | Own the decision — a managed service that quietly re-architects your estate is overreaching |
What you receive, and when
Reporting exists so you can judge the service without asking for a meeting.
- Incident notifications and closure summaries as they happen, written for the audience that has to act on them.
- The monthly service report: availability, incidents, cost against forecast, posture drift, capacity, and both sides' open actions with ages.
- The quarterly review: restore test results with measured times, right-sizing recommendations priced, and the baseline changes proposed for the next quarter.
Questions we are asked
Which clouds does this cover?
AWS, Azure and GCP, singly or mixed, plus the hybrid estates most organisations here actually run. The service scope statement from onboarding names what is covered account by account, so there is never a dispute about whether something was ours to watch.
How is this different from the cloud optimization page?
Optimization is a project: it finds the savings and ends. This is the operation that keeps findings true — the weekly cost review exists because estates drift back within months of a one-off exercise. The two meet in the quarterly right-sizing review, which is a small optimization cycle run on a schedule.
Do you take over our cloud accounts?
No. Access is scoped operational access under your identity model, visible in your audit logs like any other administrator. Ownership of the accounts, the billing relationship and the root credentials stays with you — a provider that asks otherwise is asking for your leverage.
Can our own team still make changes?
Yes, through the same change process — that is what makes it one process rather than two estates. The monthly report separates changes by origin, so when something regresses, the question of what changed has an answer instead of an argument.
What about the applications running on the platform?
The split is platform versus application, drawn precisely in the onboarding scope. We operate to the platform line — instance, cluster, managed service, backup of it all; your application deployments and their behaviour stay yours unless separately agreed. Vague versions of this boundary are where managed cloud disputes live.
What if we want to leave?
Everything the service produces — runbooks, baselines, reports, the actions register — is yours and stays in your systems. Offboarding is a defined phase, not a negotiation: access revocation, handover walkthrough, and the final report. A service you cannot leave cleanly is a service you should not enter.
Continue reading
Managed Services
The delivery model in general: how managed engagements work across every domain.
Cloud Optimization
Tagging, cost allocation, right-sizing and commitment planning for cloud spend you can attribute to a named owner and explain line by line.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.