Cloud and infrastructure architecture review
Decide what belongs in cloud, on owned infrastructure, and what should be retired.
You receive a map of the agreed systems, recommendations on what to keep, move or retire, a proposed design and a staged implementation plan. Cost assumptions support your budget. Private AI requirements are included only when agreed in scope.
- What you get
- A current-state dependency map, target architecture, placement decisions and a staged implementation plan with budget inputs.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- Decision owners review the proposed design, recovery requirements and unresolved evidence. Building or migrating the environment is separately scoped.
Illustrative sample · constructed example
Compare the same workload before choosing its home.
Illustrative workload · document-processing service
Decision input
Can this workload tolerate losing the external connection?
| Requirement | Design implication | Sample review |
|---|---|---|
| External link outage | Local processing and cloud synchronization need separate failure paths. | Requirement unknown |
| Peak demand | Size compute, storage and the queue against the same workload. | Measurement required |
| Recovery | Name the restore target, recovery owner and test. | Target to agree |
| Operating cost | Include support, connectivity, backup and the team running it. | Comparable costs needed |
Conceptual design. The local option remains conditional on capacity, recovery and support evidence.
Reference guidance: failure mode analysis- Evidence
- Peak demand, acceptable interruption and recovery target are missing.
- Decision
- Insufficient evidence to recommend
- Next action
- Measure demand and agree operating and recovery requirements before pricing equivalent options.
Illustrative comparison, not procurement advice. No cost total or savings estimate is invented.
Why now
The work starts here.
A support deadline, cloud bill, capacity problem, recovery concern or private-AI requirement has forced an infrastructure decision that should not be made from a vendor quote alone.
Scope at a glance
- Read-only architecture engagement
- Public cloud, private infrastructure or a hybrid estate
- Named technical and budget decision owners
If nobody acts
What waiting costs
A dependency found during a move changes the calendar and the budget after both have already been approved.
Cloud resources with no clear owner continue to bill because nobody can safely prove they are unused.
A private-cloud or GPU purchase fixes capacity, power and support choices that are expensive to reverse.
Availability and recovery targets that are not tied to business requirements can produce an architecture that cannot meet the deadline it was designed around.
Check your own environment
Sounds like you?
- Cloud spend is rising but nobody can tie every resource to an owner and workload
- Server or platform support deadlines are approaching without a replacement route
- A private-cloud or GPU platform is being quoted before power, storage and capacity are sized
- The backup dashboard is green but the recovery target has not been tested
Save yourself the call
Not for you if
- The target platform, workload list and dependencies are already verified and what you need is implementation
- The question is limited to one Microsoft 365 tenant, which the ownership review covers directly
- The only concern is whether a specific backup can restore, which needs a recovery validation
The work
What is different when we hand over
Cloud, server, storage, network and recovery components are mapped to the workloads that depend on them.
Requirements for availability, recovery, security, data location, capacity and support are agreed.
Each workload receives a keep, move or retire decision across public cloud, private infrastructure or a hybrid route.
The target design, implementation sequence, decision risks and budget inputs are documented for approval.
Acceptance
Checks before handover
Done when the decision owner accepts the verified current state, the route for every in-scope workload and an implementation sequence that can be priced.
The current environment and its critical dependencies are verified
Every in-scope workload has a keep, move or retire decision
The target architecture includes availability, recovery, ownership and operating requirements
The implementation sequence, decision risks and budget inputs are accepted by the decision owner
A fair question
Can a cloud or hardware vendor not design this for us?
A vendor is useful once the requirements and target route are agreed. This engagement defines the workloads, dependencies, operating constraints and decision criteria across cloud and owned infrastructure first. If the target platform is already known and the work is bounded, buy the implementation instead.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- Number of sites, workloads and cloud subscriptions
- Server, storage, network and backup platforms in scope
- Availability, recovery and data-location requirements
- Whether private-cloud or GPU capacity has to be sized
Delivery calendar
The proposal names the start date, the change windows and the completion date before anything is agreed.
How engagements workScope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- No production settings, workloads or data are changed during the review
- No hardware purchase, rack installation or vendor contract negotiation
- No migration, platform upgrade or restore fixes
- Implementation is scoped and approved separately from the architecture decision
What we need from you
- Provide read-only access and existing diagrams, bills and support records
- Nominate owners who can confirm workload and recovery requirements
- Make the final platform and budget decisions
Change and rollback method
- Discovery uses read-only platform evidence, configuration exports and owner interviews.
- Assumptions are separated from verified facts and assigned before they can drive the target design.
- No platform is selected until the business, technical and operating requirements are agreed.
What you keep at handover
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- Verified current-state architecture and dependency map
- Workload decision register: keep, move or retire
- Target architecture with availability, recovery and ownership requirements
- Implementation sequence, decision risks and budget inputs
- Private-AI capacity and hardware requirements where included
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Start the infrastructure reviewOr write to [email protected]