Continuity of service when a vendor is acquired or sunsets a product

Reference article · 5 min read

Most contract language about vendor risk assumes the vendor fails: bankruptcy, breach, abandonment. The more common disruption is quieter. The company is acquired, or it stays healthy and retires the product you bought. Service continues, the people you know leave, the roadmap changes, and eventually a letter announces an end-of-life date and a migration path to a different product with a different name.

None of that is misconduct, and termination for cause rarely applies. What protects an agency is a set of ordinary commercial clauses negotiated before signature, plus a disciplined response when the notice arrives. The goal is not to prevent the vendor from being acquired. It is to keep a working system, keep your data, and keep your budget assumptions intact long enough to run a real procurement.

What actually changes when the company changes

An acquisition does not by itself change your contract. The surviving entity generally assumes the obligations. The practical changes come later, and they are the ones that hurt:

Support. Tiers get consolidated, named contacts disappear, and response times drift even when the service level agreement is unchanged on paper.
Hosting and subprocessors. The acquirer may move the workload to its own cloud accounts, regions, or subcontractors.
Product direction. Your product becomes a legacy line while investment goes to the acquirer's overlapping product.
Commercial terms at renewal. New license metrics, bundled modules you do not need, and a price built for the acquirer's catalog rather than your original deal.

Assignment and change of control

Read the assignment clause before you need it. A clause barring assignment "without consent" often carves out mergers and sales of substantially all assets, which means the event you care about is the one exempted. Ask for language that defines change of control explicitly and treats it as an assignment event.

Useful protections include written notice within a stated period after closing, a right to terminate for convenience without penalty during a defined window after that notice, and a refund of prepaid unused fees if you exercise it. Require that the successor be bound to every term, including security obligations, accessibility commitments, audit and inspection rights, records access, and any state-specific provisions your jurisdiction requires. Some public entities also need formal consent or novation before a successor can perform or invoice. Requirements vary by state and by entity type, so confirm the process with your counsel and your central procurement office rather than assuming the vendor's paperwork is sufficient.

End-of-life notice and support for the version you run

Sunset protection lives in a separate clause from assignment, and it is often missing entirely.

Notice period. Set a minimum notice before end of support, long enough to budget, procure, and migrate. The right length depends on how deeply the system is embedded, not on what the vendor prefers.
Defined stages. Distinguish end of sale, end of new development, maintenance and security-only support, and end of support. Require dates for each in writing.
The deployed version. Commit the vendor to supporting the version actually in production, including security fixes, not only the current release.
No forced upgrade cost. If the vendor drops support for your version, the upgrade that restores support should not carry a new license or professional services charge.
Data on the way out. Require export in a documented, non-proprietary format, on demand, during the term and for a defined tail afterward, with schema documentation. For hosted products, a transition services obligation is worth more than traditional source code escrow.

Price protection through the term

Continuity is financial as well as technical. Cap renewal increases with a stated percentage or a published index, and apply the cap across the full term including option years. State that if the vendor moves you to a successor product, the price for equivalent functionality is held at the existing level for the remainder of the term and the same cap applies afterward. Bar re-pricing based on a changed license metric. Finally, allocate migration cost: when the vendor initiates the retirement, data conversion and reimplementation should be at vendor cost or a pre-agreed fixed rate, not a fresh statement of work.

When the notice arrives

Read the contract before you read the announcement. Identify your notice rights, termination rights, and current term end.
Get the real dates in writing: end of sale, end of feature work, end of support, end of hosting.
Inventory the deployment. Integrations, interfaces, reports, custom fields, workflows, and retention obligations are the migration, not the core application.
Take a full export now and test restoring it somewhere you control.
Notify the budget office, counsel, the records officer, partners under data sharing agreements, and the grantor if grant funds are tied to the system.
Acknowledge receipt without agreeing to anything. Signing the acquirer's new master agreement usually replaces your negotiated terms. Treat any request to move to new paper as a new contract requiring full review.

Evaluating the replacement product

The acquirer's product is a candidate, not a conclusion. Compare it against staying put as long as support allows, and against competing products.

Build the parity list from how staff actually use the system, including reports and edge-case workflows, not from a feature grid.
Re-verify accessibility conformance, security documentation, hosting location, and subprocessors. Prior commitments do not transfer to a different codebase.
Confirm it can hold your retention schedule, satisfy public records requests, and support legal holds.
Price the integration work with your other systems separately from the license.
Run a pilot on a real copy of your data before committing.
Check your procurement rules. A vendor being acquired does not by itself establish a sole source justification, and a competitive process may be required.

HQT works with state and local agencies on system modernization and migration planning, including assessing replacement products and moving data off retiring platforms.

Frequently asked questions

Can we terminate a software contract if the vendor is acquired?

Only if the contract gives you that right. Many agreements permit assignment to a successor in a merger without your consent and say nothing about termination, so the acquisition alone changes nothing. The time to secure a termination right tied to change of control, with a refund of prepaid unused fees, is before signature or at renewal.

How much end-of-life notice should a government software contract require?

Enough time to budget, run a procurement, and migrate, which for an embedded system of record is considerably longer than for a peripheral tool. Rather than accepting the vendor's standard notice, work backward from your own budget cycle and procurement timelines. Also require the vendor to state separate dates for end of sale, end of new development, security-only support, and end of support.

Do we have to migrate to the acquirer's replacement product?

No. Unless your contract says otherwise, the acquirer's migration path is an offer, and your obligations run to the product and terms you actually signed for. Evaluate the replacement against competing products and against staying on the current version for as long as support lasts, and check whether your procurement rules require a competitive process.

Who pays for migration when a vendor retires the product we bought?

That depends entirely on what the contract says, and most contracts are silent, which in practice means the agency pays. Negotiate the allocation up front: when the vendor initiates a retirement, data conversion and reimplementation should be at vendor cost or at a rate fixed in the original agreement. At minimum, secure a documented data export obligation so you are not paying for access to your own records.

Does a vendor acquisition or product sunset justify a sole source award?

Not on its own. The fact that your incumbent was purchased does not establish that only one vendor can meet the requirement, and sole source justifications are generally scrutinized on that question. Confirm the standard with your procurement office and counsel, since thresholds and documentation requirements differ by state and entity.