What a two-week infrastructure assessment should deliver

Define the two-week scope

Use a two-week assessment to examine an agreed part of your environment in depth: a platform, application group, migration candidate or delivery pipeline. Set a scope that fits roughly ten working days.

Before discovery, agree the systems, questions, exclusions and people involved. Reserve time for analysis and documentation. Keep implementation separate so the findings describe the environment you assessed.

What you should prepare

Prepare read-only access before kickoff. Gather architecture diagrams, inventory or CMDB exports, monitoring dashboards, six to twelve months of incident and change history, and license renewal and support dates.

Include platform operators, deployment engineers and the budget owner in discovery. Compare their account of daily operations with the existing documentation.

How the two weeks usually run

Start with kickoff, access checks and interviews. Confirm the scope, then inspect configurations, dependencies, monitoring, backups and the delivery pipeline with your team.

Reserve the final days for analysis and writing. Schedule short weekly check-ins to correct assumptions and review findings before the leadership read-out.

A picture of what exists

Document your current systems, dependencies, data flows, versions and support status. For delivery, trace the route to production: approvals, tests and release recovery. Identify any unsupported components.

Separate verified findings from reported information. Record whether you inspected a backup schedule, observed a successful restore or relied on an interview.

Findings ranked by risk, with evidence

Rank findings by impact and likelihood, with supporting evidence and estimated remediation effort. Identify the priorities your team should address first.

Prioritize unsupported versions, single points of failure and untested recovery by business impact. Use applicable references such as the NIST Cybersecurity Framework and its six functions: govern, identify, protect, detect, respond and recover. Link each finding to evidence, remediation effort and an accountable owner.

A target architecture you can defend

Request a written target architecture with its rationale, alternatives and constraints: budget, skills, contracts, regulation and timing. Use diagrams to support the decision record.

Identify what you will retain as well as what you will change. Explain why each choice fits the agreed scope.

A sequence with a way back

Sequence changes by dependency and risk. For each move, define recovery steps and a decision point to stop, revise or continue.

Compare action with waiting. Record renewal dates, support deadlines and growing risks so you can make the timing decision with evidence.

A read-out for the people who decide

Give leadership a concise decision record: options, risks, estimated effort and the decisions required. Keep the detailed evidence available to your engineers.

Request an assessment you can use independently. Quote implementation separately and retain the choice of who carries out the work.

After the read-out

Turn ranked findings into a backlog with an owner and target date for each priority. Escalate unsupported production releases and untested recovery according to their assessed risk.

After the read-out, decide who will take each action forward. Discuss any implementation or ongoing support with us separately, including responsibilities, documentation and ownership terms.

Red flags

Check for evidence, ranked priorities, a justified target architecture and a migration sequence with recovery plans. Challenge generic recommendations, unexplained product preferences and scope that exceeds the agreed 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 $14,500 fixed-fee Assessment Sprint delivers a two-week topology and pipeline audit, target architecture, migration sequence and recovery plans. We agree scope before payment and scope implementation separately. Discuss any subsequent engineering or managed support through a separate agreement defining capacity, coverage and service targets.