Skip to content
Randhir VermaPMP®
All articles

Smart Utilities9 min read

The Handover Cliff: Forward-Deployed Engineering for the Day Your AMISP Walks Away

Randhir Kumar Verma, PMP®
Published 4 Oct 2026

The Handover Cliff: Forward-Deployed Engineering for the Day Your AMISP Walks Away

Executive Summary

India has installed 7.24 crore smart meters as of 30 June 2026, of which 5.73 crore sit under RDSS, against 20.33 crore sanctioned. Most boardroom conversation still treats that gap as the problem. It is not the problem I worry about.

The problem is at the other end of the contract. A typical AMISP engagement is a DBFOOT structure: design, build, finance, own, operate and transfer. In one rated transaction the shape is 27 months of installation plus 93 months of operation per meter — ten years, ending in handover to the DISCOM. The meters installed in 2023 and 2024 have already burned a quarter of that operating clock. The transfer date is not a distant abstraction. It is a dated liability sitting in a contract file, and almost nobody inside a DISCOM owns the readiness plan behind it.

Transfer moves assets. It does not move the ability to run them. The head-end system, the device key custody, the integration glue between meter, MDM and billing, the tribal knowledge of which feeder has a flaky backhaul — all of that lives inside the AMISP's team today. On transfer day it either lives inside ours, or it evaporates. Forward-deployed engineering is the discipline that closes that gap, and it has to start seven years early, not seven months.

The Cliff Nobody Priced

Read an AMISP contract carefully and you find a well-drafted asset transfer. You rarely find a capability transfer. The two are not the same thing, and the difference is where DISCOMs will lose money in the 2030s.

Consider what actually keeps an AMI estate alive on any given Tuesday. Somebody reconciles the head-end's device inventory against the billing master. Somebody notices that a firmware cohort has started drifting on clock sync. Somebody knows that the meters on a particular rural feeder stop reporting when a tower sheds load, and that the right response is a SIM profile change, not a site visit. None of this is in the SBD. All of it is in the heads of fifteen people on the AMISP's payroll who will be redeployed to their next contract within a month of transfer.

The Ministry of Power sees the shape of this. In September 2025 it moved to constitute a steering committee and expert sub-group to standardise training modules and SOPs for smart meter data utilisation, standards adoption and cybersecurity practice. That is the right instinct. But a national SOP is a floor, not a transition plan for a specific estate with a specific vendor mix and a specific transfer date.

There is a second reason to care now rather than later. The Power Secretary has publicly pushed for full interoperability across meters so that "there should not be any locking between any manufacturer and any protocol." Interoperability is a procurement lever. It only becomes an operating lever if the DISCOM has the engineering capacity to exercise it — to actually swap a head-end, migrate a key store, or re-point an MDM. A utility that cannot do those things is locked in regardless of what the standard says.

Why the Usual Answer Fails

The standard response is to write a transition clause with a 90-day knowledge transfer window and a documentation deliverable. I have watched that pattern fail in three different programmes, for three reasons that repeat every time.

Documentation describes the system as designed, not as operated. Every live AMI estate has a hundred undocumented workarounds, and those workarounds are the operating model.

A 90-day window assumes the receiving team exists. If the DISCOM has no AMI operations cell on transfer day, knowledge transfer is a lecture delivered to an empty room.

Finally, the people who understand the estate are measured on SLA performance until the last day of the contract. Teaching the client is, structurally, not their job.

So the fix cannot be a clause. It has to be an operating posture maintained for the life of the contract.

The Transition Readiness Ladder

This is the framework I use to assess where an estate actually stands. Each rung is a capability the DISCOM must be able to demonstrate without the AMISP in the room. Score each rung 0–3 and the gaps become a hiring and training plan rather than an anxiety.

RungCapabilityThe testWho must own it
1. VisibilityIndependent read of head-end and MDM healthDISCOM produces its own daily communication and data-availability number, and it matches the AMISP'sAMI operations cell
2. Data modelAuthoritative consumer–meter–DT–feeder mapping held DISCOM-sideA new meter can be traced from install to bill without vendor helpIT and commercial, jointly
3. Key custodyCryptographic key material and device credentials under DISCOM controlA key ceremony can be run and audited in-houseSecurity function
4. Integration contractsVersioned, tested interfaces between HES, MDM, billing and GISAny one component can be replaced in a test environmentEnterprise architecture
5. RunbooksField and NOC procedures written from observed incidentsA JE resolves a non-communicating meter class without escalationSDO and field organisation
6. Change controlDISCOM approves firmware and configuration changes on evidenceA firmware cohort rollout is staged, measured and reversibleAMI operations cell
7. Commercial leverageSLA measured on DISCOM instrumentationPenalties and incentives computed from our data, not theirsContracts and finance

Most estates I have examined sit between rung 1 and rung 2. Rung 3 is where the discomfort begins, because key custody is a question with a yes or no answer and the answer is usually no.

What Forward-Deployed Engineering Actually Looks Like Here

Forward-deployed engineering is often described as putting engineers near customers. In a DISCOM it means something sharper: a small, permanent team that sits between the AMISP's operation and the utility's own commercial reality, and whose output is institutional memory.

Concretely, in a North Bihar context, that team does four things. It instruments independently — our own queries against our own copy of the data, so that every number in a review meeting has a DISCOM-side provenance. It writes runbooks from live incidents, in the field, with the JE who solved it, in the language that JE uses. It shadows the AMISP's change calendar, so that firmware pushes and configuration changes are reviewed by someone who will still be here in 2033. And it owns the seams — the interfaces where meter data becomes a bill — because that is where revenue leaks and where no vendor's SLA reaches.

The cost is modest. Six to ten engineers, properly deployed, against an estate worth thousands of crores. The alternative is to discover on transfer day that we have bought ten years of metering and zero years of metering capability.

A note on sequencing. The estates being installed now, before the RDSS sunset of 31 March 2028, are the ones whose transfer falls in the mid-2030s. There is time. Early installs do not have that luxury, and they should be assessed first.

What This Means for Leaders

  1. Pull the transfer date into your board pack. For each AMISP package, publish the contractual transfer month alongside installation progress. If your dashboard shows installs but not the handover clock, it is measuring the easy half.
  2. Stand up the AMI operations cell this financial year. Not a project team — a permanent function with a named head, reporting high enough to say no to a vendor change request.
  3. Audit rung 3 immediately. Ask one question: can we run a key ceremony without our AMISP? Treat a "no" as a security finding, not a roadmap item.
  4. Make SLA measurement DISCOM-side. Compute availability and data-completeness on your own instrumentation. Matching numbers build trust; diverging numbers reveal the real estate.
  5. Fund runbook capture as a deliverable. Pay for incidents turned into procedures, with field staff as co-authors. It is the cheapest insurance in the programme.
  6. Put capability milestones in every new AMISP contract. Staged capability handover at year three, five and seven, with payment consequences — not a 90-day window at the end.

Key Takeaways

  • AMISP contracts are DBFOOT structures that end in transfer; a documented example runs 27 months of installation plus 93 months of operation per meter.
  • Transfer moves assets. Capability has to be built in parallel, starting years earlier.
  • India is at 7.24 crore meters installed against 20.33 crore sanctioned, with RDSS sunsetting on 31 March 2028 — the earliest estates are already a quarter through their operating term.
  • Interoperability mandates only create leverage for utilities that can technically exercise them.
  • The Transition Readiness Ladder turns a vague anxiety into a scored, budgetable capability plan.
  • Forward-deployed engineering in a DISCOM is memory infrastructure: instrument independently, write runbooks from incidents, shadow change, own the seams.

Written from the field in North Bihar, where the handover clock is already running.

Sources: India's smart meter population at 7.24 crore: Parliament (T&D India, Aug 2026) · Ministry of Power, Rajya Sabha Unstarred Question No. 943 (Jul 2026) · ICRA rating rationale, Apraava Smart Meter Private Limited (May 2026) · India seeks interoperability in smart meters — Power Secretary (The Tribune, Dec 2025) · Government to form experts' committee to train DISCOMs on smart meter data (Mercom India, Sep 2025) · AMISP Standard Bidding Document (REC)

ShareLinkedInWhatsAppX

Enjoyed this? Get the next one by email

Occasional notes on smart metering, AMI and AI in utilities. No spam; unsubscribe in one click.

By subscribing you agree to the Privacy Policy.

Comments

No comments yet. Be the first to share a thought.

Leave a comment

Your email is never shown. Comments appear after they have been reviewed.