The diligence report is the first draft of your 100-day plan

The technical report usually lands in the third or fourth week of exclusivity. The deal team reads the summary, counsel takes the findings that touch price and terms, and the rest of the document goes into the data room archive. A few weeks later the deal closes, and the new owner learns on day one that the founder still holds the only admin login to the cloud console, that nobody can say when a backup was last restored, and that two former contractors can still push code to production.

None of that should be news. In most reviews it is already written down, with evidence and a cost range. What is missing is the step between the report and the first week of ownership: someone has to sort the findings by when they must be done, not only by how serious they are.

This article is about that step. It treats the findings register and the fix plan as the first draft of the 100-day plan, and shows how a buyer can turn them into dated work before closing, so that day one starts with a list instead of a discovery.

One register, several time windows

A good report already contains most of what a 100-day plan needs. Every finding carries a layer, a severity, the evidence, the business impact and a cost and time to fix with assumptions. The fix plan groups them into the first 100 days and the first year. The buyer's job before closing is to read that plan a second time, now as the person who will own the system, and to add two things the review cannot decide: dates and owners.

Our severity scale gives the first cut. Critical findings can stop the deal or should be resolved before closing. High findings are likely to affect price or terms and need a plan in the first 90 days. Medium findings raise the cost of ownership and belong in the first-year plan. Low findings are hygiene. But severity is not the whole schedule. Some items with a modest rating have to come first because everything else depends on them. You cannot run a restore test in an account you do not control, and you cannot rotate keys until you know where they are.

So the useful view is a set of windows, each with its own content and its own proof of completion:

The windows are a planning frame, not a promise. A company with one product and a small team may move through the first two in days. A business carved out of a larger group may spend months untangling shared accounts. The register tells you which case you are in.

Before closing: names, accounts and keys

The period between signing and closing is the last time the seller is fully motivated to fix things. After closing, every fix is the buyer's cost and the buyer's time. The findings that belong here are the ones about control: whether the company, and not a person, owns what it sells and runs on.

• The domain registrar, DNS and the business email admin, registered to the company.
• The root or owner account of each cloud provider, and the card that pays for it.
• The organization that owns the code repositories, with the company as owner.
• App store developer accounts, the payment processor, analytics and the main software subscriptions.
• Access removed for former employees and contractors, followed by rotation of any shared password or key they could have seen.
• Signed IP assignments from people who wrote code without one. Our note on ownership gaps in software acquisitions covers how these surface and why they matter.
• Vendor licenses with change-of-control or assignment terms, listed for counsel with the facts attached.

How these items are tied into the deal is a question for counsel. The usual routes are conditions before closing and covenants about how the seller runs the technology until closing, such as no major releases or new vendor contracts without consent. Two limits deserve a word with your lawyer early. Until closing, the companies remain separate, and a buyer who starts running the target's systems can create a gun-jumping problem. And in many smaller deals signing and closing happen on the same day, so this whole window moves before signing.

The buyer can still prepare. Write the day-one access list now: which named accounts the new owner needs, in which systems, who creates them, and which shared credentials get rotated at the moment of handover. A list prepared in calm weeks is better than one written at the closing dinner.

Days 1 to 30: control and recovery

The first month has one aim: the new owner can see the system, control who changes it, and bring it back if it fails. Nothing visible to customers needs to change. This is also the window in which a new owner often finds that the findings were accurate and still incomplete, because read-only access during a review never shows everything.

Security and access

Start with the admin list from the review and confirm it against the live systems. Every admin account should belong to a named person, use multi-factor sign-in and have a reason to exist. Shared logins get replaced by named ones. Keys and passwords found in the code history get rotated, not just deleted from the latest version. Offboarding becomes a written routine instead of a favor someone remembers.

Backups and a restore test

A backup that has never been restored is an assumption. Run a full restore into a separate environment, time it, and check the restored data against production counts. The result gives you two numbers the business needs and rarely has: how long recovery takes and how much data could be lost. If the review rated an untested backup as High, this is where that finding usually closes.

Monitoring and who can deploy

Alerts should reach a person who answers, not a mailbox nobody reads. Test it: trigger an alert and see who gets it. Then write down who can release to production and how. In founder-run companies the answer is often one person with every permission. A short list of named deployers, a release freeze around closing and a record of every release are enough for month one. A full pipeline redesign, if the review called for one, belongs to a later window.

The 100-day plan and the first year

High findings are the core of the 100-day plan. They are the findings likely to have affected price or terms, so the deal team already knows them. The work now is to turn each one into a package someone can run: an owner, a budget range from the report, a start date, dependencies and a written definition of done.

Check the assumptions first. Every cost range in a report rests on stated assumptions: who does the work, from what starting point, what must hold for the low end. With full access, the team can test those assumptions in the first weeks. A framework upgrade estimated on the basis that the tests can be trusted moves a lot if the tests turn out to be thin. Re-estimating is not a failure of the review; the review shows you exactly which assumption moved.

Not every High finding will be closed in 100 days, and the scale does not ask for that. It asks for a plan in the first 90 days. A key-person dependency, for example, may take most of a year to reduce, but the plan, the second engineer and the first recorded runbooks belong in this window.

Medium findings go into the first-year plan, by quarter, so they reach the budget instead of a wish list. Low findings stay in the register and get fixed when the team works in that area. Turning a list of Low items into a project usually spends senior time where it changes little. The report's strengths deserve a place in the plan too: the parts of the system that work well are the ones to leave alone while everything else moves.

Findings that wait on integration choices

Some findings only make sense once the buyer knows what happens to the system. If the product will stay separate, an outdated framework needs an upgrade plan. If it will be connected to the buyer's platform through a few interfaces, the upgrade may still be needed, along with an integration layer. If it will be migrated into the buyer's own product within a year or two, a large upgrade may be wasted money.

A technical review should not make that decision. It is made by the people who own the investment case, usually after closing and with more access than a review ever has. What the report can do is mark each such finding as depending on integration and say what each option would add or remove. That keeps the options open without guessing at a plan nobody has agreed.

One rule holds across all three paths. Control, recovery and security work happens regardless. "We will migrate it anyway" is not a reason to leave an exposed admin panel or an untested backup in place, because migrations often take longer than planned and the old system stays the owner's responsibility for as long as it runs. Our engineering partner PERETZ describes the integrator's order of work after closing in How to Integrate Two Companies' IT Systems After an Acquisition: the Order, and What Goes Wrong. The diligence report is what that work should start from, and the integration decision belongs in the 100-day window, made with the facts the first month produced.

Keeping the seller's people engaged

A findings register describes a system. The knowledge needed to fix it often sits in two or three people, and the team layer of the report names them: the engineer who answers every hard question, the founder who approves every release, the contractor who built the billing integration. Deals change these people's jobs at exactly the moment their memory matters most.

Retention arrangements, consulting agreements with a departing founder and transition services are matters for counsel and the deal team, and are usually settled before the announcement. The technical side can make them work in practice:

• Give each key person a clear answer about the future of the system they look after. Uncertainty about their own work tends to weigh more than a retention payment.
• Bring them into the fix plan. They know why things were built the way they were, and some findings will have reasons the review could not see.
• Pair a second engineer with each of them on real tasks, starting in the first month.
• Record the deploy, the restore and the month-end jobs while the people who run them are still there.
• Run a handover test: a new engineer sets up and deploys the system from the documents alone, and every question they have to ask becomes a page to write.

Tone matters too. Findings are about the system, not about the people who kept it running with limited time and budget. A team that feels judged by the report will defend the past instead of helping with the plan.

Done means evidence, not a status update

A common way for a 100-day plan to fail is quietly. Every item turns green in a weekly update, and a year later the next buyer's reviewer finds the same untested backup and the same founder login. A status is a statement. A fix is done when there is an artifact that shows it, ideally one a person outside the team can check.

Write the definition of done for each finding before the work starts, in the same terms as the finding itself. If the finding was "backups have never been restored", done is a restore log with the date, the time taken and a data check, not "backups reviewed". If the finding was "former contractors retain access", done is an export of the access list with removal dates, not "access cleaned up". Evidence of this kind is cheap to collect while the work is happening and expensive to rebuild later.

Two habits help. Have someone who did not do the work check the evidence for High findings. And re-run the checks that matter most, admin access and the restore, at the end of the 100 days, because systems drift back. The same evidence later becomes the core of the technical section of a data room when the company is sold again.

What to hold before the money moves

Before closing, a buyer should be able to point to each of these:

• Every Critical finding resolved, or tied to a deal term counsel has agreed.
• A day-one access list: named admin accounts, who creates them, which credentials get rotated.
• Written owners for the restore test, MFA, offboarding, alerting and deploy rights in the first 30 days.
• Each High finding with an owner, a budget range, a start date and a definition of done.
• Medium findings placed in the first-year budget by quarter.
• Findings that depend on integration marked as such, with the decision dated inside the first 100 days.
• The key people named, with a plan for pairing, recording and the handover test.
• The review's limits listed, so the first month checks what the review could not see.

None of this makes the transition light work. It makes it work you can see coming. If you are inside exclusivity, our technical due diligence delivers a findings register and a fix plan for the first 100 days and the first year, written to be lifted into exactly this kind of plan; earlier in a deal, a red-flag memo finds what could stop it. The review never includes the fixes. If you want hands for them after closing, PERETZ can do the work under a separate contract, and any capable team can do the same.

Questions