What arrives with an inherited site
A supplier change often happens at an awkward moment: the previous developer has stopped responding, an update broke a form, or the business urgently needs a feature. The executive wants to transfer access and receive a response guarantee. An administration panel, however, exposes only part of the system. Behind it may sit a separate server, database, background jobs, payment provider, CRM, domain, and accounts owned by people who have left the project.
In current commercial search results, the pre-support audit has become a distinct promise. Amplify Lab describes checking code, infrastructure, and access before contract, while Brusnica Development includes code, security, monitoring, and backups in its inherited-project audit. These are the companies’ service descriptions, not independent proof of quality. Their overlap marks a real boundary: a team cannot own a system it cannot yet reproduce and restore.
A fast handover therefore does not mean immediate intervention in production. The new team first obtains an observable picture, protects recovery, and only then changes the system. This order may feel slower on day one, but it avoids turning an unknown fault into a larger outage.
Inventory starts with the business, not the repository
Record the critical paths first: browse a catalogue, submit a lead, place and pay for an order, sign in, receive an email, or deliver data to CRM. Each path needs an acceptable interruption, business owner, and temporary manual route. This distinguishes an inconvenient defect from an incident that stops revenue or a customer obligation.
Then map the technical parts: repositories and branches, build process, environments, servers, domains and DNS, certificates, databases, file stores, queues, external interfaces, email, analytics, monitoring, and backups. Record the account owner, renewal method, and person who can grant or remove access.
Dependencies attached to a former employee’s personal account or card are particularly dangerous. A service may work today and stop after a payment expires or password resets. The handover should move critical resources under controlled company accounts without distributing passwords through email and group chats.
Read first, then verify a copy and reproducible build
Where possible, the new team’s first access should be read-only. Engineers inspect change history, configuration, and logs without adding new variables. At the same time, they record the production state: code version, settings, dependencies, database structure, and active integrations.
“Backups enabled” proves little without restoration. Select a copy, restore it in isolation, and test more than table presence: sign-in, files, a critical journey, and operation time. A copy that depends on the same server or account as production offers weak protection against losing that boundary.
The team then builds the project from documented sources in a test environment and ships one small reversible change. This answers the practical question: can the current version be reproduced and the previous one restored if the release fails? Until that is known, a promise of regular improvements is an assumption.
The audit must end with a decision backlog
A useful report is not a count of findings. It connects an observation to a consequence: “the certificate renews manually and expires on this date”, “the form accepts a lead but loses it when CRM is down”, or “a backup exists but excludes uploaded files”. An executive sees priority and an engineer gets a verifiable task.
An audit may show that gradual replacement is more economical. “Rewrite everything” cannot follow merely from an unfamiliar stack or unattractive code. Compare stabilisation cost, replacement cost, transition risk, and the behaviours the new version must preserve.
- Critical risks that can already stop the site, lose data, or expose excessive access.
- Conditions for safe operation: monitoring, restored backups, managed secrets, and an emergency channel.
- Defects affecting leads, payment, search, or staff work, with reproducible steps.
- Obsolete dependencies and architectural constraints that obstruct change but do not justify an overnight rewrite.
- Known unknowns: missing permissions, documentation, service owners, and areas that cannot be verified.
- A first-thirty-days plan with owner, verification method, and rollback path for each change.
An SLA starts by defining an incident
Public support offers use different models. Adict connects packages with platforms, monitoring, backups, and response time, while Intervolga names a minimum retained volume and a separate audit. Price alone does not reveal coverage. Compare support hours, severity rules, first response, recovery objective, reserved capacity, and work treated as product development.
Response time is not repair time. A team may acknowledge an incident and begin diagnosis within fifteen minutes, while restoration depends on cause and the available fallback. For each critical journey, define a temporary route in advance: switch to a reserve, disable a faulty integration, accept leads manually, or restore the previous release.
pommeDeTerre’s current support pricing starts at RUB 30,000 per month; standard support starts at RUB 60,000, and extended SLA with retained capacity at RUB 120,000. Those levels can be discussed after the audit because unknown condition changes both the initial workload and realistic recovery time. Handover is complete not when passwords arrive, but when both sides agree the system map, verify a backup and release, assign owners, and share the same understanding of what happens at the next incident.