Vendor acquired: what should a startup do in the next 90 days?

When a larger company acquires one of your vendors, the product may not change immediately. The impact can arrive within weeks or take years. VMware ended perpetual licence sales less than three weeks after Broadcom completed its acquisition, while Heroku announced the end of its free plans more than 11 years after Salesforce acquired it. Startups should not panic-migrate or assume nothing will change. Instead, review the contract, rank dependencies by the cost of losing them, build alternatives for the riskiest services, and make a migration decision within 90 days.

Key takeaways

• Changes can happen quickly or years later. Broadcom completed its VMware acquisition on 22 November 2023 and ended perpetual licence sales within three weeks. Salesforce acquired Heroku on 3 January 2011 and announced the end of its free plans more than 11 years later.
• Migration deadlines vary. Customers received seven days to respond to the X API changes, 92 days for Neptune, 95 days for Heroku's free plans, and approximately one year for Parse. A 90-day review gives startups a practical window to assess their options, although vendors may provide much less notice.
• Vendor contracts often favour the provider. Of the five self-service agreements reviewed for this article, four allowed the vendor to terminate the contract with 30 days' notice or less, and four permitted assignment to a buyer without customer consent.
• An anti-assignment clause may not protect you during an acquisition. A Delaware court ruled in 2013 that a reverse triangular merger generally does not constitute an assignment. Startups that want an exit option following a change of control need to consider an express change-of-control clause.
• Assess the cost of replacing each dependency. Classify each service as an inconvenience, a potential outage, or a rewrite if it becomes unavailable. For example, Auth0 password hashes require a support ticket to export and are unavailable on its Free tier. Stripe transfers card data only to a PCI DSS Level 1 processor, upon request.
• Forced migrations have a real financial cost. Two engineers working for six weeks at the US median developer wage of $65.38 per hour would cost approximately $31,400 in wages alone. That is roughly 1% of a $3 million seed round, excluding the features and improvements the team cannot deliver while working on the migration.

In this article

• What happens to a product after its maker is acquired?
• What does your contract already give you?
• How do you tell an inconvenience from an outage or a rewrite?
• How do you design a seam so a switch is a project, not a rewrite?
• What will a forced migration cost, and how long will it take?
• What do investors and enterprise customers expect to see?
• What is the 90-day plan?
• When is a migration sprint worth buying outside engineers for?
• Conclusion: build a business that can survive the next acquisition
• Frequently asked questions

What happens to a product after its maker is acquired?

There is no reliable way to predict when an acquisition will affect a product. Across six documented cases, the first change customers experienced arrived anywhere from less than three weeks to more than 11 years after the deal. One acquisition even brought customers a benefit. Startups should therefore prepare for change rather than assume an acquisition will be either good or bad.

The fast changes

Broadcom completed its acquisition of VMware on 22 November 2023, according to its Form 8-K. On 11 December, VMware's cloud division announced the immediate end of perpetual licence sales and additional support contracts for those licences, as reported by The Register. Customers could continue using perpetual licences they already owned, but SiliconANGLE reported that existing customers would no longer be able to obtain support and software updates under those arrangements.

The financial consequences became a legal dispute. AT&T sued Broadcom on 29 August 2024 in New York State Supreme Court, alleging breach of contract. According to Legal Dive, AT&T argued that it faced a tenfold increase in annual VMware costs for features it did not want. Broadcom responded that AT&T had failed to exercise renewal terms on its perpetual licences before 9 September 2023. By 14 October 2024, the two companies were moving towards settlement discussions, according to CIO Dive.

The impact extended beyond individual customers. CISPE, a European cloud industry trade group, reported "price increases of 800 to 1500 percent" for its members following Broadcom's changes. iX Magazin reported the claim in May 2025 without receiving a comment from Broadcom. These figures should be treated as the trade group's own figures, not independently audited results.

The slow changes

Facebook agreed to acquire Parse on 25 April 2013. At the time, the messaging was reassuring. A Parse co-founder said the service was not going away, while Facebook's Doug Purdy said the company did not intend to change it, according to TechCrunch.

However, on 28 January 2016, Facebook announced that Parse would be retired at the end of January 2017. The announcement came 1,008 days after the acquisition announcement. Facebook suggested a two-step schedule: data on a self-hosted MongoDB database by 28 April 2016 and a new app on the open-source Parse Server by 28 July. The shutdown and migration options were covered by InfoQ and InfoWorld.

Heroku provides an even longer example. Salesforce completed its acquisition on 3 January 2011, according to Salesforce's announcement. More than 11 years later, on 25 August 2022, Heroku announced that its free product plans would end on 28 November. The company cited "an extraordinary amount of effort to manage fraud and abuse." The announcement appeared on the Heroku blog and was covered by TechCrunch.

These examples demonstrate why startups cannot assume that a product is safe simply because it continues operating for years after an acquisition. A service can remain available for a long time before its pricing, support, or availability changes.

The good change

Not every acquisition damages the customer experience. Microsoft completed its acquisition of GitHub on 26 October 2018 and said GitHub would "operate independently, and remain an open platform."

On 7 January 2019, just 73 days later, GitHub made unlimited private repositories free. It called this the first time developers could use GitHub for their private projects with up to three collaborators per repository for free. Both the GitHub blog and Fortune covered the announcement.

The lesson is not that acquisitions always lead to worse products. It is that their outcomes are uncertain, which makes it unwise to build a business continuity plan around an assumption that the buyer will preserve the existing service.

The sudden changes

Some vendors give customers very little warning. X completed its acquisition on 27 October 2022, according to its Form 8-K.

On 2 February 2023, the @TwitterDev account announced that free access to the Twitter API would end on 9 February. Developers therefore had only seven days to respond. The change was reported by The Register and TheWrap.

Neptune offered a longer transition but introduced restrictions immediately. On 3 December 2025, the company announced that it had entered into a definitive acquisition agreement with OpenAI. It said its hosted application would be switched off after a three-month transition, with remaining data irreversibly deleted. Neptune's transition hub and InfoWorld covered the announcement.

Neptune also closed new sign-ups and stopped automatic renewals on the first day of the transition. That matters because a vendor can begin limiting your options before the final shutdown date. A service that technically remains online may already be unsuitable for new projects or continued expansion.

A press release is not a term of your contract.

What does the research say about acquired products?

Research suggests that product discontinuation is common among major technology acquirers, although it does not happen in every case and is not necessarily evidence of deliberate harm to customers.

Gautier and Lamesch studied 175 companies acquired by Alphabet, Amazon, Apple, Meta, and Microsoft between 2015 and 2017. They found that, in the majority of cases, the acquired product was discontinued under its original brand, particularly when the acquired company was young. A later paper with Maitry, covering acquisitions between 2015 and 2021, also reported that most acquired products were discontinued.

These studies focus on Big Tech acquisitions rather than the full range of developer-tool buyers. Their findings are therefore useful as a general indication of risk, not as a precise prediction of what will happen when a particular vendor is acquired.

It is also important to distinguish between discontinuing a product and buying a company specifically to eliminate a competing product. Cunningham, Ederer and Ma estimated that 5.3% to 7.4% of acquisitions in their pharmaceutical sample were killer acquisitions, in which a company acquired a project to discontinue it. That finding concerns pharmaceuticals and should not be treated as a direct estimate for software acquisitions.

Employees are another part of the picture. An analysis of US Census data covering startup acquisitions between 1990 and 2011 found that acquisitions push many acquired employees to leave and launch their own ventures, a pattern driven disproportionately by founders and other top earners. When experienced employees depart, customer support and product development can weaken even if the company never announces a shutdown.

Our article on what a vendor lock-in exit plan should include explores the Deno case. On 9 October 2026, Deno announced that its hosted platform would continue operating for another six months before shutting down.

There is no comprehensive dataset showing exactly how long a startup-sized vendor will survive inside a developer-tools acquirer. The documented cases and available research nevertheless support a clear conclusion: product changes and discontinuations are common, their timing is difficult to predict, and reassuring statements made during an acquisition do not guarantee that the service will remain unchanged.

For startups, the practical response is to understand the contract, identify dependencies that would be expensive to replace, and prepare an exit before one becomes urgent.

What does your contract already give you?

Less than you might expect. A review of five common vendors' published self-service terms, conducted on 25 October 2026, found that four allowed the vendor to terminate the agreement with 30 days' notice or less, while four allowed it to transfer the agreement to a buyer without customer consent.

These come from the published agreements of AWS, Stripe, Anthropic, Vercel, and Supabase. They are self-service terms, not necessarily the terms that govern every customer. If you signed a separate order form or negotiated agreement, start there because it may provide different protections.

Two provisions stand out. First, AWS commits to providing at least 12 months' notice before discontinuing a material functionality of a generally available service that you use. That is the longest contractual notice period for product discontinuation identified in this comparison. Second, Supabase's fixed-term agreement cuts both ways: neither party has a termination-for-convenience right during the term. Supabase can still change the agreement, other than orders, at its discretion on reasonable notice, so check what your own order fixes.

Why an anti-assignment clause will not save you

An anti-assignment clause may not protect your startup when a vendor is acquired because the transaction can be structured so that the contract technically remains with the same company.

In a reverse triangular merger, the buyer creates a subsidiary that merges into the target company. The target survives as the contracting entity, but its ownership changes. The Delaware Court of Chancery considered this issue in Meso Scale Diagnostics v. Roche Diagnostics, filed on 22 February 2013. The court held that a reverse triangular merger is generally not an assignment by operation of law or otherwise.

However, a federal court in California reached a different conclusion in a case involving Oracle. The outcome can therefore depend on the governing law and the contract's wording. As Koley Jessen explains, a contract intended to cover mergers and changes of control should address those events explicitly.

The UN secretariat's notes on cloud contracts call it common to require advance notice of an upcoming change of control and its expected impact on the contract.

If you have a negotiated agreement, look for a clause that specifically addresses a change of control, not just an assignment. If you rely on standard click-through terms, you may not have this protection.

Which levers do you hold, and which can you buy?

Start with the rights you already have, then identify the additional protections worth negotiating.

Three protections you may already have

• The right to leave. Most of the agreements reviewed allow customers to close their accounts or terminate their subscriptions under the applicable terms. The practical challenge is often not obtaining permission to leave, but moving your data, code, and workloads before access ends.
• The vendor's existing notice obligations. Your contract may already require the vendor to provide notice before certain changes. AWS, for example, commits to at least 12 months' notice before discontinuing material functionality in a generally available service that you use. Read the exact wording to understand which changes qualify and what exceptions apply.
• Statutory switching rights for eligible EU customers. The EU Data Act has applied since 12 September 2025 and establishes rules intended to make switching between data-processing services easier. These include a maximum two-month notice period for initiating a switch, a standard transition period of up to 30 calendar days, and at least 30 days of continued data retrieval after the transition period. Switching charges are scheduled to be prohibited from 12 January 2027, subject to the applicable rules and exceptions.

The requirements are explained by Germany's Federal Network Agency, Penningtons Manches Cooper, and the European Commission.

UK regulators are also addressing cloud market competition. The Competition and Markets Authority published its cloud services market investigation decision on 31 July 2025 and recommended prioritising strategic market status investigations, including considering the two largest providers.

Four protections worth negotiating

If your vendor is important to your business, ask for the following protections in writing before an acquisition closes:

• A change-of-control exit window. Negotiate the right to terminate without penalty for a defined period, such as 90 days, after a change of control. This gives you time to evaluate the new owner and move if necessary.
• Advance notice of acquisitions and material changes. Request written notice of an acquisition and any planned changes to the product, pricing, or support arrangements. US bank regulators already advise financial institutions to seek notice of significant strategic or operational changes, including mergers and acquisitions, in their vendor relationships. See the 2023 Interagency Guidance on Third-Party Relationships.
• Price protection. Negotiate a price hold for the remainder of the current contract term and a cap on increases at renewal. This reduces the risk of an acquisition being followed by a sudden price increase that makes the service unaffordable.
• Data portability and source-code escrow. Require the vendor to return your data in a standard, usable format. For critical software that your business cannot operate without, consider source-code escrow, which allows access to deposited source code if specified events occur. The interagency guidance identifies insolvency of a third-party provider as one example of a situation where escrow may be relevant.

Why negotiate before the deal closes?

The period between announcing an acquisition and completing it can provide an opportunity to secure protections, although the opportunity depends on the circumstances.

In US transactions requiring antitrust review, buyers generally cannot take control of the target's ordinary business operations before the applicable waiting period expires. WilmerHale's analysis of the Federal Trade Commission's January 2025 enforcement action explains that merging parties must not interfere with the target's ordinary-course conduct during the waiting period, and King & Spalding reads it the same way.

Historical transactions illustrate how much time this period can provide. The interval between announcement and completion was 26 days for Heroku, 144 days for GitHub, 309 days for HashiCorp, and 545 days for VMware.

Not every acquisition requires regulatory review, and a longer transaction does not automatically give customers a right to renegotiate. Nevertheless, when an acquisition is announced, there may be an opportunity to ask for protections before the transaction closes. A vendor may also change its own terms before a sale, subject to the existing contract and applicable law.

Why you should review renewal clauses now

The AT&T dispute with Broadcom illustrates how much can depend on the precise wording of a contract. The disagreement concerned whether and when AT&T had exercised renewal options on its perpetual VMware licences. According to CIO Dive, the dispute involved roughly 75,000 virtual machines, and a 30-day support extension helped keep them covered while negotiations continued.

Broadcom argued that AT&T had received fair warning of the changes, according to Legal Dive. The disagreement demonstrates why businesses should understand their renewal deadlines, notice requirements, and the exact steps required to exercise a contractual option.

Do not rush into a multi-year renewal simply to avoid an immediate disruption. A longer commitment can protect pricing and availability, but it can also lock your startup into a service that becomes unsuitable or too expensive. Consider the commitment alongside your runway and other spending priorities, as discussed in our article on what to cut from engineering costs when runway is short.

This is general information, not legal advice. Have a lawyer review your actual agreement, particularly its termination, renewal, assignment, change-of-control, pricing, and data-export provisions.

How do you tell an inconvenience from an outage or a rewrite?

For every vendor your startup relies on, ask two questions: what would you need to change if the service disappeared, and what could you fail to recover before access ended? An inconvenience means switching configurations or replacing a service is relatively straightforward. An outage means you cannot move essential data or credentials in time. A rewrite means your application depends so heavily on the vendor's specific features, data structures, or software development kit (SDK) that replacing it requires substantial code changes.

The distinction matters because migration costs often hide in the second category. Auth0's documentation explains that password hashes cannot be retrieved through its API. They must be requested through a support ticket, the export is unavailable on the Free tier, and Auth0 cannot guarantee how long the process will take.

Stripe also imposes conditions on data transfers. It can export payment card data to a replacement processor, but that processor must hold PCI DSS Level 1 status, which Stripe verifies. The export does not include payment history or subscriptions, so those records must be reconstructed through the API.

Neither vendor is necessarily trying to prevent customers from leaving. The problem is that their export processes have requirements and lead times. If you discover those requirements on day 80 of a 90-day transition window, you may not have enough time to complete the move. What looked like a manageable migration can become an outage.

Why dependency mapping matters for migration costs

Migration budgets often fail because businesses underestimate how many other systems depend on the service being replaced.

A study of the cloud migrations of ten international banks found that the industry underestimates what they cost. Managing dependencies between applications was the first of five underestimated categories, ahead of legislation, support from other departments, re-architecting, and hiring contractors.

Banks operate under different conditions from seed-stage startups, and ten organisations represent a limited sample. However, the underlying lesson applies to both: you cannot estimate the cost of replacing a service accurately until you understand what depends on it.

For example, replacing an authentication provider may involve more than changing a login screen. You might also need to migrate user credentials, update permissions, change session handling, test account recovery, and modify other services that rely on the existing authentication system.

The more dependencies you discover during the migration itself, the more likely you are to exceed your budget and delay other work.

How to build the dependency register in a day

Start by identifying your vendors using three sources rather than relying on what you and your team remember.

Check company card transactions and invoices to find paid services. Review your single sign-on system or password manager to identify the accounts your team uses. Then inspect your repositories, package manifests, and environment variables to uncover the services and software libraries your applications depend on.

For each vendor, record five things:

• Purpose: What does the service do for your business?
• Failure impact: What would break if the service disappeared tomorrow?
• Data location: What information does it hold, and where is that information stored?
• Export and recovery: Have you exported the data and successfully loaded it into another system?
• Contract deadline: When does the agreement expire, renew, or allow termination?

The fourth item is particularly important. Knowing that a vendor offers an export feature is not the same as knowing that your team can recover its data and use it elsewhere. An export that has never been tested is an assumption, not a working exit plan.

Our guide to technical due diligence before a Series A covers the open-source side of this inventory.

Two additional dependencies deserve a place on the register because they can change or renew without a traditional vendor acquisition.

AI models have their own retirement schedules. Model providers regularly replace or discontinue models, potentially forcing changes to your application even when your contract remains in place. Anthropic's model deprecations page says it notifies customers with active deployments at least 60 days before retiring a publicly released model. If your application depends on a particular model, include its retirement date and the work required to replace it in your planning.

Third-party software can depend on a single company's continued involvement. A package or service maintained by one company creates a dependency on that company's ability and willingness to keep supporting it. This resembles the bus factor problem in small engineering teams: if one critical person becomes unavailable, the work may become difficult to maintain. Our guide to the bus factor in small teams explains the same risk from the people side.

The objective is not to eliminate every dependency. It is to know which ones you can replace easily, which ones could interrupt your business, and which ones would require significant engineering work. Once you have that information, you can prioritise your exit plans according to the actual cost of losing each service.

How do you design a seam so a switch is a project, not a rewrite?

Put a small module between your application and the vendor, using your own terminology rather than the vendor's. Only that module should need to know which vendor you use. If you switch providers, you can build a new adapter for the replacement instead of changing every feature that depends on the original service.

Software architects call this approach ports and adapters, or hexagonal architecture. When the module translates between your application and an external system with a different data model or terminology, it can also act as an anti-corruption layer.

Ports, adapters and the anti-corruption layer

Alistair Cockburn's 2005 write-up of hexagonal architecture states the intent as letting an application be developed and tested in isolation from its eventual run-time devices and databases. If you replace a database, the way the rest of your application communicates with it should remain unchanged.

Microsoft's Azure Architecture Center describes an anti-corruption layer as a facade or adapter that translates between systems with different meanings and structures. This prevents an external system's design from dictating how your own application must work.

The approach has a cost. The same page warns that the layer adds latency to calls and is an extra service you must manage and maintain. That is the trade-off: you accept a small, ongoing engineering cost to make a future migration more manageable.

Research supports the need to consider these trade-offs carefully. A survey of 114 UK IT professionals found that vendor lock-in is exacerbated as computing resources move from on-premise to the cloud. The authors proposed lock-in strategies relating to contracts and to vendors that support standardised formats, protocols and APIs.

However, reducing lock-in is not always worth every additional engineering expense. Gregor Hohpe makes the general point in Don't get locked up into avoiding lock-in: "Minimizing switching costs may not be the most economical choice," and "Complexity can be the biggest price you pay for reducing lock-in."

The objective is not to eliminate every dependency. It is to make expensive, disruptive dependencies easier to replace without building unnecessary complexity into your application.

Without a seam, you optimise for speed in the current quarter but may make a future migration expensive. With a seam, you pay a small engineering cost upfront to make the eventual switch more predictable.

Where an open standard already provides the seam

You do not always need to design your own interface. Industry standards can provide a common way for your application to communicate with different vendors. Four areas are particularly useful, although each has limitations.

Telemetry. OpenTelemetry is a Cloud Native Computing Foundation project that describes itself as open source and "vendor- and tool-agnostic," usable with a broad variety of observability backends, and says "There's no vendor lock-in."

Its adoption is substantial. In the 30 days to 22 October 2026, the @opentelemetry/api npm package had 345,718,982 downloads, and the Python opentelemetry-api package had 443,719,489 downloads in the last month on PyPI Stats.

Using OpenTelemetry allows you to change observability providers without redesigning how your application generates telemetry. You still need to verify that the replacement supports the signals, exporters, and features you actually use.

Identity. OpenID Connect (OIDC) is a standard identity layer built on OAuth 2.0. The OpenID Connect Core 1.0 specification defines how applications can authenticate users through compatible identity providers.

If you use OIDC and maintain your own internal user IDs, changing identity providers can become a configuration and data-migration exercise rather than a complete rewrite. Passwords remain a significant complication because password hashes may not be exportable or transferable between providers. Auth0's export requirements, discussed earlier, illustrate this limitation.

Object storage. Cloudflare's R2 service implements the S3 API to make it easier for applications built around that interface to migrate. However, Cloudflare also documents differences in supported operations and features.

Google's Cloud Storage XML API is interoperable with "some tools and libraries" that work with Amazon S3. The important word is some. An API standard does not guarantee that every feature behaves identically across providers. Test the actual operations your application uses before relying on compatibility.

Feature flags and AI models.OpenFeature is a CNCF incubating project that provides a vendor-neutral API for feature flagging. It can help you change feature-flag providers without rewriting the application logic that evaluates flags.

AI model integrations need similar care. Anthropic offers an OpenAI SDK compatibility layer, but its documentation says the layer is primarily intended for testing and comparing model capabilities. It also documents differences, including the strict parameter for function calling being ignored.

A compatibility endpoint is therefore useful as an additional adapter for testing, but it is not a substitute for your own stable interface.

Gateway libraries can reduce the effort of connecting to multiple AI providers, but they introduce another dependency that you must assess. LiteLLM had 92,239,101 PyPI downloads in the last month. However, SafeDep reported that its 1.107.0 release, uploaded on 21 October 2026, contained a credential stealer and remote-code-execution backdoor and was removed from PyPI by 13:23 UTC that day.

The lesson is not to avoid gateway libraries. It is to pin versions, review upgrades, and treat the libraries that provide your portability as dependencies in their own right.

What a seam cannot do

A common interface cannot guarantee that the company maintaining it will continue supporting the software. It also cannot guarantee that a healthy community will emerge around an alternative when a product changes direction.

MinIO illustrates the first problem. Although its object-storage software supported the S3 API, its community edition lost management features in May 2025, stopped publishing binaries in October 2025, entered maintenance mode on 3 December 2025, and was archived on 25 April 2026. The MinIO repository now states that it is no longer maintained. It's FOSS also reported the change in the project's open-source strategy.

The maintenance-mode announcement generated considerable discussion on Hacker News, and Wikipedia pageviews for MinIO rose from 126 on 1 December to 456 on 4 December 2025.

The minio tag also had 977 Stack Overflow questions at the time of the cited source. That figure indicates an existing body of user knowledge, but it does not tell us how many users were directly affected.

For startups, the practical lesson is to prefer standards with at least two independent implementations. A shared API gives you a route out, but you still need a viable alternative that you can operate and support.

An alternative can exist without having a mature community. HashiCorp changed Terraform's licence to the Business Source License on 10 August 2023, according to its announcement. The Linux Foundation announced OpenTofu on 20 September 2023, 41 days later, creating an open-source alternative.

At the time of the cited sources, OpenTofu had 30,614 GitHub stars compared with Terraform's 50,165. OpenTofu's migration guide states that it aims to maintain compatibility with Terraform configurations.

However, the Stack Overflow tag for OpenTofu had only 31 questions, compared with 20,188 for Terraform.

These figures illustrate the difference in accumulated community knowledge, although they are only rough indicators of ecosystem maturity. A technically compatible alternative may still have fewer tutorials, fewer experienced users, and less accumulated troubleshooting knowledge.

The acquisition timeline is also instructive. IBM signed an agreement to acquire HashiCorp on 24 April 2024, according to HashiCorp's first Form 8-K, and completed the acquisition on 27 February 2025, according to its second Form 8-K. IBM's completion announcement says IBM is "committed to continuing to invest in and grow the HashiCorp capabilities" without mentioning licence terms.

The licence change came first; IBM agreed to buy HashiCorp 258 days later. That is an important distinction: a vendor can change its product or business strategy before a sale is announced. Your exit plan should account for vendor decisions generally, not just acquisition announcements.

Which seams should you build first?

Prioritise dependencies according to the cost of getting the decision wrong. Start with systems where a replacement would otherwise require a substantial rewrite or where losing access could interrupt the business.

• Identity first. User records, permissions, and authentication connect to almost every part of an application. Maintain your own internal user IDs and use standard identity protocols where possible.
• Payments second. Payments affect revenue, and moving card data involves strict security requirements and additional migration steps. Understand the export process and preserve the records you will need to reconstruct subscriptions and payment history.
• The primary data store third. Know how to export your data, understand the differences between database providers, and test whether the replacement can support your application's queries and data structures.
• Standardise telemetry and feature flags where practical. These are often relatively straightforward areas in which to use established interfaces, reducing future switching costs without building elaborate custom systems.

For applications that cannot be migrated all at once, Martin Fowler's strangler fig pattern provides a practical approach. You build replacement functionality alongside the existing system, move features across incrementally, and retire the old implementation once the new one is proven.

This approach reduces the need for a risky, all-at-once migration. The goal is to make switching a planned engineering project with a defined scope, rather than an emergency rewrite that competes with the product roadmap.

What will a forced migration cost, and how long will it take?

Estimate the work in engineer-weeks first, then calculate the cost based on your team's pay rates. Add a buffer for dependencies you have not yet identified. The financial cost becomes clearer once you know how many engineers will be involved and how long the migration is likely to take.

The shutdown of Parse provides a useful timeline benchmark. The vendor-suggested plan, per InfoQ, split a year into a first milestone at 91 days (data on a self-hosted database) and a second at 182 days (a new app on Parse Server). Your migration will have different requirements, but this example helps show how much time a forced move can take.

A simple cost estimate is:

Number of engineers times weeks times 40 hours times the hourly wage.

O*NET OnLine, using US Bureau of Labor Statistics data, lists the 2025 median software developer wage as $65.38 per hour, or $135,980 per year. These figures cover wages only. Employer costs, tools and the features your team cannot build while working on the migration will add to the total. There is no public benchmark that reliably measures these additional costs for startups.

These estimates are calculated using the O*NET wage figure. The seed-round comparison uses Crunchbase News's estimate of a median US seed round of around $3 million in 2025.

There are two important cautions. First, the wages are only part of the cost. Crunchbase's analysis also reports that the time from a seed round of $1 million or more to a Series A is now "more than two years," and only 16% of the 2024 seed cohort had progressed further. Every engineer-week spent on an unexpected migration is time taken away from building the product, serving customers and extending your runway.

Second, these estimates assume your dependency map is accurate. Research involving ten banks highlights why organisations should allow extra time for dependencies they have not identified. A startup should treat the figures as planning estimates, not guaranteed budgets or deadlines.

Plan the migration so you can stop safely if something goes wrong.

Run the old and new systems side by side for a period, then move a small amount of traffic or one customer segment first. This gives you a chance to find problems before the entire product depends on the replacement. After switching over, keep the old vendor available in read-only mode for at least 30 days, where the service and contract allow it.

Check the vendor's data-retention and retrieval terms before you begin. For example, AWS retains your content for 30 days after termination but lets you retrieve it only if you have paid all amounts due. Settle the final invoice before you need to recover your data, rather than discovering a payment restriction during the migration.

What do investors and enterprise customers expect to see?

Investors and enterprise customers want evidence that your startup can manage its reliance on external vendors. Create a short, honest vendor register that identifies your most critical dependencies and explains how you would replace each one if necessary. Prepare it before anyone asks for it.

A guide to technical due diligence for venture capital investors explains that reviewers may ask whether a startup can replace its most important vendors. It also warns that external SaaS products become a risk when nobody has identified or accounted for the cost of vendor lock-in. Your vendor register provides a concise answer to these questions. RocketDevs' guide to what investors check before a Series A explains how this fits into the broader technical review.

Enterprise customers, particularly banks and other regulated organisations, approach the issue from a different direction. They need to know that they can change providers without facing unreasonable restrictions, excessive costs or disruption to critical services.

The 2023 US Interagency Guidance on third-party relationships says contracts should allow banks to change providers when appropriate without undue restrictions, limitations or cost. It also lists, among termination considerations, options for an effective transition of services and the time frame to move the activity to another third party or bring it in-house.

In the European Union, the Digital Operational Resilience Act (DORA) requires financial entities to maintain exit strategies for ICT services that support critical or important functions. Under Article 28, those plans must be comprehensive, documented, appropriately tested and regularly reviewed.

These requirements can reach your startup through an enterprise customer's vendor-risk questionnaire. If you can explain your exit plan clearly and demonstrate that you have tested it, you will be better prepared to answer the customer's questions.

The strongest evidence is a migration test, not a promise. If you have exported your data and successfully loaded it into another system, you can demonstrate that you have a workable exit route. If you have never tested the export, you do not yet know whether it will work when you need it.

What is the 90-day plan?

Follow six steps in order: read before you react, ask in writing, classify your dependencies, build a seam where needed, prove the fallback, and make a decision. The 90-day window is a practical planning target, informed by the notice periods in the acquisition cases discussed above. It gives you time to assess the risk and prepare alternatives before making a major commitment.

The timeframes are planning targets, not guarantees. The amount of work will depend on the complexity of your product and its dependencies.

The notice periods in previous cases help explain the urgency. Neptune customers received 92 days' notice, Heroku's free-plan users received 95 days, and the vendor terms reviewed above commonly included 30-day notice periods. Waiting until a deadline is announced may leave too little time to respond safely.

Step 1: read before you react (days 0 to 3)

Read the acquisition announcement and the vendor's FAQ carefully. Separate firm commitments, such as a statement that a product will continue operating, from intentions, such as a plan to continue supporting it. Those statements do not offer the same level of certainty.

Then review your contract against the key questions discussed earlier: termination rights, assignment, change of control, pricing, notice and data return. At this stage, nothing about the product may have changed, so avoid moving code before you understand the actual risk.

Step 2: ask in writing (days 3 to 10)

Email your account contact with specific questions. Ask for a roadmap commitment, a price hold through the remainder of your contract, at least 90 days' written notice before any end-of-life decision, and confirmation of how you can export your data. Request a named contact who can address future concerns.

Pay attention to the quality of the response. Clear, specific answers give you something to plan around. Vague replies or a refusal to confirm important details in writing are also useful signals when assessing risk.

Step 3: classify every dependency (days 10 to 30)

Use your vendor register and the three dependency classes: inconvenience, outage or rewrite. Record the likely impact of losing each service and what it would take to replace it.

For every vendor whose loss could cause an outage, perform a real export and load the data into a test environment. This gives you a practical estimate of how long recovery would take, rather than relying on the vendor's description of its export tools.

Step 4: build the seam where it is a rewrite (days 30 to 50)

Build an abstraction layer only where losing the dependency would otherwise require a substantial rewrite. Define the interface using your own terminology, implement an adapter for the current vendor, and keep your own identifiers as the primary keys wherever possible.

Then draft a second adapter for the alternative you would choose if you had to leave. You do not necessarily need to complete a production-ready replacement immediately. The goal is to reduce how much of your application would need to change if you switched providers.

Step 5: prove the fallback (days 50 to 75)

Test the alternative with a small amount of real traffic or one willing customer. Compare cost, latency and behaviour with the existing service. Check that the data transfers correctly and that important features still work.

The objective is not to switch immediately. It is to establish that switching is a realistic option. A tested fallback lets you plan the work in advance. An untested fallback leaves the cost and timeline uncertain until a deadline forces your hand.

Step 6: decide whether to stay, hedge or leave (days 75 to 90)

Choose your response based on the evidence you have gathered.

• Stay: The vendor has provided credible answers, the product remains healthy and the commercial terms are acceptable. Finalise any negotiated renewal protections.
• Hedge: The answers are vague or some risks remain unresolved. Keep the abstraction layer and second adapter ready, and document the warning signs that would trigger a switch.
• Leave: The evidence points to an unacceptable risk. Schedule the migration using the notice period and contractual rights you actually have.

Record the decision and the reasons behind it. That gives the team a consistent policy to follow if the situation changes later.

Which tripwires should you write down?

A tripwire is a specific, observable event that triggers a predefined response. Set these signals before a vendor's situation deteriorates, so your team does not have to decide what to do in the middle of a crisis.

The acquisition and shutdown cases above offer several examples. Neptune closed new sign-ups and stopped automatic renewals on the first day of the transition. MinIO's README changed to "maintenance mode" 143 days before its repository was archived. These are the kinds of public signals that can provide warning before a service disappears.

Parse illustrates a different outcome. Its open-source server appeared on the same day as the shutdown notice, created on 28 January 2016. A decade later, the project had accumulated 21,402 GitHub stars, 196,170 npm downloads of Parse Server in the last month and 19,532 Stack Overflow questions tagged parse-platform. The Parse client SDK still sees 534,199 npm downloads a month. These figures illustrate how an open-source community can help sustain a product after its original vendor exits, although downloads and questions alone do not prove that a replacement is suitable for your application.

The shutdown-day Hacker News discussion, titled "Parse is shutting down today," attracted 435 points on 30 January 2017. Together, these examples show why it is worth monitoring more than official announcements. Documentation, repositories, renewal behaviour and community activity can all provide useful signals, although none should be treated as definitive proof on its own.

Useful tripwires include:

• A price increase or material change to the terms of service.
• New sign-ups or automatic renewals being suspended.
• An end-of-life or shutdown announcement.
• Documentation labelling the product or a feature as "legacy."
• A sustained slowdown in public repository activity or releases.
• A key maintainer or founder leaving, particularly when other signs of declining support appear.
• A missed support commitment or a deterioration in response times.

For each tripwire, write down the action you will take. For example, a price increase might trigger a contract review, while an end-of-life announcement could trigger an immediate migration plan. The important point is to agree on the response in advance, rather than waiting until the situation becomes urgent.

When is a migration sprint worth buying outside engineers for?

Hiring external engineers can make sense when the migration work is clearly defined, limited in scope and easy for your team to review. Vendor migrations often fit these conditions because they have a specific goal, such as moving data to a replacement service or building an adapter that allows your product to use a different provider. As a company that sells engineering hours, RocketDevs has a commercial interest in this recommendation, so it is worth assessing the benefits and limitations carefully.

A forced migration can be well suited to additional engineering support. It has a defined starting point, a clear finish line and tests that show whether the work is complete. For example, you can confirm that an export loads successfully into the replacement system or that the new service produces results consistent with the old one.

RocketDevs offers vetted remote developers at $9.99/hr for Associate roles, $21.99/hr for Mid-senior roles and $30.99/hr for Senior roles. Each developer completes 6-8 hours of vetting before placement, and only the top 2% are accepted. The 14-day risk-free trial is money-back and 100% honoured.

This trial allows you to test the working relationship on a contained task, such as building one adapter or writing an export-and-import script, before committing to a larger migration sprint. An external developer does not need to understand your entire system to deliver useful work, provided the task is properly specified and someone on your team can review the result.

There are situations where hiring extra engineers will not solve the underlying problem. If nobody on your team can review the work, you risk creating another dependency that the business does not fully understand. If knowledge of the vendor integration exists mainly in one person's head, document that knowledge first. RocketDevs' guide to the bus factor in small teams explains why relying on a single person creates operational risk.

If the real constraint is your remaining runway rather than the number of available engineering hours, review what to cut from engineering costs when runway is short before committing to additional spending.

When the adapter is clearly specified and an internal engineer can review the work, consider building a vetted team with RocketDevs. Start with one export-and-import script, verify the quality and fit, and expand the scope only if the results justify it.

Elite Talent. Honest Price.

For a broader view of how to structure a growing engineering team around decisions like these, see RocketDevs' guide to scaling a startup.

Conclusion: build a business that can survive the next acquisition

You cannot control who acquires your vendor, what the new owner prioritises or how much notice you get before a product changes. You can control how much power that decision has over your business.

The startups that navigate vendor acquisitions successfully are not necessarily the ones with the biggest engineering teams or the most sophisticated infrastructure. They are the ones that know which dependencies they cannot afford to lose, understand what their contracts actually protect, and have a credible plan for moving before a deadline forces their hand.

Over the next 90 days, turn that resilience into something concrete. Read your contracts. Document your critical vendors. Test your data exports. Build abstraction layers where a replacement would otherwise require a rewrite. Agree on the warning signs that would trigger a move, and prove that your fallback works while you still have the freedom to choose your timing.

You do not need to replace every vendor or build every tool yourself. You need to know where you are exposed, what it would take to get out, and whether you could do it without putting your customers, product or runway at risk.

That is the real lesson of a forced migration: vendor independence is not about avoiding dependencies. It is about making sure none of them can make your next major business decision for you.

Build that flexibility now, and an acquisition announcement becomes a decision to evaluate, not a crisis you have to survive.

Frequently asked questions

What should you do first when a vendor you depend on is acquired?

Read your contract before taking action, and avoid making changes to production until you understand your options. The vendor's announcement explains its public position, while your contract sets out your rights. During the first three days, review the clauses covering contract length, termination, assignment, change of control, price changes and data return. Record when your current contract ends.

Can you cancel your contract if your vendor is acquired?

Only if your contract gives you that right. None of the five click-through agreements reviewed for this article gives customers a cancellation right triggered specifically by an acquisition. A Delaware court ruled in 2013 that a reverse triangular merger generally does not constitute an assignment, meaning an anti-assignment clause may not protect you. An express change-of-control clause may offer more protection. Self-service plans can often be cancelled more easily, but your practical ability to leave still depends on how quickly you can move your data and code.

How much notice will you get if the new owner shuts a product down?

There is no standard notice period. The historical cases discussed in this article range from seven days for X's developer platform to approximately 92 days for Neptune, 95 days for Heroku's free plans and about a year for Parse. AWS contractually promises at least 12 months' notice before discontinuing material functionality, which is the longest notice commitment in the five terms read. Ask your vendor to confirm its notice obligations in writing rather than assuming you will have time to migrate.

Should you migrate immediately after an acquisition announcement?

No, but you should start preparing straight away. Changes often arrive after an acquisition closes, and the cases discussed here show that the timeline can range from less than three weeks to more than 11 years. An immediate migration could waste engineering time if the product remains suitable for years. Instead, classify your dependencies, test your data exports and build an abstraction layer for services that would otherwise require a rewrite. Use the evidence you gather over the following 90 days to decide whether to stay, hedge or leave.

How do you know a vendor is being wound down?

Watch for warning signs before an official shutdown announcement. These can include closed sign-ups, suspended automatic renewals, documentation labelled "legacy," a repository README changing to "maintenance mode," and founders or key maintainers leaving. Research on startup acquisitions has also found that acquired employees, including founders and high-earning employees, may leave after a deal. While no single signal proves a product is being discontinued, several changes together can indicate growing risk. Monitor these signals weekly during the first three months after the acquisition.

How can you prepare for a vendor shutdown before one is announced?

Maintain a vendor register that identifies your critical dependencies, the consequences of losing each service, your contractual exit rights and the alternatives available. Test data exports and imports before you need them, and build an abstraction layer where replacing a vendor would otherwise require substantial changes to your code. Set clear warning signs that would trigger a migration, and document the steps your team would take. A tested fallback gives you control over the timing and cost of a move instead of leaving you to respond under pressure.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Broadcom Inc., Form 8-K, completion of the VMware acquisition, filed 22 November 2023
• The Register, Broadcom ends perpetual VMware licences, Simon Sharwood, 12 December 2023
• SiliconANGLE, Broadcom accelerates VMware transformation, killing off perpetual software licenses, Mike Wheatley, 12 December 2023
• CIO Dive, AT&T, Broadcom move toward settling legal feud, Matt Ashare, 14 October 2024
• Legal Dive, Broadcom and AT&T reach settlement in principle over VMware support, Matt Ashare, 22 November 2024
• iX Magazin (heise), EU cloud provider: Broadcom raised VMware license prices by 800 to 1500 percent, Axel Kannenberg, 23 May 2025
• TechCrunch, Facebook buys Parse, Kim-Mai Cutler and Josh Constine, 25 April 2013
• InfoQ, Parse DBaaS shutdown, Sergio De Simone, 29 January 2016
• InfoWorld, Facebook is shuttering the Parse developer platform, Blair Frank, 28 January 2016
• Salesforce, Salesforce.com signs definitive agreement to acquire Heroku, 8 December 2010, and Salesforce.com completes acquisition of Heroku, 3 January 2011
• Heroku, Heroku's next chapter, 25 August 2022; TechCrunch, Heroku announces plans to eliminate free plans, Kyle Wiggers, 25 August 2022
• Microsoft, Microsoft to acquire GitHub for $7.5 billion, 4 June 2018, and Microsoft completes GitHub acquisition, 26 October 2018
• GitHub, New year, new GitHub, Nat Friedman, 7 January 2019; Fortune, Microsoft's GitHub will offer free private repositories, Glenn Fleishman, 7 January 2019
• Twitter, Inc., Form 8-K, completion of the merger, 31 October 2022
• The Register, Twitter eliminating all free API access, Brandon Vigliarolo, 2 February 2023; TheWrap, Twitter ends free access to API, Slav Kandyba, 2 February 2023
• Neptune, Acquisition and shutdown transition hub; InfoWorld, OpenAI to acquire AI training tracker Neptune, Gyana Swain, 4 December 2025
• Deno, Deno is joining Cloudflare, 9 October 2026
• Gautier and Lamesch, Mergers in the Digital Economy, Information Economics and Policy, 2021
• Gautier and Maitry, Big Tech Acquisitions and Product Discontinuation, Journal of Competition Law and Economics, 2024
• Cunningham, Ederer and Ma, Killer Acquisitions, Journal of Political Economy, 2021
• J. Daniel Kim, Startup acquisitions, relocation, and employee entrepreneurship, Strategic Management Journal, 2022
• Amazon Web Services, AWS Customer Agreement; Stripe, Stripe Services Agreement; Anthropic, Commercial Terms; Vercel, Terms; Supabase, Customer Agreement, all read 25 October 2026
• Delaware Court of Chancery, Meso Scale Diagnostics v. Roche Diagnostics, 62 A.3d 62, 22 February 2013
• Smith Anderson, Delaware court finds a reverse triangular merger does not result in an assignment by operation of law, April 2013; Koley Jessen, Anti-assignment provisions and their effect on transaction structures, Bart Dillashaw, August 2013
• UNCITRAL secretariat, Notes on the main issues of cloud computing contracts, 2019
• Bundesnetzagentur, Data processing services and provider switching; Penningtons Manches Cooper, A guide to the EU Data Act and switching rights, 23 February 2026; European Commission, Data Act explained
• UK Competition and Markets Authority, Cloud services market investigation, final decision 31 July 2025
• Federal Reserve, FDIC and OCC, Interagency Guidance on Third-Party Relationships: Risk Management, Federal Register, 9 June 2023
• WilmerHale, FTC reminds merging parties: don't jump the gun during the HSR waiting period, 13 January 2025; King & Spalding, Record gun-jumping penalty imposed by FTC, 9 January 2025
• Auth0, Export data and password hashes; Stripe, Request a payment data export
• Kaya, van den Berg and Wieringa, The Banking Industry Underestimates Costs of Cloud Migrations, IEEE Conference on Business Informatics, 2020
• Anthropic, Model deprecations and OpenAI SDK compatibility
• Opara-Martins, Sahandi and Tian, Critical analysis of vendor lock-in and its impact on cloud computing migration, Journal of Cloud Computing, 2016
• Alistair Cockburn, Hexagonal architecture, 2005; Microsoft, Anti-corruption layer pattern, Azure Architecture Center
• Gregor Hohpe, Don't get locked up into avoiding lock-in, martinfowler.com, 9 September 2019; Martin Fowler, Strangler Fig Application, 22 August 2024
• OpenTelemetry, What is OpenTelemetry?; npm registry, @opentelemetry/api downloads; PyPI Stats, opentelemetry-api
• SafeDep, LiteLLM PyPI compromise: credential stealer and backdoor, Kunal Singh, 21 October 2026; PyPI Stats, litellm
• OpenID Foundation, OpenID Connect Core 1.0; OpenFeature, Introduction
• Cloudflare, R2 S3 API compatibility; Google Cloud, Cloud Storage interoperability
• MinIO, minio/minio repository; It's FOSS, MinIO is done with open source, Sourav Rudra, 27 April 2026; Hacker News, MinIO is now in maintenance-mode; Wikimedia, MinIO pageviews
• HashiCorp, HashiCorp adopts Business Source License, 10 August 2023; Linux Foundation, Announcing OpenTofu, 20 September 2023; OpenTofu, Migrating from Terraform
• npm registry, parse-server downloads and parse downloads; Hacker News, Parse is shutting down today, 30 January 2017; Stack Exchange API, parse-platform tag and minio tag
• GitHub API, opentofu/opentofu, hashicorp/terraform and parse-community/parse-server; Stack Exchange API, opentofu tag and terraform tag
• HashiCorp, Form 8-K, merger agreement with IBM, 25 April 2024; IBM, Form 8-K, completion of the HashiCorp acquisition, 27 February 2025; IBM Newsroom, IBM completes acquisition of HashiCorp, 27 February 2025
• O*NET OnLine, Software Developers, 15-1252.00, BLS 2025 wage data
• Crunchbase News, In Charts: Seed Deals Keep Getting Bigger As Odds Of Reaching Series A Fall Dramatically, Gené Teare, 26 May 2026
• Pragmatic Coders, What a VC Fund Checks in Technical Due Diligence, 27 August 2026
• Digital Operational Resilience Act, Article 28