Replace old software without stopping work

Legacy software is any system your business depends on that has become hard to change, hard to run or hard to find people for. Age alone is not the problem. Plenty of old software works well; the trouble starts when changing it costs more than the change is worth.

It takes many forms. A desktop billing program written in Visual Basic or FoxPro that runs on one office PC. A PHP website from 2010 that nobody dares update. An Access database that grew into the company’s stock system. A workbook of Excel macros that runs payroll. An ERP version the vendor stopped supporting years ago.

What they share is risk. The one person who understands the system may leave, the old Windows machine may die, and every new rule, from GST e-invoicing to a new payment method, is bolted on with a workaround that makes the next one harder.

There are four honest answers, and the right one is the cheapest that solves the real problem. If the software works but the machine under it is failing, it may only need moving to the cloud, unchanged. If the screens are the trouble, a new web front can sit on top of the old data for a while.

If the software can no longer keep up with how you work, it needs rebuilding, part by part. And if a ready-made product does what you need, buying it is usually quicker and cheaper than building, whether it is one of our own products, such as Ember POS for billing and stock or Hearth HRMS for payroll, or someone else’s.

We look at the old system before recommending anything, and we write down why. Often the answer is a mix: one part moved as it is, another rebuilt, a third replaced by a product.

The hardest part of replacing old software is learning everything it does. After years of changes, the real rules live in the code, the database and the habits of the people who use it, not in any document.

So we read all three. We go through the code and the database: the calculations, the hidden checks, the reports, the jobs that run at night. We sit with the billing clerk, the storekeeper and the accountant and watch them work, because they know the exceptions: the dealer who always gets an extra discount, the invoice that must be printed twice, the stock that is counted in kilos in one place and in pieces in another.

We write the rules down in plain language and check them with your team. Then we save the old system’s outputs for real cases, such as invoices, payslips and reports, and the new system must produce the same results before it goes live.

We replace old systems in parts, so the business never depends on one risky switch. The new system takes over one job, such as taking orders, while the old one carries on doing everything else. A connection between them keeps both in step, so an order entered in the new app still appears where the old billing screen expects it.

Each part goes live on its own, when it is ready and your team is ready. Then the next part moves across, and the old system does a little less each time, until one day it does nothing at all and can be switched off.

We choose the first part carefully. Usually it is the one that hurts most today, or the one that is easiest to separate, so your team sees the new system working early and the risk stays small.

Data is usually the most valuable thing in an old system, and the messiest. Years of use leave duplicate customers, free-text fields where numbers should be, codes that changed meaning, and records nobody can explain.

We map every old field to its new home, merge duplicates with your team’s help, and convert what needs converting. In Gujarat and across India that often includes text typed years ago in old Gujarati or Hindi fonts that only look right on the original PC; we convert it to standard Unicode, so names and addresses display properly everywhere.

The move is rehearsed several times on copies before the real one. Each time, counts, totals and balances are compared with the old system: the number of customers, the outstanding amounts, the stock in each godown. The real move happens only when a rehearsal comes out clean.

A parallel run is the clearest proof that the new system is right. For a period, both systems do the same work, and the results are compared.

For payroll, that means a full month’s salaries worked out in both and compared payslip by payslip. For billing, the same invoices raised in both, with GST and totals checked line by line. Every difference is traced: sometimes the new system has a bug, and sometimes it reveals a mistake the old one had been making for years.

A parallel run costs effort, because someone enters work twice or checks two sets of figures. We keep it as short as the confidence allows, and we automate the comparison wherever we can. When the results match and your team says so, the old part is switched off.

Some systems stay, and the new one has to fit around them. Tally often remains the accounting system, so invoices, receipts and credit notes flow into it automatically instead of being typed again.

Invoices that need a GST e-invoice get their reference number and QR code through an authorised provider when they are raised, and e-way bills are created from the same record. Payment gateways, bank statements, WhatsApp messages, biometric attendance devices and your website are connected the same way.

Where the old system exchanged files, such as a spreadsheet exported every night, the new one uses proper connections that check what they send and say when something fails, so nothing goes missing quietly.

People trust a new system once they have used it on real work before it matters. We train a few key users first, the ones others ask for help, and they try the new system during the parallel run while the old one is still there to fall back on.

Where it helps, the new system keeps what people liked about the old one: the same order of fields, keyboard shortcuts for fast billing, the printed layouts customers recognise. A short guide for each role, in English, Hindi or Gujarati, covers the daily tasks.

On the day each part switches, we are on hand during your working hours, in India time, to answer questions and fix anything small straight away.

Modernisation has worked when the old system is switched off and nobody misses it. Before we start, we agree what success means for your business: the same results as before, less typing, no double entry, work possible from phones, and changes that no longer take months.

We measure what can be measured, such as the time it takes to raise an invoice or close the month, and how often the same data is entered twice, before and after each part goes live. Your team tells us the rest.

The final checks are simple: every record has moved, every report the business relies on is available in the new system, and the old server and its licences can be retired.

The point of modernising is to never be stuck again. The new system is built on common, well-supported tools, the code is documented, and tests check its rules, so any capable developer can work on it, including your own.

We stay on to support it: fixing issues, applying updates, adapting it to new tax and payment rules, and adding what the old system never could, such as a mobile app for the field team or reports that once took a day to prepare. Each change goes out on its own, checked, so the system keeps improving without ever needing another big replacement.