If you've ever sat in a PSU CIO chair, you know the pattern: ₹4-crore initial vendor selection, three years of rolling change-requests adding ₹6 crore more, a stalled migration project, an officer who signed off retiring/transferring, and a successor who finds the system can't do the one thing she actually needs. The vendor's account manager smiles. The change-request quote arrives next week.
This article puts numbers on what most PSU and government CIOs already feel intuitively: the real cost of vendor lock-in is 3-5× the build cost over the life of a system. And in 2026, with open-source delivery as standard, you don't have to accept it.
The five lock-in mechanisms (the ones nobody warns you about)
1. Source-code custody
Most government IT contracts say the vendor "delivers" the software. They rarely transfer source code, build scripts, or deployment automation. The system runs in production, but if you want to make a single change, you need the vendor. Forever.
2. Knowledge custody
Even if the source code is technically yours, the architecture is in the vendor's heads. Their PMO has the threading model, their solution architects know the data flows, their senior devs know which jobs run when. Take the team away and the system becomes a black box.
3. Change-request economics
Every non-trivial change becomes a CR. The CR goes through the vendor's BD team, gets quoted at 2-5× internal cost, takes 6-16 weeks for clearance + execution + UAT + sign-off. A change you could implement in 4 hours costs you ₹3-8 lakh and three months. Multiply by the number of times your departments rotate.
4. Integration custody
Once their HRMS sits between your finance, your treasury and your statutory filings, replacing it means rebuilding all the integrations. The cost of replacement = cost of original + cost of all integrations + downtime risk. They know it. You know it. They price accordingly.
5. Subscription compounding
Per-employee per-month SaaS pricing looks reasonable in year one. Multiply by 5,000 employees × 60 months and you're at ₹4-8 crore for what was originally a ₹1-2 crore build problem. The numbers compound silently.
Real 5-year TCO at three PSU sizes
Mid-range vendor pricing, India 2026, for an HR + payroll + attendance system. Numbers exclude integration cost, migration cost, training, and CR's — those usually add another 30-60%.
| Setup | 500 employees | 2,000 employees | 10,000 employees |
|---|---|---|---|
| SAP SuccessFactors / Oracle Fusion HCM | ₹1.4 crore | ₹4.8 crore | ₹16 crore |
| Darwinbox enterprise | ₹85 lakh | ₹2.6 crore | ₹9.2 crore |
| TCS / Wipro custom build (with their support contract) | ₹95 lakh | ₹3.4 crore | ₹12 crore |
| GreytHR Enterprise (mid-market) | ₹48 lakh | ₹1.6 crore | ₹5.4 crore |
| Big Helpers custom (open-source delivery) | ₹21 lakh | ₹39 lakh | ₹84 lakh |
The savings range from 56% (vs GreytHR at 500 emp) to 95% (vs SAP at 10,000 emp). The bigger the PSU, the more brutal the SaaS subscription compounding becomes.
The change-request trap, with a real example
An anonymised central PSU we audited had paid a top-3 Indian IT firm ₹4.2 crore over 5 years for an HRMS that still couldn't handle their custom OT structure for shift-based plant operators. They had filed 43 change requests in 5 years. Cumulative CR cost: ₹68 lakh. CRs that took longer than 90 days: 31 of 43. CRs that never delivered the requested behaviour even after closure: 12 of 43.
The HR team was running a parallel Excel system to compute OT correctly because the vendor's "solution" was always almost-right.
We rebuilt their HR + payroll + shift-OT module in 16 weeks for ₹38 lakh. Open-source delivery. Saved 5-year TCO: ~₹2.6 crore. Their HR director's quote: "I can finally trust my own payroll register."
Why GFR and GeM rules don't actually force lock-in
Many government CIOs assume GeM bidding rules force them into big-vendor procurement. They don't. Read GFR 2017 Rule 161 carefully — it allows EoI / RFP processes that are open to any registered Indian Pvt Ltd vendor, not just GeM-empanelled ones. Most state PSUs run their own SBD (Standard Bidding Document) which permits direct contracting under specified conditions.
The key is to write the RFP in a way that does NOT favour a single big-vendor by accident. Common red flags:
- Demanding "vendors with ₹500-crore turnover minimum" — this excludes good mid-size vendors
- Requiring "10 years of experience as prime contractor for government IT" — favours incumbents
- "Must have SAP / Oracle Gold Partner status" — locks you into one stack
- Subscription pricing only — locks you into per-user-per-month forever
Better RFP structure: deliverable-based, with mandatory open-source delivery and source-code-handover clauses. Many state IT secretariats have started writing RFPs this way since the MeitY 2023 open-source guidelines.
The escape route: open-source delivery as standard
Open-source-delivery contracts are the single biggest change in Indian government IT procurement in 2026. The model:
- Vendor builds the software
- Source code is delivered under MIT / Apache 2.0 / GPL with full git history
- You host where you choose (your DC, NIC cloud, MeghRaj, private VPS)
- You can hire any other vendor to maintain it, anytime
- Maintenance is a separate optional contract — 12 months at a time
The risk profile flips entirely. The vendor competes on quality of work, not on lock-in. Bad vendor? You leave next month. Mid vendor? You renew with leverage. Great vendor? You renew with confidence.
📐 We do this for PSUs
Custom government / PSU software with open-source delivery, on-premise hosting, GFR / GeM-aligned, AI-augmented agile development. Daily-update capable. Direct partner-led engagement.
How to structure your next RFP to escape lock-in
The boilerplate template (we share it free with PSU CIOs on request):
- IPR clause: "All source code, design files, documentation, and deployment automation shall be transferred to [Department] under MIT / Apache 2.0 open-source licence on every milestone delivery. Vendor retains no rights to PSU-specific customisations."
- Hosting clause: "Vendor shall not require hosting on vendor-specific infrastructure. System shall be deployable on [Department]'s on-premise / NIC cloud / MeghRaj infrastructure at [Department]'s sole choice."
- Maintenance unbundling: "Build contract and maintenance contract shall be separately tendered. Build vendor shall have no automatic right to maintenance contract."
- Knowledge transfer clause: "Vendor shall conduct minimum 40 hours of structured KT to [Department] in-house team or successor vendor at end of build phase, including architecture walkthrough, deployment runbook, and disaster-recovery procedures."
- Source-escrow clause (for sensitive systems): "Source code shall be deposited in third-party escrow with [escrow agent] within 30 days of go-live, with right of release to [Department] on vendor non-performance, bankruptcy, or contract termination."
These five clauses, inserted into your standard RFP, eliminate ~80% of vendor lock-in risk. They cost the build vendor nothing extra to honour (they're standard in commercial software contracts) and they cost the lock-in-game vendors a lot — which is why they oppose them.
Final thought
You're not stuck. The contracts your predecessors signed in 2018-2022 were structured for an era when source-code custody was the norm. India's IT estate has moved on. Your next RFP can move on too.
Talk to vendors who price the build, not the lock-in. They exist. Ask for source code on day one. Ask for open-source licence. Ask for maintenance to be separately re-tenderable. The serious bidders will say yes. The lock-in bidders will mysteriously not bid.
Want our open-source-delivery RFP template? WhatsApp Kashvi at +91 99939 82666 with your designation + PSU. Free, no strings. — Kashvi
Get our open-source-delivery RFP boilerplate
5 clauses that flip the lock-in risk · Free for PSU CIOs · WhatsApp to receive
💬 Request the template See Govt/PSU programme →Frequently asked questions
What is vendor lock-in in government IT contracts?
Vendor lock-in is the situation where a department becomes dependent on a single vendor's proprietary technology, data formats, or operational knowledge to such a degree that switching to another vendor becomes prohibitively expensive or operationally risky. Common causes: closed-source code, proprietary data formats, undocumented system, vendor-controlled cloud account, vendor-only knowledge of the deployed system.
How much does vendor lock-in actually cost a PSU over 5 years?
Conservatively: 3-8x the original contract value over 5 years. A Rs 50 lakh original SaaS subscription often becomes Rs 2-5 crore over 5 years through annual price increases (typically 10-15% annually), forced upgrade tiers, per-user growth pricing, and integration costs that compound. The migration cost when you finally try to leave is often 60-100% of building from scratch.
What contract clauses prevent vendor lock-in in a government IT engagement?
Six essential clauses: (1) IPR vests in the purchaser including source code + documentation + IaC; (2) source-code escrow with defined release triggers (vendor bankruptcy, persistent SLA breach, contract termination); (3) data export in open standard formats; (4) infrastructure portability - ability to migrate to any cloud or on-prem; (5) knowledge-transfer plan with paid weeks of overlap to successor vendor; (6) exit-cooperation obligation surviving termination for 6 months at agreed rates.
Can a PSU exit a SAP/Oracle/Microsoft enterprise contract mid-term?
Technically yes - most enterprise contracts have termination-for-convenience clauses with notice periods (typically 90-180 days). Practically very expensive: forfeiture of remaining licence prepayments, data-migration costs (often Rs 50L-5Cr depending on scale), retraining of staff, and the integration unwinding. The smarter move is contract-renewal-time renegotiation: enterprise vendors will often discount 30-50% if a credible exit threat exists.
What is source-code escrow and is it mandatory for PSU IT contracts?
Source-code escrow is a tripartite agreement (department + vendor + escrow agent) where the vendor periodically deposits the latest source code, build scripts, and documentation with a neutral third-party agent. The agent releases the deposit to the department under defined trigger conditions (vendor bankruptcy, contract termination, SLA breach). Not legally mandatory but strongly recommended by CVC and CAG audit framework. Recognised escrow agents in India: NSDL, NIXI, KEONICS.
How long does vendor migration typically take in PSU IT?
For a complex enterprise system (HRMS/ERP/CRM with 1000+ users): 9-18 months end-to-end. Phases: vendor selection 2-3 months, data migration design 1-2 months, parallel run 3-6 months, cutover 1-2 months, post-cutover stabilisation 2-3 months. The PSU pays for both vendors during the parallel run period - often Rs 30L-2Cr in additional cost. Custom-built systems with proper handover clauses migrate 40-60% faster.
What is the open-source alternative for typical PSU enterprise stacks?
For HRMS/payroll: ERPNext, OrangeHRM, custom Laravel/Postgres builds. For ERP: ERPNext, Odoo. For database: PostgreSQL replaces Oracle in 90% of cases. For office productivity: ONLYOFFICE or Collabora (replaces Microsoft 365 for most use cases). For CRM: SuiteCRM, custom builds. The technical capability is there; the procurement/migration cost is the main barrier - which is why phased migration over 18-36 months tends to work better than big-bang.
Can a vendor really sue a PSU for breach if the PSU exits the contract?
Yes, but it's rare and usually settles. Standard government contracts include termination-for-convenience clauses that limit the vendor's recovery to actual damages (not lost profits). The bigger risk for the department is reputational and procedural - a CVC enquiry into why the contract was terminated, audit objection by CAG, parliamentary questions. The right defence is a documented file showing material breach, opportunity to cure, and procedural compliance with the contract's termination clause.