Most businesses in Vidarbha do not run on one old system; they run on a chain of them. A FoxPro billing program from 2009, a Tally with custom macros, an Excel sheet that only one accountant understands, and a PHP web app whose developer stopped answering calls. This article is about how to tell when that chain has become a risk, what your options are, and how to replace it without stopping the business.
What counts as a legacy system
The word "legacy" sounds like it belongs to banks and railways. In practice, for an MSME manufacturer in an MIDC area, a distributor in Nagpur or a college in Gondia, legacy usually means one of these:
- A desktop application written in Visual Basic 6, FoxPro or Clipper, running on a Windows 7 machine nobody dares to update.
- Tally or Busy with a layer of macros, TDL customisations or Excel exports that hold the real business logic.
- A PHP or ASP.NET web application built five to ten years ago by a freelancer or an agency that no longer exists.
- A set of Excel workbooks passed around on WhatsApp, with formulas nobody wrote down.
- A licensed ERP whose vendor has stopped issuing updates, or whose annual maintenance you stopped paying.
None of these is bad on its own. A FoxPro system that has billed correctly for fifteen years has earned some respect. The question is not age; it is whether the system still lets the business do what it needs to do, safely.
Signs the system has become a risk
In our experience these are the signals that matter. If three or more apply, it is time to plan, not to wait.
- Only one person can operate or fix it. When that person is on leave, billing stops or reports are delayed. If they resign, you have a crisis.
- It cannot talk to anything else. GST returns are typed by hand from printouts. UPI collections are reconciled in a separate sheet. E-way bills or e-invoices need re-entry into a portal.
- It runs on an operating system or database that is out of support. Windows 7, Windows Server 2008, old MySQL or Access databases receive no security patches. If the machine is on the internet at all, it is exposed.
- Backups are informal. A pen drive, a copy on the accountant's laptop, or nothing. Ask when the backup was last restored and tested. If the answer is "never", the backup does not exist.
- Workarounds have become the process. Staff keep a parallel register or a WhatsApp group because the system cannot handle a case that comes up every week.
- Reports arrive too late to act on. Month-end stock or outstanding figures take days to compile, so decisions are made from memory.
- The vendor is gone or charges a premium for every small change. A field addition costs a fortnight of chasing and an invoice with no explanation.
Two of these are about people, not technology. That is usually where the real risk sits.
Your three options: wrap, migrate or rewrite
There is no single right answer. The choice depends on how much of the old system still works, how much data it holds, and how fast the business is changing.
Wrap it
Leave the old system running and put a new layer around it. A small service reads its database (or its exports) and feeds a web dashboard, a mobile app for salespeople or a WhatsApp notification. The core keeps billing; the new layer does what the core cannot.
This is the cheapest and fastest option. It works well when the old system is stable and the pain is mainly reporting and access. It does not fix an unsupported operating system, and it adds one more thing to maintain.
Migrate it
Move the data and the essential features into an off-the-shelf product: a modern billing and inventory suite, a hosted LMS, a clinic management system. You give up some customisation in exchange for a product that someone else keeps updated.
This works when your processes are close to standard for your trade. It works badly when the old system encodes a genuinely unusual way of working, because you will end up with workarounds again. We covered the trade-off in detail in custom ERP versus off-the-shelf.
Rewrite it
Build a new system around how the business actually runs today, then move the data across and retire the old one. This is the most expensive and slowest option, and the one with the highest payoff when done well.
The mistake we see most often is a rewrite that tries to reproduce the old system screen by screen, including the parts everyone hated. A rewrite is the one chance to fix the process, not just the software.
Comparing the options
| Factor | Wrap | Migrate to a product | Rewrite |
|---|---|---|---|
| Typical timeline | 3 to 8 weeks | 2 to 4 months | 4 to 9 months |
| Rough cost (indicative) | ₹75,000 to ₹3 lakh | ₹1 to ₹5 lakh plus subscription | ₹3 to ₹12 lakh |
| Fixes unsupported platform | No | Yes | Yes |
| Keeps unusual processes | Yes | Partly | Yes, and can improve them |
| Disruption to staff | Low | Medium | Medium to high |
| Ongoing dependence | Old vendor plus new | Product vendor | Whoever maintains the code |
These figures are rough guides for Indian MSME projects; the real number depends on how many modules, users and integrations are involved. Our custom software cost guide goes into what moves the price.
A phased plan that does not stop the business
Whatever option you pick, the sequence below is what we follow. It is close to our eight-step process, adapted for a system that is already live.
- Inventory what exists. List every system, spreadsheet and register, who uses it, and what data it holds. This takes a day or two and always surprises the owner.
- Get the data out first. Before anything is built, export the old system's data into a plain format (CSV or a modern database) and check it. Duplicate customers, negative stock and missing GSTINs will all appear here. Cleaning is tedious but it cannot be skipped.
- Pick one painful workflow. Not the whole system. Sales order to invoice, or admission to fee receipt. Build or migrate that one, run it in parallel with the old system for two to four weeks, and compare outputs daily.
- Cut over one module at a time. When the parallel run matches, switch that workflow and freeze it in the old system. Repeat for the next module.
- Retire the old system deliberately. Keep a read-only copy for the statutory retention period, take the machine off the network, and write down where the archive is. Do not simply let it fade.
A parallel run is the single most important step. It is also the one most often cut to save time, and the reason cut-overs go wrong.
What to ask a vendor before you sign
- Will you give us the source code and database access, or does the new system become another lock-in?
- How will data be migrated, and who checks it? Ask for a migration test on a real export before the contract is signed.
- What happens to GST, e-invoice and e-way bill flows? These are not optional.
- How does the system behave on a low-end Android phone with 3G? If salespeople in the field will use it, test that.
- What is the support arrangement after go-live, in writing?
If a vendor cannot answer the source-code question plainly, walk away. You may be replacing one legacy system with another. Our guide on how to choose a software development company in Nagpur has a longer checklist.
Where SailRight fits
We build replacement systems and wrap-around layers for businesses in Gondia, Nagpur and beyond, and our own RightSutra suite is one migration target for billing, stock and payroll. Our custom software development service covers the whole plan above, from inventory to retirement. If you would like a second opinion on an old system, talk to us.
- Legacy systems
- Modernisation
- Data migration
- MSME
- Custom software