What Happens to Your Business When a Platform You Depend On Changes Everything

In February 2024, a scheduling platform used by thousands of service businesses changed its pricing model overnight. Plans that had been $25 per month jumped to $80 per month. Features that were included in the base tier moved behind a premium paywall. There was no grandfather clause. Users were given thirty days to accept the new pricing or find an alternative.

For individual users, this was annoying. For businesses that had built their operations around the platform, embedding its scheduling links on their website, integrating it with their CRM, training their staff on its workflows, and storing years of appointment history inside it, the change was disruptive on a scale that the platform's leadership almost certainly did not intend.

This is not an isolated incident. It is a recurring pattern in the software industry, and it is accelerating. Businesses that depend on platforms they do not control are exposed to a category of risk that most owners never evaluate until it arrives.

Real Scenarios: How Platform Changes Disrupt Businesses

Platform dependency risk is not theoretical. It has a documented history of causing significant business disruption, and the examples span every industry and company size.

Price restructuring. In 2023, Unity Technologies, the game engine used by thousands of indie developers and studios, announced a per-install runtime fee that would have dramatically increased costs for successful games. The backlash was severe enough that Unity partially reversed course, but not before studios had spent weeks calculating the financial impact and exploring alternatives. Businesses built on Unity's previous pricing model discovered that their cost projections were meaningless the moment Unity decided to change.

Feature removal. Mailchimp, the email marketing platform, removed its free tier's automation features in 2022, forcing small businesses that relied on automated email sequences to either upgrade to paid plans or rebuild their email workflows on a different platform. For businesses that had spent months building and testing automation sequences, the migration cost was measured in weeks of work and disrupted marketing campaigns.

API shutdowns. Twitter's decision to restrict and then effectively shut down free API access in 2023 affected thousands of businesses that had built analytics tools, social publishing workflows, and customer service systems on that API. Companies that had invested in Twitter-based infrastructure faced a binary choice: pay enterprise-level API fees or abandon their Twitter-integrated systems entirely.

Terms of service changes. Amazon's marketplace regularly updates its seller terms, and each update has the potential to reshape the economics for sellers who depend on the platform. Changes to return policies, referral fees, advertising requirements, and inventory storage rules have individually and collectively squeezed margins for sellers who built their entire business model on Amazon's marketplace.

Acquisition and sunset. When a large company acquires a smaller tool and decides to integrate it into their ecosystem or discontinue it entirely, users of the acquired tool face forced migration. Google has been particularly active in this regard, with a public list of discontinued products that runs to over 280 entries. Businesses that built workflows around Google Reader, Google+, Inbox by Gmail, Google Domains, and dozens of other products learned that a product's popularity does not guarantee its continuity.

These are not edge cases. They are the normal operating behavior of platform companies pursuing their own strategic interests.

Platform Risk Versus Infrastructure Risk

Not all technology risk is the same. Understanding the distinction between platform risk and infrastructure risk helps businesses make better decisions about where they put their operational weight.

Platform risk is the exposure created when a business depends on a system it does not own, control, or have contractual guarantees about. The platform's owner can change pricing, features, terms, APIs, or the product's very existence at any time. The business using the platform has no leverage, no vote, and often no advance notice.

Infrastructure risk is the exposure created by the technology a business does own or control. Custom-built systems can break. Self-hosted servers can fail. Proprietary code needs maintenance. These risks are real, but they are manageable because the business has full authority over how they are addressed.

The key difference is agency. Platform risk removes the business's ability to decide. Infrastructure risk preserves it. When your own system breaks, you decide when and how to fix it. When a platform you depend on changes, you react on their timeline, not yours.

This distinction does not mean that businesses should avoid all platforms. Email, video conferencing, cloud hosting, and other commodity functions are well-served by platform providers because the switching costs are relatively low and the functions are standardized. The risk becomes acute when a platform handles a core business function, something central to how the business delivers value and serves clients, with high switching costs and no easy alternatives.

How to Evaluate Your Dependency Level

Most businesses have never conducted a systematic evaluation of their platform dependency. They know what tools they use. They do not know how dependent they are on each one.

A dependency evaluation requires answering four questions about each platform in your stack.

What is the switching cost? This is not just the subscription price. It includes the cost of migrating data, retraining staff, rebuilding integrations, updating client-facing systems, and managing the transition period where productivity dips. For some platforms, the switching cost is trivial: moving from one video conferencing tool to another takes a day. For others, particularly CRMs, project management systems, and industry-specific platforms, the switching cost can represent months of disruption.

How much institutional data lives in the platform? Data that exists only inside a third-party platform is effectively held hostage. If the platform changes terms or shuts down, accessing that data may become difficult, expensive, or impossible. Client communication histories, project records, financial data, and operational analytics stored exclusively in a platform represent a vulnerability.

How central is the platform to client-facing operations? A platform that handles internal communication is less critical than one that manages client interactions. If your client portal, scheduling system, or payment processing runs through a single third-party platform, a disruption to that platform directly affects your clients, not just your internal team.

What are the contractual terms regarding data export and API access? Read the terms of service. Many platforms have the right to change their API terms, limit data exports, or modify functionality with minimal notice. Others provide contractual guarantees about data portability and API stability. The difference matters enormously when evaluating long-term risk.

Scoring each platform on these four dimensions produces a dependency map that shows where the business is most exposed. Most businesses discover that two or three platforms represent critical dependencies with high switching costs, significant data concentration, and limited contractual protections.

What a Forced Migration Looks Like

Businesses rarely plan for platform migrations. They are forced into them. And forced migrations are invariably more expensive, more disruptive, and more stressful than proactive ones.

The timeline of a typical forced migration follows a predictable pattern.

Week one: recognition and panic. The platform announces a change. The team scrambles to understand the implications. Initial research into alternatives begins, often under time pressure because the platform's change has a deadline.

Weeks two through four: evaluation and selection. The team evaluates alternative platforms, requests demos, negotiates pricing, and makes a selection. This process is compressed because there is a deadline, which means the evaluation is less thorough than it would be under normal circumstances. The selected alternative may not be the best option; it is the best option available within the time constraint.

Weeks four through eight: migration. Data needs to be exported from the old platform and imported into the new one. Historical data often does not transfer cleanly due to format differences. Custom fields, tags, categories, and relationships between records may not map one-to-one. Someone, usually a senior person who should be doing other things, oversees the migration to ensure critical data is not lost.

Weeks eight through twelve: stabilization. The new platform is live, but the team is not yet proficient. Workflows that were automatic on the old platform are now manual until the new platform's automation is configured. Client-facing systems that integrated with the old platform need to be reconnected to the new one. Productivity dips measurably during this period.

Weeks twelve through twenty: normalization. The team reaches proficiency on the new platform. Automation is rebuilt. Integrations are reestablished. The business returns to its pre-migration operational level, though some historical data and institutional knowledge is inevitably lost in the transition.

The total cost of a forced migration for a mid-market business is typically measured in tens of thousands of dollars when factoring in staff time, productivity loss, potential revenue disruption, and the opportunity cost of leadership attention diverted from strategic priorities.

The Hidden Cost of Free and Cheap Tools

Free tools are not free. The cost is simply denominated in a different currency: data, dependency, and future leverage.

When a business adopts a free tool, it makes an implicit trade. It gets functionality today in exchange for accepting whatever the platform decides to do tomorrow. The platform is not running a charity. It is acquiring users, collecting data, and building market position. When those users are sufficiently invested, the platform monetizes through pricing, data use, or both.

The pattern is consistent. Launch free or cheap. Acquire a critical mass of users. Wait until switching costs are high. Then introduce or increase monetization. LinkedIn followed this pattern with premium features. Slack followed it with message history limits. Zoom followed it with meeting duration limits on free accounts. Each company made their free tier just limited enough to push businesses toward paid plans, after those businesses had already built workflows around the platform.

Cheap tools carry a similar risk. A $10 per month tool that becomes a $50 per month tool represents a 400% price increase that the business has no ability to negotiate if it is locked into the platform's ecosystem. For a single tool, the dollar amount may be manageable. Across a stack of ten or fifteen tools, the cumulative exposure is substantial.

The real cost is not the price increase itself. It is the loss of negotiating leverage. When your operations depend on a platform, you are not a customer negotiating a fair price. You are a captive audience accepting whatever terms are offered. The platform knows your switching costs are high. You know your switching costs are high. The negotiation is over before it starts.

How to Build Resilience Into Your Technology Decisions

Technology resilience does not mean avoiding all third-party tools. It means structuring your technology decisions so that no single vendor change can disrupt your core operations.

Data portability as a requirement. Before adopting any platform for a core business function, verify that you can export your data in a standard, usable format at any time. Not through a support ticket. Not as a CSV with garbled formatting. A clean, complete export that you could import into an alternative system. If a platform does not offer this, it is telling you something about how it views the relationship.

Separating core from commodity. Classify each function in your technology stack as either core or commodity. Commodity functions, such as email, file storage, and video conferencing, are standardized and easily switchable. Use platforms for these. Core functions, such as client management, project delivery, and operational workflows, are unique to your business and difficult to migrate. Consider owned infrastructure for these.

Maintaining integration independence. When integrating systems, build the integration in a way that is not dependent on a single platform's proprietary API. Middleware tools, webhooks, and standardized data formats create a layer of abstraction between your business logic and any specific vendor. If one vendor changes, you replace that connection rather than rebuilding your entire workflow.

Regular dependency reviews. Conduct a platform dependency review annually, evaluating each tool against the four questions described earlier. This is not about paranoia. It is about awareness. Knowing your dependencies allows you to make proactive decisions rather than reactive ones.

Contractual protections where possible. For platforms that handle critical business functions, negotiate terms that include data portability guarantees, pricing stability periods, and advance notice of material changes. Enterprise agreements often include these protections. Small business plans rarely do. Understanding the difference matters when evaluating which pricing tier to select.

Migration readiness. For your two or three most critical platforms, maintain a documented migration plan that outlines what data needs to be exported, which integrations need to be reconnected, and what the estimated timeline and cost would be. You may never need to execute the plan, but having it reduces the panic and compression that make forced migrations so expensive.

Owning What Matters

The technology landscape will continue to change. Platforms will merge, pivot, reprice, and shut down. This is not pessimism. It is the documented behavior of an industry driven by growth targets, investor expectations, and competitive pressures that do not always align with their users' interests.

The businesses that navigate these changes successfully are not the ones that pick the "right" platforms. No platform choice is permanent. They are the ones that maintain enough independence to make transitions without disrupting their core operations.

This means owning the infrastructure that is central to how you deliver value. It means using platforms where appropriate but never building your entire operation on a foundation you do not control. And it means evaluating technology decisions not just on today's features and pricing, but on the long-term risk profile of dependency.

Your clients depend on your business being stable and consistent. Your business, in turn, should depend on infrastructure that is equally stable and equally within your control. When the next platform change comes, and it will, the question is not whether you will be affected. The question is whether you will be disrupted.

Keep Reading

For a deeper look at the financial and strategic case for owning your operational systems, see our article on Own Your Infrastructure: Why Proprietary Systems Increase Business Value at /news/own-your-infrastructure. You can also read Why the SaaS Model Is Failing Growing Businesses at /news/why-saas-is-dead for a broader analysis of why the subscription model is breaking down for scaling companies.