"Legacy" is not an insult and not an age. A twelve-year-old system that is documented, maintainable, and doing its job is not legacy; it is infrastructure. A three-year-old system nobody dares touch is legacy already. The word describes a relationship, not a birthday: a system becomes legacy the day the organisation is afraid of it. This guide is about recognising that day, choosing the right response, and executing the move without stopping the business.
- A system is legacy when changes are scary, knowledge lives in one head, or the platform underneath has lost support.
- There are exactly four strategies: rehost, replatform, rebuild, replace. Most projects that fail chose the wrong one, not the wrong vendor.
- The decision comes down to two questions: is the current behaviour worth keeping, and is the code worth keeping?
- Plan every migration as parallel-run with a reversible cutover. Zero downtime is a planning choice, not luck.
- Doing nothing is also a decision, and it has a price that compounds.
The signs a system has crossed the line
- Fear of change. Small edits are estimated in weeks, and every deployment needs a prayer. The cost of change, not the age, is the definition of legacy.
- The one-specialist problem. A single person (often external, often expensive) is the only one who can touch it. Your system has a bus factor of one.
- Dead platform underneath. The framework, CMS, or language version is past end-of-life: no security patches, shrinking pool of people who will work on it, rising cost for the ones who will.
- Workaround archaeology. The team's real process is a layer of manual workarounds on top of what the system actually does.
- It fails the phone test. For customer-facing sites: slow on mobile, broken on small screens, invisible to modern search. Your customers meet the worst version of you first.
The real cost of doing nothing
Keeping a legacy system feels free because the licence was paid long ago. It is not free. The costs are just distributed where accounting does not look: every feature the business wants and does not get; the hours of manual workarounds performed weekly, forever; the security exposure of an unpatched platform (and under India's DPDP Act, unpatched systems holding personal data are a legal exposure, not just a technical one); the specialist's invoices; and the compounding effect, because every year of postponement makes the eventual move bigger. Doing nothing is a decision, and it is rarely the cheap one over any horizon longer than a year.
The four strategies
Every modernization project, whatever a vendor calls it, is one of four moves. The industry has settled on these names:
How to choose: two questions
Strip away the consultancy frameworks and the choice reduces to two questions asked honestly.
Question one: is the current behaviour worth keeping? Do the workflows, screens, and rules encode real operational wisdom, or are they the fossil of how someone worked in 2014? If the team's daily workarounds are effectively a redesign proposal, the behaviour is not worth preserving, and you are in replace territory.
Question two: is the code worth keeping? Can a competent developer understand it, test it, and change it safely? If yes, replatform around it. If no, and the behaviour is still right, rebuild the behaviour and let the code go. Sentiment about sunk cost has no place here: code that cannot be safely changed has negative value, whatever it cost to write.
Behaviour worth keeping + code worth keeping = replatform (or merely rehost, if the code's only problem is where it lives). Behaviour worth keeping + code beyond saving = rebuild. Behaviour wrong, whatever the code = replace. That is the entire decision, and it is why the audit weeks matter more than the build weeks.
Code that cannot be safely changed has negative value, whatever it cost to write. Sentiment about sunk cost has no place in this decision.
Planning the migration: zero downtime is a choice
Whatever the strategy, the execution pattern is the same, and it is the same one we described for spreadsheet migrations: build the new alongside the old, prove it, then cut over reversibly.
- Inventory first. Every page, URL, integration, scheduled job, and quiet side-effect the old system has. Legacy systems always do more than anyone remembers; the inventory is where you find the invoice export nobody mentioned.
- Build in parallel. The new system takes shape on staging while the old one keeps serving. Nobody experiences an outage because there is never a moment without a working system.
- Migrate data with verification. Migrate, then reconcile counts and spot-check records against the source. "It probably all came across" is not a migration report.
- Cut over reversibly. DNS switch or traffic switch with the old system still warm behind it. If something is wrong, you switch back in minutes, not restore from backups in days.
- Watch the week after. Search console, error logs, and the people who use the system daily. Then, and only then, the old system is archived.
For customer-facing websites there is one more discipline: rankings. Every existing URL must redirect to its successor, metadata and structured data must survive the move, and search consoles must be watched through the transition. We wrote a full guide to migrating without losing your Google rankings, and it is the difference between a modernization and a quiet traffic disaster.
What it costs
Honest ranges, for the scale of business we work with. A website replatform, ageing CMS or .NET site onto a modern platform, content and SEO carried over, is typically ₹1.5 to 4 lakh over 3 to 5 weeks: the shape of our fixed-scope modernization package. A rebuild of an internal operational system depends on workflow depth; single-workflow systems land in the ₹3 to 6 lakh, 4 to 6 week range, and multi-workflow platforms are scoped individually, with the audit that precedes them fixing the price before you commit. Rehosting is days of work, not weeks. In every case the pattern to insist on: a fixed written price after an audit, not a day rate into fog.
What this looked like in practice
A UK real-estate firm came to us with the classic profile: an ageing .NET website, every change requiring a specialist, the business needing a platform its own team could run. Behaviour worth keeping, code not worth keeping, so: replatform. We rebuilt on WordPress with the CRM integration preserved, carried content and SEO across intact, and ran the old site until the new one was proven. It was live within a month and the business never went dark. The details are in our case studies.
The mistakes that sink modernization projects
- The big-bang rewrite. Two years of building a perfect replacement in secret, then a single terrifying switchover. Parallel-run in weeks beats big-bang in years, every time.
- Modernizing the technology but not the bus factor. If the new system is also understood by exactly one person, you have bought new clothes for the old problem. Documentation and handover are deliverables, not courtesies.
- Scope creep disguised as ambition. "While we're at it" is how a five-week replatform becomes a five-month replace. Modernize first; improve in phase two, deliberately.
- Forgetting the redirects. For public sites, skipped URL redirects convert years of earned search ranking into a 404 page.
- No rollback plan. If the cutover cannot be reversed in minutes, the cutover is not ready.
Leo Tech Labs is a consulting-led software firm. We plan migrations so the business keeps running while the ground moves under it.