The Moment That Changes What You’re Using
A service you’ve used for years, built habits around, and possibly paid for receives an announcement: it’s been acquired by a larger company. The announcement press release says the expected things — the team is excited about the opportunity, the product you love will continue, this is great for users — and provides no reliable information about what will actually change. The history of tech acquisitions includes both examples where products genuinely continued and improved under new ownership and examples where the acquisition was primarily a talent or IP acquisition that resulted in the product being discontinued.
Evaluating the likely outcome of a tech acquisition that affects a product you use requires more than reading the press release. The history of how the acquiring company has treated previous acquisitions, the strategic logic of the acquisition, and the product’s role in the acquirer’s portfolio are better predictors of outcome than the announcement’s warm language.
The Patterns That Predict Good vs. Bad Outcomes
Acquisitions with better historical outcomes for users: strategic acquisitions where the acquired product fills a clear gap in the acquirer’s product portfolio (the acquiring company needs the product’s function and has incentive to maintain it), acquisitions by companies with a track record of maintaining acquired products (Salesforce acquiring Slack, Adobe acquiring Figma initially), and acquisitions that provide resources for a product that was financially struggling without the resources to continue its roadmap.
Acquisitions with worse historical outcomes for users: acqui-hires where the announced ‘product will continue’ language obscures that the real acquisition is the team (the product is wound down after the team is absorbed), acquisitions where the product directly competes with the acquirer’s existing products (the smaller competing product rarely survives long after the acquisition), and acquisitions by private equity buyers whose acquisition thesis is cost reduction and margin improvement rather than product development.
The Data Migration Window
The most practically important action after learning about any acquisition of a service you use with significant data in it: export your data now, before it becomes difficult or impossible. Many services that are discontinued or significantly changed provide an export window that closes at the service’s shutdown; the user who exports during this window recovers their data, and the one who procrastinates may find the window has closed.
The data export practice that’s good regardless of acquisition news: annual export of important data from any service you can’t easily replace the data from. Photos from a photo service, notes from a note-taking app, contacts from a contact management system, and financial data from a personal finance app are examples of data that’s difficult to recreate if the service closes without adequate export notice. The habit of annual exports prevents the data loss that unplanned service closures otherwise cause.
Price Increases and Feature Changes Post-Acquisition
Even when acquired products are maintained, pricing and feature availability often change in ways that reduce value for the existing user base. Acquired products integrated into the acquirer’s ecosystem frequently move features from the standalone product to the acquirer’s bundle (requiring purchase of the larger bundle rather than the standalone product), remove the freemium tier that drove adoption in favour of paid-only access, or increase prices to the acquirer’s standard pricing tier.
The pattern is common enough to treat as a near-default expectation rather than a surprise: Twitter/X’s API access pricing after the 2022 acquisition moved from a free tier that supported a rich third-party ecosystem to pricing that made most previous use cases economically nonviable. The acquisition changed the product fundamentally for the third-party developers and researchers who had built on the free tier.
Building a Portfolio That Reduces Acquisition Risk
The dependency risk management principle for software tools: where possible, prefer tools with data stored in open formats that can be accessed by multiple applications, tools with robust data export, and tools from organisations whose interests align with long-term product maintenance (companies whose primary product it is, rather than features within a larger portfolio).
The diversification that matters most: don’t have all important data in a single vendor’s ecosystem without a migration plan or export backup. The photos in iCloud, Google Photos, Amazon Photos, and an external drive are more resilient than all photos in a single service. The notes in Obsidian (stored as plain text Markdown files on your own drive) are more migration-resilient than notes in a cloud-only proprietary format. These choices don’t prevent disruption from acquisitions, but they reduce the impact when disruption occurs.
