A first 100-day technology plan protects the business, then prepares the first value creation work.
The first 100 days after a private equity acquisition are the buyer’s window for setting direction, and technology has a short, specific job in that window. Secure access to every critical account. Stabilize the systems the business runs on. Build an inventory and a ranked risk list. Deliver the reporting the fund needs first. Then pick and scope the first value creation project in writing.
The order reflects risk. Access and stability protect what the fund just bought, and they are hard to repair after an incident. The inventory turns diligence findings into a working list the operating team can act on. Reporting gives the board a trusted baseline. Only then is the company ready to commit people and budget to a larger change.
The plan belongs to the portfolio company’s leadership, usually the CEO or CFO with whoever leads IT, with the operating partner reviewing progress. The window is a planning framework, not a deadline for major system changes. Large migrations and rebuilds started in the first 100 days, before the business is understood, are a frequent source of trouble later in the hold.
Secure access and stabilize the systems the business runs on.
Start by confirming who holds administrative access to the domain, email, hosting, code repositories, accounting system, payroll, banking portals, and payment processor. Sellers, departing founders, former employees, and outside contractors often still hold it. Put at least two named company administrators on each critical account, enforce multifactor authentication, and remove access that no longer has a business reason.
Move shared passwords into a company password manager, rotate those that departing people knew, and confirm backups by running a test restore. Then identify the systems that produce revenue and close the books, confirm who supports each one and under what agreement, and pause discretionary changes to them until the inventory is complete, except fixes for security issues and outright failures.
Watch for dependencies that can lapse during a transition. Software licenses, domain registrations, and support contracts may be tied to the seller’s broader organization or to a person who has left. Where the business relies on one developer, contractor, or spreadsheet author, start a documented handover while that person is still engaged. These steps protect the asset while leadership and staff are changing.
Turn diligence findings into an inventory and a ranked risk list.
Diligence produced a view of the company’s technology under deal pressure and with limited access. After close, build the working version: every application, what it is responsible for, how data moves between systems, where spreadsheets fill gaps, who supports each piece, and what each contract says about renewal and termination. Interviews with the people who do the work fill in what documents miss.
From the inventory, write a risk list ranked by business impact. Typical entries include unsupported software, single-person dependencies, untested recovery, weak access control, and data that cannot be reconciled between systems. For each, record the consequence in plain terms, the recommended response, a rough sense of effort, and the person accountable. Keep it short enough that the leadership team reads it.
Separate the risk list from the opportunity list. Ideas for new systems and improvements will surface during the inventory, and they deserve a place, but mixing them with risks makes both harder to manage. Opportunities feed the value creation plan. Risks feed a remediation plan that the board can track to closure over the hold period.
Deliver the reporting the fund needs first, even if it is partly manual.
The fund needs a trusted baseline early: financial results in its format, the operating measures in the investment thesis, and covenant reporting if the deal carries debt. Agree on the definitions for each measure with the finance team and the operating partner before building anything, and document where each number comes from in the company’s systems.
In the first 100 days, a reliable reporting package matters more than an automated one. The first packages can involve some manual assembly, as long as the steps are written down and the numbers reconcile to the general ledger. Automating a process that is not yet understood tends to lock in its errors along with its steps.
Use the early packages to find the gaps: measures the systems cannot produce, data that does not tie between operating and accounting systems, and steps that depend on one person. Those gaps are strong candidates for the first value creation project, since consolidated, automated reporting is a prerequisite for measuring much of what follows in the plan.
Pick the first value creation project and scope it in writing.
By the end of the window, leadership should choose one first project tied to a lever in the value creation plan, such as pricing, margin, integration of an add-on, or reporting. Favor a project with a clear measure, a sponsor inside the company who is accountable for the outcome, and a process the team understands well enough to describe.
Scope it in writing before committing budget. The scope should state the problem, the users, the workflows included and excluded, the systems it touches, the data it needs, and how success will be measured. A written scope lets the board judge the project, gives vendors a basis for comparable proposals, and gives the team a fixed reference when priorities shift.
Baybloom Software helps portfolio company leaders assess systems and scope a first project of this kind. Whoever does the work, a 100-day technology plan succeeds when the business is secure and stable, the risks are listed and ranked, the fund trusts the numbers, and the first real change is defined clearly enough to start well.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project