Tie infrastructure decisions to architecture, and operations to a contract.

Infrastructure advisory closes the gap between measuring what exists and designing what should. Sanal Çekirdek runs this work through to handover: who operates the resulting architecture, and within which responsibility boundary, is written at the start.

Separating whoever designs from whoever operates is the most common place responsibility disappears. If the handover boundary is vague, an incident begins with an argument about the boundary.

Start an inventory assessment Back to Cloud and Data Center

Measuring the current estate

Assessment starts with inventory: servers, storage, network, the virtualization layer, backup coverage and licensing position. Capacity and utilization data is collected, and single points of failure, out-of-support components and systems outside current scope are listed by name.

Output: every asset with an owner and a refresh date
The measurement window covers at least one full business cycle
Backup coverage is proven with a restore attempt
Anything left out of scope is recorded with its reason

Target architecture and roadmap

The target architecture is derived from business requirements, and the delta against the current estate is itemized. The roadmap is ordered by dependency; each step states what must exist before it and what will be measured once it completes.

A rollback scenario is written for every step
Budget and procurement calendar are tied to the steps
Division of labor with your team is settled step by step
Priorities are revisited at the start of each quarter

Moving to a managed service

The output of advisory work is not only an architecture but a definition of how that architecture will be run. Which task is performed to which standard, how often and by whom goes into the service definition; the decision to hand over daily operations comes after that is settled.

The service definition is written before operations begin
Each task gets a standard and a frequency
Work staying in-house is listed just as explicitly
Handover is a separate decision, never automatic

What gets delivered

Advisory work ends with usable documents, not a presentation. The inventory, risk list, target architecture, roadmap and service definition are handed over in a form your own team can maintain; we avoid any format that creates a dependency on us.

The inventory stays updatable in your own system
The risk list arrives with owners and dates
Architecture decisions are written with their reasoning
Documents remain usable if the supplier changes

How we work

Collect the inventory and utilization data
List risks and gaps by name
Write the target architecture and the delta
Order the roadmap by dependency
Take over operations within a defined boundary

How success is measured

No gap remains between inventory and actual configuration
Out-of-support components reached zero on the planned date
Backup verification runs regularly, with evidence
Every open risk has an owner and a closing date

Frequently asked questions

How long does an assessment take?

Duration depends on the size of the estate and how accessible the data is. We define scope together; no duration is committed before scope is settled.

Do we have to hand over operations?

No. Assessment and target architecture can be taken on their own; operational handover is a separate decision and does not start before the responsibility matrix is written.

Can you work alongside our current provider?

Yes. Boundaries matter even more in that case: which task sits with whom, who takes over during an incident, and how information flows are all put in writing.

If you want to see your infrastructure as a measured table rather than an impression, let's start with the inventory work.

Start an inventory assessment