What a two-week infrastructure assessment should deliver

What two weeks can and cannot do

Two weeks is roughly ten working days. That is enough to understand an agreed part of an estate in depth: a platform, a set of applications, a migration candidate or a delivery pipeline. It is not enough to assess everything you run, and an assessor who promises that is promising a shallow report.

So the most important document is written before the work starts: the scope. It should name the systems and environments in scope, the questions the assessment must answer, what is out of scope, and who on your side is available. A typical split is about half the time on discovery and interviews and half on analysis and writing. An assessment is not implementation either. If changes start during the assessment, the findings stop describing the estate you actually have.

What you should prepare

Most assessments lose their first days waiting for access. Arrange read-only access to the systems in scope before day one, and gather what already exists: architecture diagrams, however out of date, inventory or CMDB exports, monitoring dashboards, the last six to twelve months of incidents and changes, and the renewal and end-of-support dates for the licences and contracts involved.

Book time with the people who know how things really work: the engineers who run the platform, the people who deploy to it, and the owner who pays for it. A few hours of interviews each is usually enough. Written documents describe the intended system; people describe the real one.

How the two weeks usually run

A well-run assessment has a visible rhythm. The first two or three days go on kickoff, access and interviews, confirming that the scope and questions still hold once the assessor has seen the estate. The middle of the first week and the start of the second go on hands-on discovery: reading configurations, tracing dependencies, checking what monitoring and backups actually do, and walking through the delivery pipeline with the people who use it.

The last few days go on analysis and writing. Ask for a short check-in at the end of each week. The first one catches a wrong assumption while there is still time to correct it; the second previews the main findings so the read-out contains no surprises for the people most affected. If you hear nothing for ten days and then receive a finished report, the assessor has worked around you, not with you.

A picture of what exists

The first deliverable is an accurate description of the current state. For infrastructure that means the topology: systems, dependencies, data flows, versions and support status, including anything already past end of support. For delivery it means the pipeline: how a change reaches production, who approves it, what is tested on the way, and how a bad release is rolled back.

A good assessment separates what was verified from what was reported. "The backup runs nightly" means one thing when someone says it and another when the assessor has seen a successful restore. You should be able to tell which is which.

Findings ranked by risk, with evidence

Every finding should carry its evidence, its impact, how likely the problem is to bite, and roughly what it takes to fix. Then the findings should be ranked. A 200-item list with equal weight is a transfer of work, not a result. You want to know which five things matter this quarter.

Keep urgent risks apart from improvements. Unsupported versions, single points of failure and backups that have never been restored belong at the top. Tidier naming conventions do not. A consistent lens helps: review each system for reliability, security, cost, operability and performance, and use recognised, vendor-neutral references for the detail, such as the NIST Cybersecurity Framework for security, which is organised around six functions: govern, identify, protect, detect, respond and recover. Use a framework as a checklist for coverage, not as the deliverable itself.

A target architecture you can defend

The target architecture should be a written document, not a diagram alone. It should say what the estate should look like, why, which alternatives were considered and why they were rejected, and which constraints shaped the choice: budget, skills, contracts, regulation or timing.

It should also say what stays as it is. A target that replaces everything is rarely credible, and the parts that are fine are useful to know too.

A sequence with a way back

A target without a route is a wish. The assessment should propose an order of moves based on dependencies and risk, with a rollback plan for each move and clear decision points where you can stop, change course or continue.

It should also state the cost of doing nothing: licence renewals that will lock you in for another term, versions that fall out of support on known dates, and risks that grow while nothing changes. That is often what makes the case for acting, or for deliberately waiting.

A read-out for the people who decide

The last deliverable is a read-out for leadership: the decisions that are needed, the options for each, their risks, and rough effort. It should be possible to act on it without the assessor in the room. The detailed documents stay with your engineers.

Implementation should be quoted separately and never be a condition of the assessment. The findings are only trustworthy if they would be the same whether or not you hire the assessor to fix them.

After the read-out

An assessment is only worth its fee if something happens next. Turn the ranked findings into a backlog your team owns, with an owner and a target date for the top items. Some risks, such as an unsupported version in production or a backup that has never been restored, should be fixed within weeks whatever else you decide.

Then use the target architecture and sequence to decide how to deliver: with your own team, with the assessor, with another provider, or with a mix. Because the documents are yours, that choice stays open. Revisit the findings after a quarter; an assessment that is still accurate six months later, and whose top risks have been closed, did its job.

Red flags

Be wary of findings without evidence, generic best-practice lists that could describe any company, and recommendations that only the assessor's own product can satisfy. Be wary of an unranked list, a target architecture without a migration route, a migration route without rollback, and a scope that quietly grew to "everything" without growing the time.

Finally, check who owns the output. You should receive every document in an editable format and be free to share it with anyone, including another provider.

How our Assessment Sprint maps to this

Our Assessment Sprint is built around these deliverables: a two-week review of the agreed environment, a topology and delivery pipeline audit, a written target architecture, a migration sequence with rollback plans, and a leadership read-out. It is a fixed fee, the scope is agreed in writing before payment, and any implementation is quoted separately.