When the source code never left one contractor's laptop

The situation

Before they came to us, Rivka and Kostas had already spent three weeks trying to solve this themselves. Their first move was to email the contractor directly asking him to hand over the account credentials as a professional courtesy, on the theory that a polite request from the new owners would settle it. It did not. Their second move was to have their internal IT lead attempt a password reset on the cloud hosting account, which triggered a lockout because the recovery email on file belonged to the contractor personally, not to the company. Their third move was to ask the outgoing founder to intervene, only to learn the founder had signed off on the arrangement years earlier and no longer had the authority to unwind it. By the time they called our office, they had also tried threatening a breach of contract letter drafted by a general business lawyer, which produced no response at all, since Sophia had no contract with the buying group and no obligation to answer to it.

Rivka, a surgeon who had put a meaningful share of her savings into the deal, and Kostas, who ran a logistics company and treated this acquisition as his next venture, had assembled a small management team to buy a Thornhill software business valued in the range of fifty to eighty million dollars. The target built scheduling and dispatch software for mid-market service companies, and its code, its cloud accounts, and its production infrastructure were the entire asset. Everything else on the balance sheet, the office lease, the small amount of physical equipment, a handful of accounts receivable, was secondary to a business whose real value lived entirely inside servers and repositories neither Rivka nor Kostas had ever personally logged into.

The company's sole technical contractor, Sophia, had built and maintained the platform for nearly a decade as an independent contractor rather than an employee. Over that time she had registered the production cloud accounts, the source code repository, and several third-party service accounts under her own personal logins, with the company's knowledge but without anyone formalizing a transfer of control. It was, in effect, informal infrastructure ownership that nobody had ever converted into something the company actually held, an arrangement that had worked fine for a decade precisely because nobody had ever needed to test who was actually in charge of it.

The deal had closed. The purchase price had been paid. Sophia had given notice that she was leaving, on schedule and without apparent malice, but with the practical result that the buying group now owned a company whose core technical assets they could not access without her active cooperation, at exactly the moment that cooperation had the shortest possible shelf life.

The legal problem

On paper, the diligence process had asked the right question. The checklist Rivka and Kostas's advisors used before closing included a line item for intellectual property ownership and a line item for IT systems and infrastructure. Both had been marked as reviewed. The trouble was that the diligence responses relied on representations from the target's own management, and those representations described the code and cloud accounts as company property without anyone verifying who actually held the administrative logins that would let a new owner exercise that ownership in practice.

Once we were retained, we asked for the underlying materials rather than the summary. The target's own internal records, including old onboarding emails and a shared spreadsheet the departing founder had kept, told a different story than the version Rivka and Kostas had been given during negotiations. Those records showed that senior people on the seller's side had known for years that infrastructure access ran through Sophia personally, and had discussed internally, more than once, that it should be fixed. It never was. That contradiction mattered, because it meant the buying group's account of having been blindsided did not entirely hold up against the seller's own paper trail, which weakened the strongest version of any claim that the sellers had actively concealed the problem. A seller who wrote down that a risk existed and then failed to fix it looks careless, not fraudulent, and the difference between those two things drives very different remedies.

The legal exposure ran in two directions at once. Against the sellers, there was a plausible but imperfect claim that the representations and warranties in the purchase agreement about the target's ownership of its own intellectual property and systems had not been accurate. Against Sophia, there was no wrongdoing at all in a legal sense. She had built the systems the way she had been asked to, had not concealed the arrangement, and was under no obligation to keep working for the new owners past her notice period. The buying group's leverage to compel her cooperation was limited to whatever goodwill and negotiated payment could secure, and no court order was going to arrive quickly enough to matter.

Underneath both of those problems sat a harder one: even with a strong warranty claim, Rivka and Kostas needed the platform running now, not after a dispute resolved. A software company that cannot access its own production environment has a very short runway before customers notice, invoices go unpaid, and the value of the very asset they were trying to protect through litigation quietly erodes while the litigation is still being drafted.

What we did

1. Triaged the technical exposure before the legal exposure. The first call was not about claims, it was about whether the production systems could fail while Sophia was still reachable. We treated the days remaining in her notice period as the only reliable window to secure cooperation, and organized everything else around that clock rather than around the more comfortable, slower pace of a typical warranty investigation.
2. Reviewed the seller's own internal records rather than relying on their prior representations. Pulling the onboarding emails and the shared spreadsheet gave us a factual baseline independent of what either side was now saying, and it surfaced the contradiction between the sellers' account and their own documented awareness of the risk, which became the central fact underlying every later negotiation.
3. Negotiated a paid transition agreement with Sophia directly. Rather than treating her as an adversary or relying on a courtesy that had already failed once, we structured a short paid engagement, several weeks at her normal contracting rate, in exchange for a documented, supervised transfer of every account, credential, and code repository to company-controlled infrastructure. Framing it as a professional handover, not a concession under pressure, gave her a reason to cooperate quickly.
4. Built a formal handover checklist and verified each item independently. We did not accept a verbal confirmation that access had moved, since that was exactly the assumption that had failed the buying group before. Our technical advisor confirmed administrative control of each cloud account, the code repository, and the domain registrar before releasing the final transition payment, which caught two service accounts Sophia had initially forgotten to include in the handover.
5. Sent a formal notice to the sellers describing the discrepancy between their representations and their own records. This step preserved the buying group's legal position without committing to litigation it might not need, and it gave the sellers a clear, documented opportunity to respond before any claim was filed, which mattered because the relationship with the departing founder still had ongoing value to the business.
6. Negotiated a partial holdback release adjustment with the sellers. Rather than pursue a drawn-out warranty claim through the courts on a record that was only partially in the buying group's favour, we used the existing escrow mechanism already built into the purchase agreement to recover a portion of the transition cost directly from the funds still held back, avoiding the delay and expense a formal claim would have added.
7. Documented a post-closing IT governance policy for the target going forward. To prevent the same failure from recurring with any future contractor, we had the company adopt a written policy requiring all infrastructure accounts to be registered under company-controlled logins from the outset, reviewed at fixed intervals, rather than left to the kind of informal practice that had built up unchecked over a decade.
8. Advised the management team on how to describe the episode to their own investors. Because several of the buying group's backers had asked pointed questions once the access problem surfaced, we helped Rivka and Kostas prepare a clear, factual account of what had happened, why it had happened, and what had been fixed, so the story reached investors accurately rather than circulating informally and losing accuracy along the way.

The outcome

Access to the code, the cloud accounts, and the production infrastructure was fully restored within the transition window, and the platform stayed running for the company's customers throughout, with no visible service interruption to the business the buying group had actually paid for. That was the outcome that mattered most, and it was achieved without a lawsuit against either the sellers or Sophia.

It was not free. The buying group paid Sophia's transition fee, absorbed several weeks of internal disruption while the technical team learned systems that had never been properly documented, and recovered only a partial contribution toward those costs from the escrow holdback, rather than the full amount they initially believed they were owed. The contradiction in the sellers' own records was useful leverage in that negotiation, but it was not strong enough, on its own, to support a larger claim once the sellers pointed to the buying group's signed acceptance of the diligence materials at closing. Pursuing the full amount through litigation remained an option we discussed, but the cost and time of proving concealment against a seller who could point to acknowledged, if imperfect, disclosure made that path unattractive compared with a faster negotiated recovery.

Rivka and Kostas kept the company and the deal held together, but they also carried the loss forward as a documented cost of a diligence process that had checked a box without verifying what sat behind it. In the months after closing, they used the episode to change how their group approached every subsequent acquisition, treating technical infrastructure ownership as something to be independently confirmed rather than taken from a seller's word, and building the cost of that verification into every future diligence budget rather than treating it as optional. The company itself came through intact, its customers largely unaware anything had happened, which is its own kind of success in a deal where the worst-case version of this story ends with a platform going dark.

What you can learn from this