In this guide 6 sections
Find out whether they audit before quoting. Then ask who holds the repository and server logins, how they cope with missing documents, and which response times they commit to. Finally, ask what you receive in writing once the first review of the code, servers and database is finished, and whether another vendor may read it.
Will you audit the code before you quote?
Quoting blind is guessing. Ask for a short audit first, paid or free, covering code reading, a test run, a dependency list and a check of the server.
Ask how long it takes. Ask who does it. A senior engineer reading your code is worth more than a salesperson reading your brief, so request a named person and a delivery date.
Then ask what happens if the audit says the code is not worth keeping; an honest team admits it and lists a rewrite or retirement. Listen for a plain answer.
- What does the audit cover?
- Who performs it?
- How long does it take?
- Is the quote based on its findings?
- What if the code is not worth keeping?
Who holds the keys, and in whose name?
Accounts matter as much as code. Ask who owns the cloud account, the domain registrar login and the app store developer account, and insist all stay in your company’s name.
Ask how access arrives. Shared passwords in a chat message are a poor sign, while individual accounts with a clear end date, reviewed each quarter, are far better. Track production, database and DNS access.
Ask about the last day. Exit terms should state, in writing, that credentials are handed over, their own access is removed and every key is rotated afterwards.
How do you work when nothing is documented?
Most inherited software has no manual, and the README stops at install, so ask how the team recovers knowledge before anyone touches a file. Good answers mention reading the database schema, tracing a request through the code, interviewing staff who use each screen and recording what they learn. Vague answers are a warning.
Request a redacted sample. Real notes from a past takeover list environment variables, cron jobs, payment gateway keys, webhooks and the odd behaviour nobody could explain.
Ask what stays frozen too. Careful teams leave risky areas such as payment code, refund logic and stock counts alone until they understand every path through each of them.
What response times and which person do you get?
Demand response and fix targets by severity, written into the contract, with separate clocks for a dead checkout page and a misaligned button. One costs orders. The other costs nothing. Which hours are covered? Do weekends count?
Insist on one named owner on their side plus a deputy, so a holiday or a resignation never leaves your request without a face. Check how they log requests. A ticket system that keeps every comment and status change beats a phone number, because you can prove later what was asked and when.
What if your request falls outside the contract? Some teams quote extra work within a day, while others leave you waiting for a call back that never comes, so ask to see their recent quote turnaround.
- Severity levels with target times
- Hours and days covered
- Named owner and deputy
- How requests are logged
- How extra work is quoted
What will you give me in writing after the first review?
The first review ends in a document you keep: ranked risks, an inventory of servers, domains and services, a module map and a ninety day plan.
Can you take that document to another vendor? Refusal exposes a lock, not a service.
Send these questions by email today. Compare the answers side by side in the sheet below, scoring each vendor from one to three, because silence on any single question is also an answer.
Takeover vendor question sheet
A single sheet with five blocks matching the sections above: audit, access and ownership, documentation, service levels, and written deliverables. Each block lists the questions in a left column, with blank columns for each vendor’s answer and a score from one to three. A total row sits at the foot.
Open a blank worksheet to printQuestions owners ask
Should I pay for the audit before choosing a vendor?
A small fee for a real audit is often worth it, because it produces a report you own and can compare across vendors. A free audit is fine if the scope names the code, servers, database and dependencies in writing, and promises you the report.
What access should a new team ask for first?
Ask first for read access to the repository, the production logs and the database schema, never for write access to production on day one. Write access follows once they understand the system, have agreed a change process with you and have shown a working rollback on a staging copy of the site.
What if the previous vendor refuses to cooperate?
Collect what you legally control first, meaning the domain, the hosting account, the payment gateway login and every contract copy you can find. A new team can often rebuild knowledge from the logs, database tables and scheduled jobs of the running system, though it takes noticeably longer.
Can a company take over software built in an unfamiliar language?
Ask for engineers who have shipped in that exact language and framework, plus a sample of past work you can inspect, not a slide deck. A plain no beats a confident maybe.