Field Note
The first 90 days after a technology acquisition
The first 90 days after an acquisition come with a predictable urge to move everything. New reporting. Cost targets. Integration plans. Security work. Platform consolidation. A transformation roadmap somebody promised before they met the people doing the work.
Moving quickly matters. Moving every system quickly does not.
The first job is less exciting: find out what was really bought, stabilize what can hurt the business, and tie the sequence to the actual investment thesis.
Days 1–30: establish control
The first month should answer whether the company can operate safely while the larger decisions are made.
Confirm privileged access, backup and recovery, incident ownership, material vulnerabilities, expiring contracts and certificates, critical vendors, production support, data obligations, and key-person dependencies.
Also verify the architecture and cost baseline. Diligence works with limited time and incomplete access. The first weeks are when assumptions meet logs, invoices, repositories, deployment pipelines, and the people doing the work.
Where the evidence differs, update the plan. Do not defend the diligence deck against the system.
This is also the time to preserve institutional knowledge. If one person understands the order pipeline, billing process, or nightly reconciliation, document and distribute that knowledge before reorganizing the team around them.
Days 31–60: test the thesis
Take the most important technology-dependent assumptions in the value-creation plan and trace them through the actual system.
If growth depends on launching new products, test that path. If the plan assumes acquisitions can be integrated, define the data, identity, finance, and customer boundaries. If margin improvement depends on platform consolidation, validate licensing, migration, operational, and exit costs.
Use representative work, not workshops alone.
A small implementation or operational test can expose missing data, weak ownership, vendor dependency, or a timeline that looked reasonable at a portfolio level and does not survive contact with the systems.
That evidence is valuable even when it changes the plan.
Days 61–90: commit to a sequence
By the third month, leadership should have a practical technology agenda tied to business outcomes.
Separate the work into:
- immediate risk reduction
- capabilities required by the thesis
- operating-model improvements
- cost and platform rationalization
- decisions that need more evidence
Assign accountable owners, funding, dependencies, and exit criteria. Name what will not happen yet.
The result should not be a five-year target architecture pretending to be a plan. It should explain what changes over the next few quarters, why the sequence matters, and which assumptions would cause the plan to change.
Avoid the consolidation reflex
Acquisitions make duplication visible: multiple CRMs, commerce platforms, data tools, integration products, clouds, vendors, and processes.
Some duplication is waste. Some reflects different business models or lowers separation risk. Consolidation can reduce recurring cost and also consume the exact capacity needed for growth.
Do not migrate a stable system only because the parent company already owns another license.
Compare the full transition cost, operating benefit, business disruption, and time to value. Standardization should serve the thesis, not become the thesis.
Protect the people who know how it works
Technology integration creates uncertainty for the teams operating the acquired company. The people with the most system knowledge may also be the first to leave if the future is unclear.
Be direct about ownership, decision rights, and where capabilities will live. Involve operators in validating the plan. They know which workarounds are accidental and which ones keep the business running.
This is not a reason to preserve every current role or process. It is a reason not to destroy information before understanding it.
Make progress legible
At 90 days, the company does not need every answer. It should have control of material risk, validated assumptions, named owners, and a sequence the business can understand.
That is enough. Really.
The fastest way to lose a year is to start three platform migrations before learning whether the investment needed any of them.