Vendor lock-in in BSS/OSS: how to spot it before the contract, not after

Where lock-in appears

When the operator picks a new BSS or OSS platform, lock-in is rarely discussed explicitly. The decision is taken on capabilities, cost, vendor reputation, references. Five to seven years later, when the operator wants to change the platform or do a major upgrade, migration costs are found to approach the original implementation cost.

These costs are usually not discussed at the start. They accumulate through dozens of small choices in the RFP, contract, architecture, customisations. Each choice individually reasonable, in combination producing lock-in.

Seven signs lock-in is accumulating

Sign 1. Proprietary data formats. The vendor stores data in a format that cannot be easily exported. If migration requires custom export tooling — lock-in.

Sign 2. Closed APIs. Vendor APIs are either limited or require commercial licence. External integrations require vendor cooperation.

Sign 3. Proprietary scripting language. Customisations through a vendor-specific language. Migration requires rewriting all customisations.

Sign 4. Bundled services. The platform comes with bundled services (consulting, integration, support) that cannot be disaggregated. Removing the vendor means losing all dependent services simultaneously.

Sign 5. Long-term commitment in the contract. Multi-year exclusive commitment. High termination penalties.

Sign 6. Vendor-specific data model. Schema designed around vendor capabilities. Migration to another platform means restructuring the entire data model.

Sign 7. Skill specialisation. The internal team builds expertise in vendor-specific tooling that is not transferable. Hiring or training a new team for a new platform — major investment.

If 4+ of the 7 signs are present — serious lock-in.

What to change in the RFP

Stage 1. Pre-RFP — define non-negotiables. What must not depend on the vendor. Data export capability. API openness. Customisation through a standard language. Skill transferability.

Stage 2. Explicit RFP requirements. Request data export tooling. Public API documentation. Standard scripting language for customisations. Disaggregated pricing for services. No bundled long-term commitments.

Stage 3. Evaluation. Score not only on features and cost. Score on lock-in resistance — each of the 7 signs above.

Stage 4. Contract. Negotiate exit clauses. Clear data ownership. Migration cooperation obligation. Pricing protections for the long term.

Stage 5. Architecture during implementation. Avoid building vendor-specific. Use standard interfaces. Document customisations. Skill diversification.

Each step incrementally reduces lock-in. None eliminates it fully — the operator cannot avoid all dependencies without huge cost. But meaningful reduction is possible.

What often becomes a barrier

Vendor influence on RFP design. Often the vendors that later win help design the RFP. This inevitably biases toward their strengths.

Cost optimisation without lock-in consideration. Procurement focuses on initial price, not TCO. A vendor with low initial price often has higher lock-in.

Skill development bias. The team becomes proud experts in a specific vendor — resists changes that devalue their expertise.

Limited alternatives. If the local market has only 2-3 viable vendors, real competition is limited.

Time pressure. RFP under time pressure — short list to top vendor with the best initial fit, lock-in considerations skipped.

What to do if already locked in

Most operators in the region are already in some form of lock-in. Exit paths are limited but exist:

Hybrid migration. Do not replace the whole platform — gradually move components. Add a new platform side by side, migrate workloads incrementally. Years rather than months.

Build a wrapper layer. Create an abstraction layer over vendor systems. New developments build on the abstraction, not directly on the vendor. Future migration is easier — the wrapper changes, applications stay.

Negotiate better terms. At contract renewal use the threat of exit as leverage. Significant cost reductions are possible if the exit threat is credible.

Skill diversification. Invest the team in multi-vendor expertise. Reduces future risk.

Selective open-source replacement. Some vendor components can be replaced by open-source alternatives. Not all, but where applicable — major lock-in reduction.

When lock-in concerns are not a priority

If the operator is small and one platform is sufficient on a long horizon, lock-in is less critical.

If the vendor is demonstrably long-term committed to the local market and pricing is stable — risk is lower.

If migration cost would be significant regardless of lock-in (because business processes are rebuilt around vendor capabilities), avoiding lock-in is marginal.

If the budget is constrained and the vendor is the lower-cost option, accepting some lock-in for cost savings is rational.

If industry interoperability standards are weak in this category (real for some legacy telco systems), lock-in is somewhat unavoidable.

Discussion points for the committee

In upcoming RFPs — which 7 signs of lock-in are checked? If not systematically — process gap.

What is the existing lock-in level in current systems? And the estimated migration cost?

What is the long-term strategy — staying with current vendors or planned migration?

At renewal of major contracts — what is the leverage and planned negotiation?

What is the skill diversification strategy in the team?

How SamaraliSoft can help

Vendor Lock-in Audit & RFP Design — audit of current vendor relationships across 7 lock-in dimensions, design of an RFP framework for new procurement with lock-in resistance, contract negotiation support, migration roadmap for existing locked relationships, and a skill diversification plan over 18-24 months.

Related reading

• /en/architecture/telecom-around-core-architecture/ — layer around the core
• /en/insights/telecom-cloud-vs-onprem/ — hosting choices
• /en/insights/telecom-event-driven/ — event-driven foundation
• /en/insights/telecom-data-contracts/ — data contracts

Sources

• Ministry of Digital Technologies — telecom infrastructure UZ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — telecom market
• MNP.UZ — number portability
• Central Bank of Uzbekistan — biometric verification for digital banking