A takeover starts from an unusual position: the client is unhappy, often with reason, and is inclined to describe the incumbent's work as worse than it is. Believing that description uncritically is the first mistake, because it leads to promising a rewrite that is neither necessary nor affordable. The second mistake is the opposite — assuming the code is fine and the problem was purely relationship management. Both errors come from the same source, which is starting work before completing an inventory.
The inventory is unglamorous and non-negotiable. Every repository and who can grant access. Every environment and where it runs. Every cloud account and whose card is on it. Every domain, certificate and DNS zone, with registrar credentials. Every third-party service, its owner and its renewal date. Every credential currently in use. Every scheduled job. Every piece of infrastructure that exists but is not described in code. Working through that list produces surprises on almost every project, and it is far better to find them in week one than in week nine.
Access is where takeovers stall in practice. Credentials are frequently held personally by an individual at the outgoing vendor rather than by the client organisation, which means the client cannot grant what they believe they own. Establishing this early — and escalating it commercially while the outgoing relationship still has goodwill in it — is more valuable than any amount of code reading. Once a handover turns adversarial, credentials become leverage.
Before changing anything, get a build running from a clean checkout and get the system deployable by your own hands. Until you can do that, you do not have the project; you have a copy of some files. This step alone frequently uncovers undocumented steps, missing configuration and manual interventions that were living in someone's head, and it converts a vague sense of risk into a specific list.
Resist the rewrite for at least a month, however tempting. The client's frustration creates real pressure to demonstrate decisive action, and a rewrite feels decisive. But a codebase you have read for three weeks is one you do not yet understand, and the strange parts are as likely to encode a real requirement as to be a mistake. Stabilise first, deliver something visible and small, earn the right to make a large recommendation, and then make it with evidence.
Finally, write down what you found and share it plainly, including the parts that reflect well on the previous team. A client who receives an honest assessment rather than a sales document learns something about how you will behave later, when the awkward news is about your own work. That is the moment a rescue project becomes a long relationship rather than a short one.
