Onboarding audit

An onboarding audit is the first step when a maintenance provider inherits an existing system. It answers: what is this system, what state is it in, what will break first, and what does supporting it actually require. The review covers the repository and its build process, infrastructure and access, dependency versions and known vulnerabilities, backups and recovery, monitoring, documentation, and for AI components the prompts, models, evaluation coverage and cost profile.

The output is a written report with a risk-ranked list of findings, immediate fixes such as expired certificates or unpatched critical vulnerabilities, and a proposed stabilisation plan. It also establishes the baseline against which an SLA can honestly be offered; a provider cannot commit to a four-hour resolution on a system with no tests, no monitoring and no deployment process without first fixing those.

It is not a full code review or a rewrite recommendation. It is a triage exercise scoped to what a support team needs to know, usually completed in one to two weeks. It is also distinct from a security penetration test, which it may recommend.

• CTO / Head of Engineering: gives an honest picture of a system inherited from a previous vendor or a departed team, before decisions about its future are made.
• CFO: separates the one-off stabilisation cost from the ongoing care-plan cost, so the budget is realistic.
• CISO: surfaces expired credentials, unpatched components and unmanaged access that accumulate when a system has been neglected.
• Operations head: identifies the single points of failure that would cause an outage nobody currently knows how to fix.

Onboarding audits exist because taking over an unknown system blind leads to broken promises. A provider that offers an SLA without knowing the system either overcharges to cover uncertainty or misses targets when the first hidden problem appears. The audit converts unknowns into a list, prices the stabilisation work honestly and lets both sides agree what support is realistic. The trade-off is a short delay and a modest cost before support begins. That is far cheaper than discovering during an outage that there are no backups, no deployment scripts and a dependency three major versions behind.

• A SaaS company whose original development agency has closed, needing a new partner to take over a production platform and its AI copilot.
• An NBFC inheriting a lending system from an in-house team that has left, with undocumented integrations to credit bureaus.
• A hospital group assessing a legacy patient-management application before deciding between modernisation and continued support.
• A retailer taking over a personalisation engine built by a freelancer, with no evaluation suite and unknown model costs.
• A university needing a documented picture of an ageing ERP before the next academic-year cycle.

Technique / practiceA structured assessment practice performed at takeover. Eazyware runs an onboarding audit before any Maintenance & Support engagement on a system we did not build, producing a risk-ranked report and stabilisation plan before care-plan targets are agreed.

Eazyware service that covers it: Software Maintenance & Support. Starting prices are on the pricing page.