Independent design and change review
An independent read of a migration, policy change or platform decision before you commit: assumptions checked, failure paths worked, rollback tested.
What we review
- Stated objective: What the change is meant to achieve and how success will be recognized.
- Design assumptions: What the plan takes for granted about the environment, dependencies, capacity, licensing and behaviour under load.
- Dependency and blast radius analysis: What else is affected if this change behaves unexpectedly.
- Failure modes: Where the design is most likely to break, and whether those paths have been considered.
- Rollback and recovery: Whether a way back exists, whether it has been tested, and how long it remains available.
- Validation plan: How the team will know the change worked, beyond the absence of complaints.
- Operational handover: Whether the people who run the system afterwards can actually support it.
- Alternatives considered: Whether simpler or lower-risk options were evaluated and why they were set aside.
Deliverables
- Review findings: Observations organized by risk, separating confirmed issues from open questions and assumptions that need testing.
- Assumption register: What the design depends on being true, and which of those have been verified against the real environment.
- Failure mode analysis: The paths most likely to cause an incident, with the consequence and current mitigation for each.
- Rollback assessment: Whether the stated way back is credible, tested and available for long enough to be useful.
- Prioritized recommendations: What to resolve before proceeding, what to accept with eyes open, and what can follow later.
- Written opinion: A clear statement of whether the plan is ready to proceed as written, with the reasoning behind it.
Engagement boundaries
- The review is an independent opinion on the plan as presented. It does not transfer responsibility for the outcome.
- Findings are based on the documentation provided and whatever environment access is agreed. Undisclosed constraints cannot be assessed.
- A review does not guarantee a change will succeed. It identifies risk that was not visible to the team that built the plan.
- We do not execute the change being reviewed. Independence is the value being purchased, and executing would remove it.
- Verified findings are kept separate from assumptions and open questions. We do not present one as the other.
- If the plan is sound, the review says so. A review that manufactures findings to justify itself is worse than no review.
- Recommendations are prioritized by risk, not by what would be most interesting to implement.
- This work does not certify a design against any standard, framework or regulatory requirement.
Questions before the work starts
What if you find serious problems right before our change window?
You will hear about them immediately, not in a report a week later. Anything that would materially change the decision to proceed is raised as soon as it is identified, with the reasoning, so you can make the call with time to act.
Will you tell us the plan is fine if it is?
Yes. A review that invents findings to appear valuable is a bad review. If the design is sound and the rollback is real, the written opinion says so and explains what was checked to reach that conclusion.
Can you review a design you did not help build?
That is the intended case. Reviewing work we designed ourselves would not be independent. The review starts from your documentation and your environment.
Do you need access to our systems for this?
Documentation is the starting point. Read access to the relevant environment materially improves the review, because it lets assumptions be checked rather than taken at face value. Access is agreed in advance and scoped to the review.
How late can we bring you in?
Earlier is more useful, because more remains changeable. A review close to the change window can still catch a missing rollback path or an untested assumption, but there is less room to act on what it finds.
The platforms this work covers
A design can be reviewed on any of these platforms; the review reads your plan against how the platform actually behaves.
- Microsoft 365 and Entra ID
- Microsoft Azure
- Amazon Web Services
- Cloudflare
- Cisco
- Palo Alto Networks
- Fortinet FortiGate
- Check Point
- F5
- Data centre and virtualization
Other ways we can help
Engagements are often scoped together; these are the closest neighbours to this one.
Want an independent read before you commit to the change?
Share the design or change plan, the date it needs to proceed, and what a failed attempt would cost. The first conversation establishes whether an independent review will add anything useful in the time available.