Legacy Modernization & Cloud Migration

Move on from systems that hold you back.

Monday morning still has to work

Legacy modernisation is not a cloud sticker on a server you are afraid to reboot. It is a plan for the Monday after cutover: invoices still print, yesterday’s orders are findable, GST is not a scavenger hunt, and the person who knows the old shortcut is not the only one who can close the day. If a proposal cannot describe that Monday, it is a migration slide, not a project.

LavisTech works in India with SMEs whose systems are a mix of a desktop package, a custom tool someone wrote years ago, Tally, Excel, and a shared folder that has become the archive. We replace or re-host what we can reach. We do not promise a greenfield rebuild of the whole firm in a quarter. Continuity is the product. New screens are how you get it — when they are the right screens.

Unsupported is a risk, not a mood

Unsupported means the runtime is out of support, the vendor is gone, the only executable sits on a machine with a failing disk, or the person who understood the FoxPro tables has left. It does not mean “the UI looks old”. Ugly software that still posts correctly can wait. Software you cannot restore after a crash cannot.

We start with restore, not with a redesign. Can you build a new machine and open last month’s data? Is there a backup that has been tested, not only scheduled? Is the licence a dongle that nobody can replace? Those answers change the first sprint. A re-platform onto Azure of an application you cannot compile is a different job from lifting a supported app whose database you already understand.

If the honest answer is “we have never restored”, that restore is part of discovery. Skipping it to save two weeks is how you discover the backup is empty on the weekend you chose for go-live.

Re-platform, rewrite, or leave it

Three options, said in the first fortnight, not after a year of workshops.

• Leave it. The package still does the job, you can restore it, and the pain is a report someone exports to Excel. Fix the report. Do not boil the ocean.
• Re-platform. Same application, or close to it, on a host you can patch and back up — often Azure for the firms we see — with the same users and a better story for disaster recovery. You change where it lives and how you operate it, not what it is.
• Rewrite. One workflow at a time, usually, in something you can hire for — we are a .NET shop when that is the fit. You change the thing. That is longer, and it only pays when the old system cannot take the next change you actually need.

Vendors blur re-platform and rewrite because “cloud transformation” sells. Ask what happens to the night shift’s screen. If the answer is “they get a new portal in phase one”, you are hearing a rewrite. If the answer is “same app, we host it, we can restore it, then we peel off one painful job”, you are hearing a sequence we will sign.

A full rewrite of “everything Tally does” is almost never the first move. Tally stays, often, while you replace the custom island around it. See what custom ERP is when the island has become the real business system. Buying a new ERP logo and hoping history appears is not modernisation. It is a second set of books.

Azure is a place, not a personality

We host on Azure when the account, the region, and the operations story make sense for an Indian SME: backups you can name, identities you already use, a bill someone in the firm will actually read. We will not move you because a slide said “cloud native”. A small VM you can restore, plus a database backup you have tested, beats a dozen services nobody can explain when something fails at 7 a.m.

Cloud cost is operational, not a one-time project fee. Idle environments, forgotten test machines, and chatty integrations show up on the invoice. We will write down what we intend to run and who watches the bill. We will not invent a rupee forecast for three years of “digital”. If you need AWS instead because that is already where a sister company lives, say so. The discipline is the same. The click-ops are not the project.

What we refuse: lifting an unpatched desktop into a VM and calling it done, with RDP open to the world and the same single password on a sticky note. That is the old risk with a new hostname. Hardening, identity, and a restore test belong in the same statement of work as the move.

Data migration is a separate job

Moving history is not a side effect of buying new screens. Opening balances, item codes, customer names with three spellings, GST invoices you must still show, the order from last Thursday — that work has its own mapping, its own parallel run, and its own definition of done. We sell it as data migration, even when the same people are on the modernisation. Mixing the two in one line item is how “go-live” means empty dropdowns on Monday.

Yesterday’s orders must be findable on day one if staff will take a call about them. That sentence belongs in the plan. If you can live with history in read-only archive and only open jobs in the new system, say so — that is a smaller migrate. If finance needs five years searchable for a notice, that is a larger one. Do not discover the difference in week twelve.

Excel is often the real master. Deduping “ABC Traders”, “A.B.C. Traders”, and a GSTIN that almost matches is not a weekend script. It is decisions. We will put those decisions in front of a person who owns the customer list. We will not silently pick a winner and hope the dispatch team agrees.

How we keep Monday boring

Parallel run: the old path and the new path agree on the numbers that matter until someone finance trusts will sign. Cutover: a written window, a rollback that has been said out loud, and a list of who is in the room. Hypercare: the first days are not “warranty silence”; they are named hours when exceptions have a face. Training: the people who work the job, not a PDF in a drive named handover.

1. Discovery. What must run on Monday, what can wait, what you can restore today, which integrations are real (Tally, a weighbridge, a website) and which are myths.
2. Access and backup. Source code if it exists, database if you can, a tested restore. If you cannot, that is the work.
3. Target. Re-platform sketch or first-slice rewrite, hosting, identity, how you will watch it.
4. Migrate the slice you need for day one, under the migration job, with checks staff can read.
5. Cutover and the first two weeks of counts. Dispatches in the system versus WhatsApp. Invoices that match. Searches that find last week.

The night shift is allowed to refuse a slower screen. That is data. If they still close the job on the old desktop after two weeks, you have learned something: wrong slice, missing undo, or an incentive you did not see. Adding modules will not fix a failed assumption. That is how a nine-month rewrite starts by accident.

Time bands

Scope	Typical time	What “done” means
Discovery and options paper	2 to 4 weeks	Leave / re-platform / rewrite, with Monday named
Re-platform of an app you can build and restore	6 to 16 weeks	Hosted, backed up, users on, old box not the only copy
Rewrite of one workflow	8 to 16 weeks for the first live slice	Staff complete that job without you in the room
History move	Its own plan — see data migration	Agreed records findable; parallel checks signed

What stretches the calendar is not “Azure”. It is a proprietary file, a vendor who will not give an export, a GSTIN list that has never been cleaned, or three directors who have not agreed whether Tally stays. We will write the systems that stay as a heading, not a footnote. It stops a build team treating the office as empty land, and it stops a director hearing “new system” as “we switch Tally off in July”.

If you need a calm look at vendors and sequence before anyone lifts a server, that is IT systems consulting. If you already know the box is dying and the first workflow you must keep, we can go straighter to a build. Do not buy consulting you do not need. Do not skip it when nobody can draw Monday.

AI on a system you cannot reach

People ask in the same meeting whether we can “add AI” to the old package. If there is no API and no way to add a button, the answer is modernise first, then a narrow feature. The how-to lives with AI work; the blocker lives here. A chatbot that cannot see last Thursday’s order is a toy. After the application can accept a button and the records are reachable, AI integration is a later, smaller statement of work. Mixing them so the quote looks visionary is how you pay agent rates for a restore you still have not done.

What we will not do

We will not invent a client who “moved to the cloud in twelve weeks” with no parallel run. We will not lift-and-shift RDP to the internet and call it architecture. We will not rewrite Tally because a salesperson wants a friendlier invoice screen. We will not migrate “all history” without you choosing what all means. We will not cut over on a festival week because the licence expires the same Friday — unless you accept the risk in writing and staff are actually available.

We will not hide Excel as if it were a moral failing. It is often the system of record. Naming it is how you migrate it, or how you leave it on purpose. Shame is not a strategy.

A briefing that is enough

Write: what must work on the first Monday; what can wait a month; whether you have ever restored; which systems stay; who owns exceptions; what you will count after two weeks (findable orders, matching invoices, jobs closed in the new screen). Attach one real export — a messy item list, a week of the chat group, a redacted invoice. Send that through contact.

If we cannot reach the data, the first quote is access and discovery, not a rewrite. If we can, we will say re-platform or first slice, and we will price migration on its own line. That split is how you still have a business on Monday, instead of a new URL and a quiet office that went back to the old machine under the desk.