SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

Hand over operations — not visibility.

Remote infrastructure management transfers the daily operational load within a defined scope. Sanal Çekirdek sets that transfer up without reducing your visibility: you see the same dashboard we do.

The success of a handover is measured by how clear the responsibility boundary is. If it is not written down, an incident starts as an argument about the boundary.

Responsibility boundary and handover

Handover begins with a responsibility matrix: every task has an owner, a backup and an escalation path in writing. Tasks that are not taken over appear in the same document — no silent gaps.

  • Tasks not taken over are named in the same document
  • Escalation is defined by role, not by person
  • Access rights are reviewed as part of handover
  • Records before and after the handover date are separated

Monitoring, alerting and incidents

Monitoring starts with the service, not the device: where is the user affected, which dependency chain is breaking. Alert thresholds are tuned to avoid noise, and every alert carries an action.

  • An alert with no action is switched off
  • Incidents are prioritized by business impact
  • Recurring incidents go into a root-cause record
  • Closure requires user confirmation

Patch and change management

The patch calendar is bound to capacity and maintenance windows, with a separate path defined for emergency patches. Every change is recorded with its rationale, its impact and its rollback plan.

  • The emergency path is distinct from the normal calendar
  • No change record opens without a rollback plan
  • Change windows are agreed with the business calendar
  • Failed changes are reported separately

Reporting and review

Reports exist to support decisions, not to narrate history. The same indicators repeat every period so trends become visible, and investment decisions rest on them.

  • Indicators stay the same across periods
  • The trend matters more than any single period
  • Items needing a decision sit on a separate list
  • Reports can be verified from your own tooling

How we work

  1. Write the scope and the responsibility matrix
  2. Build the monitoring and alerting baseline
  3. Hand over in stages, with a shadow period
  4. Run patch and change management
  5. Update scope through regular review

How success is measured

  • No gap remains in the responsibility matrix
  • Alerts carrying no action keep declining
  • Recurring incidents are tied to a root cause
  • Every change has a rollback plan, without exception

Frequently asked questions

Does this replace our own team?

The aim is to take the repetitive operational load, not the team. Your people move toward architecture and business-facing work; the boundary exists to make that explicit.

Will you have access to our data?

Access is scoped as narrowly as the work requires and is logged. Which role reaches what is written in the matrix, and unnecessary access is removed during handover.

Will there be downtime during handover?

Staged handover and a shadow period exist to prevent it. The incoming team runs alongside current operations for a while, and responsibility transfers fully only once indicators are stable.

Before handing over the operational load, let's make the boundary explicit: share your current scope and we will write the matrix together.

Let's write the responsibility matrix