Every few years, a department looks at its fifteen-year-old core system — the one written in a framework nobody hires for, running on an OS out of support — and decides to replace it in one heroic procurement. Three years and several crores later, the old system is still running, now with a half-finished replacement beside it. We have been called into enough of these situations to see the pattern clearly, and to know it is avoidable.
The problem is rarely the technology. It is the shape of the programme: a single big-bang cutover concentrates every risk — data migration, user retraining, integration, political attention — into one weekend. Modernisation that works spreads that risk across dozens of small, reversible steps.
Start with a system inventory that tells the truth
Before any roadmap, build an honest inventory: what does each module actually do, who uses it, what does it integrate with, and — critically — where does the institutional knowledge live? In most departments, two or three officers carry the real business rules in their heads. Interview them early; their retirement date is a genuine programme risk.
Score each module on two axes: business criticality and technical health. The quadrant of critical-but-unhealthy modules is your modernisation backlog. Everything else can wait, and saying so out loud is the first budget you save.
Strangle, don't demolish
The strangler-fig pattern remains the most reliable approach we know for public-sector estates: put a facade in front of the legacy system, route traffic through it, and replace functionality slice by slice behind it. Each slice ships to real users, retires real legacy code, and can be rolled back on its own.
Pick a first slice that is visible but low-risk — a read-only citizen view is ideal
Freeze new features on the legacy core; every rupee of change budget goes to slices
Migrate data incrementally with reconciliation reports, never in one weekend
Keep the old and new systems in parallel until the numbers match for a full cycle
Sequence around procurement, not against it
Government modernisation lives inside procurement rules, and pretending otherwise is how programmes stall. Structure the roadmap into phases that each fit a fundable, tenderable scope with its own outcomes. A phase should be completable within a budget year and valuable even if the next phase is delayed — because in government, the next phase is always delayed.
A modernisation roadmap that requires five consecutive years of uninterrupted political attention is not a roadmap. It is a wish.
Measure the programme like an operator
Vanity milestones — modules delivered, sprints completed — tell you nothing about risk retired. Track instead: percentage of transactions flowing through the new path, legacy lines of code decommissioned, time to restore from backup, and the count of officers who can operate the new system unassisted. When those numbers move, the programme is real.
Modernisation is not a project with an end date; it is a capability a department builds. The estates that stay healthy are the ones that never again let a system age fifteen years without a plan.
