Every technology selection process includes concerns about vendor lock-in. Teams evaluate platforms based partly on how difficult it would be to switch to alternatives if needed. But most organizations significantly underestimate what switching actually costs when the time comes.

I’ve led or advised on several major platform migrations over the past few years—moving off proprietary CRM systems, replacing custom enterprise applications, migrating from one cloud platform to another. The pattern is consistent: the switching costs are 3-5 times what was initially estimated, and the timeline extends 50-100% beyond original projections.

The obvious costs are data migration and application redevelopment. You need to extract data from the old system, transform it to match the new system’s schema, validate accuracy, and load it. For complex applications with years of accumulated data, this is substantial work. Budget $200,000-500,000 for enterprise-scale data migration projects, more for particularly complex or messy legacy data.

Application redevelopment costs depend on how much functionality was built on platform-specific features. If you used proprietary workflow engines, reporting tools, or integration frameworks, you’re rebuilding all of that functionality on the new platform. This can easily reach millions of dollars for enterprise applications with extensive customization.

But the costs that destroy timelines and budgets are the hidden dependencies and integration complexity. Applications don’t exist in isolation—they’re connected to other systems through data feeds, APIs, single sign-on, shared databases, or file exchanges. Each integration needs to be identified, understood, and rebuilt or reconfigured for the new platform.

I’ve seen organizations discover integrations they didn’t know existed during migration projects. Some legacy developer built a scheduled script seven years ago that extracts data from System A, transforms it, and loads it into System B. Nobody documented it, the original developer left years ago, and it runs on a server nobody actively manages. But if you turn off System A, System B stops receiving critical data and business processes fail.

Finding these undocumented dependencies is detective work. You can’t rely on documentation because it’s usually incomplete or outdated. You need to examine server logs, network traffic, database connection logs, and scheduled jobs to discover what’s actually talking to what. This takes weeks or months and still doesn’t guarantee you’ve found everything.

Business process disruption is another major cost category that’s usually ignored in initial estimates. Even with perfect technical migration, users need retraining, business processes need adjustment, and productivity drops during the transition period. If 50 people spend two months working at 60% normal productivity while learning a new system, that’s 20 person-months of lost capacity worth perhaps $200,000 in opportunity cost.

Change management and organizational resistance create delays that extend timelines significantly. People don’t want to change systems they’re comfortable with, even if the new platform is objectively better. They’ll find reasons to delay, request modifications to make the new system work like the old one, and push back against process changes required by platform differences.

This resistance manifests as extended parallel running periods where both systems operate simultaneously while the organization gradually transitions. This doubles the operational complexity and cost—you’re maintaining two platforms, reconciling data between them, and supporting users on both. Parallel running was supposed to last one month but extends to three or six months because various stakeholders aren’t ready to switch.

Vendor relationships also complicate exits. If you’re locked into a multi-year contract, you’re paying for the old system while also paying for the new one. Termination clauses might include penalties or require extensive notice periods. Vendors might withhold cooperation on data export or documentation if they’re losing a major customer.

Some vendors deliberately make exit difficult by using proprietary data formats, limiting export functionality, or maintaining documentation as tribal knowledge rather than written specs. This isn’t always malicious—sometimes it’s just that the vendor never prioritized export features because customers rarely leave. But it creates significant friction when exit time comes.

Licensing and contractual complexity adds cost. Your new platform has different licensing terms, different pricing models, different compliance requirements. Existing software licenses might not transfer or might have minimum commitment periods you can’t exit early. Cloud platform commitments might have long reservation periods where you’re paying for capacity you’re not using.

The timeline extension creates compounding costs. If migration was supposed to take six months but actually takes 18 months, you’re paying project team costs for an additional year. You’re delaying the benefits you expected from the new platform. You might be paying parallel licensing costs for longer than planned. The budget overrun isn’t linear—it accelerates as the project extends.

Risk management during migration is also expensive. You need rollback plans, extensive testing, and careful cutover orchestration to avoid catastrophic failures. This means maintaining redundancy, conducting dry runs, and potentially scheduling cutover during low-usage periods that require overtime pay.

I’ve seen organizations abandon migration projects midway through because costs and complexity exceeded the expected benefit. They’ve spent $2 million of a planned $3 million budget but realize they’re only 40% complete and the remaining work is more complex than initial phases. Walking away means writing off the investment but continuing means spending another $4-5 million they don’t have.

The organizations that successfully manage platform exits have several common practices. They start with extremely thorough discovery to understand all dependencies and integrations before committing to timelines or budgets. They expect costs to be 3x initial estimates and pad budgets accordingly. They allocate extensive time for testing and parallel running rather than aggressive cutover schedules.

They also bring in expertise—either consultants who’ve done similar migrations or experienced internal resources. Platform migration is specialized work that benefits enormously from experience. Using general IT staff without specific migration experience guarantees underestimation and mistakes.

When working with AI consultants in Sydney on migration planning tools, we built risk assessment frameworks that force teams to identify potential hidden dependencies and complexity factors. It doesn’t eliminate surprises but reduces their frequency.

The strategic question is whether avoiding lock-in is worth the architectural compromises required. Building on lowest-common-denominator features that work across multiple platforms means not using the advanced capabilities that make specific platforms attractive. You end up with a more expensive, less capable solution in exchange for theoretical portability you might never need.

Some lock-in is acceptable if the platform delivers sufficient value and the vendor is stable and well-managed. Not all lock-in is equal—being locked into AWS is different from being locked into a niche vendor with uncertain future. Platform switching risk should be evaluated based on vendor stability and market position, not just technical portability.

For critical applications, consider the switching cost as insurance premium. If moving to Platform B would cost $5 million, that’s the implied cost of lock-in to Platform A. Is Platform A’s superior functionality worth that switching cost risk? Sometimes yes, sometimes no, but at least the decision is informed by realistic cost assessment.

The organizations that get surprised by switching costs are those that evaluated lock-in theoretically without considering realistic exit scenarios. They knew switching would be “difficult” but didn’t quantify what difficult means in time, money, and organizational disruption.

For anyone evaluating platforms or concerned about vendor lock-in: estimate switching costs realistically, multiply your initial estimate by three, and decide whether that risk is acceptable given the benefits of the platform. Don’t assume you can easily switch just because data export exists and APIs are documented. Real switching costs extend far beyond technical migration to encompass organizational, process, and integration complexity that’s difficult to fully predict before you’re deep into the project.

Vendor lock-in isn’t inherently bad—it’s a trade-off between platform capabilities and switching flexibility. But understanding the real cost of that trade-off requires honest assessment of what exit would actually entail, not optimistic assumptions about simple migration paths that rarely exist in practice.