Legacy System Migration Services Without Downtime

Your finance team still exports GST data from a system nobody wants to log into, and one contractor holds the only working knowledge of how it talks to your warehouse. Migrating it is not really the risk — the risk is a cutover that quietly duplicates 400 invoices and breaks month-end. This is a migration path built around production staying up.

What legacy system migration services actually cover

Legacy system migration services cover five jobs, and most proposals only price one of them: discovery, data migration, integration rewiring, cutover and decommissioning. Discovery is an inventory of every scheduled job, inbound file, hardcoded IP and licence dependency the old system relies on — skip it and you meet all of them at 2am on go-live. Data migration is schema mapping plus the awkward 1-2% of rows that violate the new constraints: blank GSTINs, duplicate customer codes, free-text addresses. Integration rewiring replaces CSV drops and point-to-point FTP jobs with something you can actually monitor. Cutover is the night itself. Decommissioning is the part that saves you the licence and the server. Ask for the discovery inventory in week one; if a vendor cannot produce it, they are estimating, not planning.

Why migrations break production

Migrations almost never break because the new code is wrong — they break at the seams between old and new. The three failure modes we see most often are dual writes, where both systems accept changes and neither reconciles, so order statuses drift apart within hours; scheduled jobs running under a service account nobody owns, firing twice, once old and once new; and permission mapping, where a migrated user ends up seeing cost prices or another region's data. A fourth, quieter one is volume: staging holds 5,000 rows, production holds 40 lakh, and the batch that took 40 seconds now takes 40 minutes. None of this shows up in unit tests. It shows up in reconciliation reports, which is exactly why you run those before any write path moves.

A migration path that will not break production

The path that works is shadow mode first, strangler fig second: keep the legacy system as the source of truth while the new one reads the same data and writes to its own tables, then compare continuously. You move one seam at a time — reports and read-only lookups first, then low-risk writes, then money. Every write path gets an idempotency key so a retried request cannot create a duplicate invoice. Feature flags let you switch a single module back to the old system without a deploy or a rollback. Expect mismatches: a 0.3-0.5% difference on the first comparison run is normal and usually traces to formatting, casing or two legacy overrides someone forgot about. We map these seams before writing any new code, and the approach is written up in our integration architecture notes.

Cutover day: the checklist that keeps you safe

Cutover is a rehearsal, not an event — if you have not run it twice on production-shaped data, you are not ready to run it for real. The list that keeps our cutovers boring:

• Freeze writes at a stated time, and tell ops, finance and support a week ahead rather than an hour ahead.
• Take a full database snapshot and a file-level backup of the legacy app server, then restore it somewhere and prove the restore works.
• Reconcile three numbers before reopening writes: record counts, invoice totals and open order values.
• Keep the legacy system read-only for two to four weeks. Read-only is cheap; deleted is not.
• Name one person who can call a rollback, and define the trigger numerically — more than 1% order failures in the first hour, for example.
• Watch scheduled jobs for 48 hours. Duplicate invoices usually surface there first.

In our experience, most rollbacks get called because nobody agreed in advance what "working" looks like, not because the new system was broken.

What it costs and how long it takes

Discovery and the shadow-mode build typically run 2-6 weeks before a single write path moves; a module-by-module migration usually finishes in 3-6 months. A representative shape: a B2B distributor with roughly 40,000 SKUs and 900 orders a day, running an old ERP alongside Tally and a homegrown CRM. Three weeks of discovery surfaced 11 scheduled jobs and four integrations nobody had documented. Five weeks of shadow reads compared about 60,000 orders and settled at 0.4% mismatch, all traced to GSTIN casing, trailing spaces in customer codes and two price-list overrides. Go-live went module by module across four weekends. That scope typically lands in the ₹8-40 lakh range depending on how many integrations need rewiring, though it varies widely, and it excludes the cost of running both systems in parallel. Keeping the legacy box alive in read-only mode needs somewhere to live — see servers if you would rather not keep it on the office rack.

Two Indian details change scope more than people expect. GST invoice and return data usually has to be retained for years, so the legacy database gets archived rather than deleted. And consent records under the DPDP Act have to map to new user IDs, or you lose the audit trail for the customers you migrated.

Where to start

Start with an inventory, not a codebase. Spend week one listing every integration, scheduled job, report and licence the legacy system touches, then rank modules by blast radius — money first, cosmetics last. Pick one module, run it in shadow mode, and measure the mismatch rate before you commit to a date. If you want a second pair of eyes on that inventory, Maysan Labs builds migration paths and the dashboards that watch them; the useful output is a cutover plan you can argue with, not a slide deck.