Vendor lock-in is not always bad. Sometimes a platform is the right strategic choice, the integration with the rest of the estate is genuinely valuable, and the cost of leaving is offset by the productivity of being inside the ecosystem. The risk appears when organisations lock themselves in accidentally — without understanding cost, exit paths, integration limits, operating skills, or long-term governance burden.
Vendor-neutral technology decisions are not about avoiding every commitment. They are about choosing deliberately, with eyes open. This is the framework we use in advisory work to help leaders evaluate cloud, SaaS, security, and infrastructure choices on the dimensions that actually matter five years out.
What “vendor-neutral” actually means
Vendor-neutral does not mean platform-snobbish. It does not mean “always the multi-cloud option” or “open source by default” or “anti-Microsoft” or “anti-AWS”. Those are positions, not principles.
Vendor-neutral means recommendations are not driven by partner relationships, commercial incentives, certification programmes, or familiarity bias. The recommendation comes from the trade-off analysis, not from what is convenient to sell or comfortable to deliver.
The practical test: when a vendor-neutral consultancy recommends a Microsoft platform, it can equally well recommend the Google or AWS equivalent in a different context. When a partner-led firm recommends Microsoft, the recommendation is structurally biased — even if individually correct — because the partner economics make the alternative harder to recommend.
We work with all major platforms. The work is to choose the right one for the situation, not the one we are best paid to deliver.
Evaluate outcomes first
Define what the business needs: better security, faster delivery, lower cost, easier collaboration, improved resilience, stronger compliance, or simplified operations.
The mistake we see most often: comparing platforms before defining outcomes. The conversation starts with “should we use Azure or AWS?” rather than “what business outcome are we trying to achieve, and which platform serves it best?”. The first question has no answer. The second produces a defensible recommendation.
Good outcome definitions are specific enough to disqualify options:
- “We need to reduce reporting time from three days to one” — disqualifies platforms that do not have strong data-warehouse integration with the existing stack.
- “We need to migrate two acquired companies onto a single tenant within 18 months” — disqualifies platforms that lack the migration tooling for the specific source environments.
- “We need to satisfy POPIA, ISO 27001, and our financial-services regulator” — disqualifies platforms that do not have demonstrable regional certifications and audit support.
Outcomes that disqualify nothing — “we want better technology”, “we want to be more agile” — are not outcomes. They are aspirations. The advisory work is to convert aspirations into outcomes that can shape a decision.
Compare operating impact
A tool that looks cheaper can become expensive if it requires skills the team does not have, creates integration complexity, or adds manual operational work.
The operating impact dimensions that matter most:
- Skills fit. Does the team already know how to operate the platform? If not, what does the hiring or training plan look like? Hiring for AWS expertise in a market dominated by Azure professionals is a real cost.
- Tooling ecosystem. Does the platform play well with the IDE, CI/CD pipeline, monitoring, and security tooling already in place? Forcing a tooling rewrite to fit the platform is real cost.
- Operational complexity. Some platforms have cleaner defaults; others require careful configuration to be operated safely. Platforms that need a dedicated platform engineering team to be safe are more expensive than the licensing line suggests.
- Vendor support model. How does paid support work, what is the response time at the relevant tier, and what does it cost? This is rarely visible in the comparison spreadsheet.
- Documentation quality. Some platforms have excellent documentation that engineers can self-serve from. Others require Stack Overflow archaeology and consulting engagements to operate. Documentation quality is real cost.
A weaker team running a well-suited platform routinely outperforms a stronger team running a poorly-suited platform. The platform decision is partly a team decision.
Understand exit paths
Before committing, understand data portability, identity integration, automation options, contract terms, migration complexity, backup options, and support dependencies.
The honest reality: cloud and SaaS exits are hard. Vendors design to be sticky, and the data, identity, integration, and operational dependencies accumulate. The cloud-portability story is mostly marketing.
What helps:
- Open formats wherever possible. Postgres-compatible databases over proprietary engines. S3-compatible object storage over platform-specific APIs. Kubernetes over platform-specific orchestration. Open authentication standards (OAuth, SAML, OIDC) over proprietary identity. None of these eliminate the cost of switching but they reduce the lock-in surface meaningfully.
- Negotiated egress allowances. Bulk data egress is the most underestimated cost line in a cloud migration out. Negotiate egress concessions during the deal, especially for SaaS-on-cloud arrangements where data lives in a third party’s tenant.
- A documented exit plan that gets updated annually. Names the workloads, their dependencies, the data volumes, the estimated migration effort, and the reasonable destination. Treats exit as something the business could execute if necessary, not a theoretical exercise.
- A contractual review every renewal. The terms drift. Pricing changes, region changes, certification changes, support tier changes. Each renewal is the moment to test whether the platform still fits.
We are not fundamentalists about portability. Some platform-specific services (Azure Cosmos DB, AWS DynamoDB, Google BigQuery) are good enough that the lock-in is a defensible trade. The point is to choose the lock-in, not to acquire it accidentally.
Design for interoperability
Use open standards where practical: SAML, OAuth2, OIDC, APIs, infrastructure as code, portable data formats, and clear integration boundaries.
Interoperability does not mean rejecting the platform’s native services. It means designing the system so the next system can connect, the next platform can take over, and the next vendor can compete.
Practical patterns:
- Identity through open standards. SAML or OIDC for SSO into SaaS applications, even when the platform offers a native option. The native option is convenient; the open standard is portable.
- APIs over UI integration. When a system needs to talk to another, use the documented API and treat the API as the contract. UI screen-scraping and undocumented integrations are exit blockers.
- Infrastructure as code. Terraform, Pulumi, or the platform’s native IaC tooling. The IaC code is platform-aware but versioned and visible. Migrating between platforms involves rewriting the code; migrating without IaC is much harder.
- Data portability. Bulk export options documented. Backup formats that are not platform-locked. Schema documentation maintained.
- Decoupled architecture. Loose coupling between services through queues, events, and APIs makes individual components replaceable. Tight coupling makes the entire stack a single decision.
Interoperability is more expensive than going all-in. The premium is the option value of being able to change later.
Evaluate total cost of ownership
Direct service pricing is what salespeople compare. TCO is what finance compares twelve months after the decision.
The components of real TCO that the comparison spreadsheet usually misses:
- Egress and inter-region traffic. Cross-cloud, cross-region, and out-to-internet egress charges add up faster than expected.
- Licensing alignment. Existing Microsoft licences (Azure Hybrid Benefit) reduce Azure cost meaningfully for Windows and SQL Server workloads. The same workloads on other platforms require new licences or BYOL.
- Support contracts. Standard support is rarely sufficient for production. Premium tiers price between 3% and 10% of monthly spend.
- Skills and hiring. The cost of hiring or retraining for a platform the team does not yet operate well.
- Platform engineering overhead. Cloud platforms require ongoing engineering investment to stay safe and cost-controlled. Budget for it explicitly.
- Operating cost of governance. A poorly-governed cloud account costs 30–50% more than a well-governed one through over-provisioning, idle resources, and storage tier mismatches.
We typically model TCO on a 36-month horizon with assumed workload growth. Most decisions look different on a three-year view than on a first-year view.
Choose deliberately
The goal is not to avoid every platform commitment. The goal is to choose deliberately, with a clear understanding of benefit, risk, cost, and future flexibility.
A deliberate choice looks like:
- A documented decision with the alternatives considered and why they were rejected.
- An explicit acknowledgement of what the lock-in is, what it would cost to leave, and what the exit path looks like.
- A commitment to revisit the decision at a defined cadence — typically every contract renewal.
- A named owner accountable for the platform’s continued fit.
An accidental commitment looks like:
- A platform chosen because the existing partner discounted it.
- A SaaS tool adopted because someone bought it on a corporate card and the rest of the business absorbed the dependency.
- A cloud account that grew from a proof-of-concept to a production workload without the platform decision being made deliberately.
Vendor-neutrality is the discipline of catching the second pattern early and converting it to the first.
How we approach platform decisions
In our technology leadership and advisory work, we run platform-decision engagements as structured analyses across the six dimensions above: outcomes, operating impact, exit readiness, interoperability, TCO, and the deliberate-choice criteria. The output is a comparison document, a decision recommendation, a documented set of trade-offs, and a contractual checklist for the negotiation.
We also recover decisions that did not go well. When a platform commitment was made under pressure or without the analysis, the recovery work is similar in shape: assess the current state, identify the lock-in components, design a path that either improves the operating model on the current platform or sequences a controlled exit.
Where to start
If you are facing a platform decision, comparing two options, or wondering whether a current platform is still the right fit, the first practical step is a structured assessment. Two to three weeks of focused work produces a comparison document, a TCO model, and a defensible recommendation.
Start the conversation if you want a sounding board on a current decision, or if a recent technology choice has not delivered what was expected.