A two-week audit is the most common way we start with a new client, and it is also the deliverable most often done badly across the industry. Done badly, it produces a forty-slide deck of observations everyone already knew, a colour-coded risk matrix, and a recommendation to "invest in modernization." Nobody acts on it, because it gives no one a decision they can defend. Done well, an audit ends with four concrete things a leadership team can pick up and use the same week.
1. An architecture map that reflects reality
Not the diagram from the wiki that stopped being true in 2021 — the actual one. What services exist, what talks to what, where the data lives, which integrations are load-bearing, and where the undocumented glue is. The value of this map is not that it is pretty; it is that it is honest. It shows the parts of the system that everyone works around but no one owns, the single database that eleven services quietly depend on, the nightly job that would take the business down if it failed. You cannot plan a modernization against a fiction, and most teams are planning against one without realising it.
2. A risk register ordered by business impact
Every audit finds risks. A useful audit ranks them by what they cost the business, not by how technically offensive they are. A deprecated library is a finding; a deprecated library in the payment path with no test coverage and one person who understands it is a business risk with a name and a deadline. The register should let a non-technical executive read down the list and understand, in plain terms, what could go wrong, how likely it is, what it would cost, and what it takes to defuse it. That translation — from technical debt to business exposure — is most of what leadership is actually buying.
3. A sequenced roadmap, not a wish list
A list of everything that should be improved is not a plan; it is an anxiety generator. A roadmap sequences the work so that each phase reduces risk or unlocks value, ends in something inspectable, and does not require the previous phase to have been perfect. It answers the only question leadership really has: if we can fund three months, what three months buy us the most safety and the most optionality? A good roadmap is also honest about dependencies — the work that genuinely cannot start until something else is done — because hidden dependencies are how a "six-month" plan becomes an eighteen-month one.
4. A working proof, not just a promise
This is the artefact most audits skip, and it is the one that changes the conversation. In two weeks it is almost always possible to build one small, real thing: extract a single capability behind a façade, stand up a thin slice of the target architecture, or instrument the system so the cost or performance problem becomes measurable instead of anecdotal. A working proof does two things a document cannot. It de-risks the approach — you have now done the hard part once, for real — and it gives leadership evidence rather than assertion. "We think this will work" and "here is it working" ask for very different amounts of courage from the person signing the cheque.
How clients turn this into budget
The pattern we see repeatedly is that the audit does not sell the modernization — it lets the client's own champion sell it internally. A CTO who walks into a budget meeting with an honest architecture map, a risk register their CFO can read, a roadmap costed in fundable phases, and a working proof of the first phase is not asking for faith. They are presenting a decision with the uncertainty already removed. That is the real product of a two-week audit: not a report, but a defensible decision that someone inside the company can stand behind.
What to demand from any audit
If you are commissioning an assessment — from us or anyone — insist on these outcomes before it starts. Ask that the architecture map be validated against the running system, not the documentation. Ask that risks be expressed in money and time, not severity colours. Ask that the roadmap be broken into phases you could actually fund one at a time. And ask for something that runs at the end, however small. An audit that cannot commit to those four things is selling you a document, and a document is the one thing a struggling system does not need more of.