Why this is a live problem in Gujarat's industrial corridors
Across the chemical estates of Ankleshwar, the plastics and engineering clusters of Vadodara, and the dyes and intermediates units of Vapi, a common story repeats itself. A business invested in a bespoke software system — sometimes custom-built, sometimes an older vendor product — during a period of rapid growth. The system worked. It was shaped around the business's specific processes and the team learned it thoroughly. Over time, the original developers moved on, the vendor stopped supporting the product, and the underlying database or operating system reached end-of-life. The software still runs. It just cannot grow, cannot integrate with newer tools, and sits on hardware that is one failure away from a crisis.
This is not a sign of poor decision-making in the past. It is a normal lifecycle problem, and the question now is not whether to act but how to act without destroying operational continuity.
---
Audit what the old system actually does well
Before any migration conversation begins, the most important exercise is an honest capability audit. Legacy systems that have survived years of daily use have usually earned that survival. They encode business rules — pricing logic, quality hold procedures, dispatch sequencing — that may not be documented anywhere else.
Start by listing every function the system performs and asking three questions about each:
- Is the output still correct? Some modules produce accurate results even on old code. Others have developed quiet errors that staff work around habitually.
- Is there a human workaround in use? If your stores team exports to Excel every morning before beginning work, that is a signal the system is no longer truly serving that function.
- Does the function touch compliance or statutory requirements? GST data, factory act records, CPCB-related documentation — anything in this category carries risk if it lives only in an unsupported system.
The audit often reveals that 60 to 70 per cent of what the legacy system does could be replicated or improved in a modern environment, while a small core — frequently the production scheduling or costing logic — is genuinely sophisticated and needs to be understood deeply before it is rebuilt.
---
The real risks of an unsupported stack
Plant heads and finance leads often frame legacy risk as primarily a technology problem. It is more accurately a business continuity and compliance problem.
Operating system and database end-of-life
When the underlying OS or database falls out of vendor support, security patches stop. In a connected industrial environment — where machines, ERP and logistics portals are increasingly networked — an unpatched system is an open door. A ransomware incident in a chemical or pharmaceutical plant does not just cost data recovery time; it can halt production for days and trigger regulatory scrutiny.
Vendor and developer dependency
If the software was built by a small vendor or an in-house team that has since dispersed, there may be no one who can fix a critical bug when it surfaces. One corrupted master record, one failed upgrade, and the system may become unreadable. This is not a hypothetical — it is a documented pattern across industrial businesses that delayed modernisation decisions.
Integration failure
Modern business requires your system to speak to e-way bill portals, bank APIs for automated reconciliation, customer portals, and supplier systems. Legacy software built before these ecosystems existed cannot connect without fragile, manually maintained bridges. Every such bridge is a point of failure.
Talent scarcity
Finding developers who understand a proprietary 1990s or early 2000s system architecture is increasingly difficult. When the one person who knows the system leaves, the knowledge leaves with them.
---
Strangler-fig migration versus full replacement
The two main approaches to modernisation are full replacement and incremental strangler-style migration. Each suits different situations.
Full replacement
This means switching off the old system on a defined date and going live on a new platform. It is faster in calendar terms and avoids the complexity of running two systems. It is also higher risk. For a manufacturer with continuous production — a dyes plant in Vapi running round-the-clock shifts, for example — a failed go-live has immediate, measurable consequences. Full replacement suits businesses where the legacy system is genuinely broken or where the business is small enough that parallel complexity outweighs the risk.
Strangler-fig migration
This approach, named for the tree that grows around an existing structure, involves building new capability module by module alongside the old system, gradually shifting traffic to the new environment until the old system is no longer needed and can be decommissioned. A typical sequence for a manufacturing business might be:
- Replace financial reporting and GST compliance first — lowest operational risk, highest compliance benefit
- Move inventory and stores management next — visible, testable, and with clear reconciliation points
- Migrate production planning and costing — the most complex and critical, done last when the team is familiar with the new environment
The strangler approach reduces the risk of a catastrophic failure but extends the project timeline and requires discipline to avoid leaving the organisation permanently stranded between two systems. Setting a hard decommission date for each legacy module is essential.
For businesses considering this kind of phased architecture work, custom software development services that can bridge old and new environments are worth discussing early, since the integration layer between the two systems is where many migration projects run into trouble.
---
Data migration: the unglamorous core of the project
Data migration is where modernisation projects most commonly underestimate effort and overestimate readiness. The ERP data migration playbook covers the mechanics in detail, but the strategic points for legacy systems specifically are worth stating here.
Legacy databases frequently contain:
- Duplicate master records created when the original system lacked validation rules
- Obsolete items and accounts that were never formally closed and now clutter every report
- Encoded business logic in field values — a two-character code in a customer record that staff know means "hold for director approval" but which is not documented anywhere
- Historical data in formats no longer used — financial years that do not align with current practice, unit-of-measure inconsistencies across plant locations
Cleaning this data before migration is not optional. Loading dirty data into a new system does not modernise the business; it imports the legacy problems into a new environment.
Plan for at least two full trial migrations before the cutover migration. Each trial reveals a new category of exceptions. Build the timeline accordingly.
---
Parallel running: managing the overlap period
Parallel running — operating both the legacy and new systems simultaneously for a defined period — is the standard risk mitigation for high-stakes migrations. It is also operationally demanding and should be treated as such.
During parallel running, every transaction needs to be entered or reflected in both systems. That doubles the workload for the teams involved. In a busy accounts or stores department in an industrial unit, this is not a trivial ask.
To manage it:
- Set a fixed parallel period — typically four to eight weeks depending on business complexity — and communicate it clearly so teams know it is temporary
- Assign a reconciliation owner whose sole job during the period is to compare outputs from both systems daily and flag discrepancies
- Define the criteria for cutover in advance: what level of reconciliation accuracy signals that the new system can be trusted as the system of record?
- Plan the legacy shutdown — do not let it drift. A system that stays nominally live "just in case" for months after cutover creates confusion and prevents the team from fully committing to the new environment
For manufacturers in the Vadodara manufacturing corridor, where shift patterns and plant operations do not pause for IT projects, having a clear operational plan for the parallel period is as important as the technical migration plan.
---
Keeping operations live through the transition
The non-negotiable constraint for any industrial business is that production, dispatch and compliance cannot stop. A few practices that consistently reduce disruption:
Avoid migration during peak periods. For chemical manufacturers, the period around financial year close or ahead of major export shipments is not the time to be cutting over to a new system. Build the migration calendar around operational realities, not IT convenience.
Train on real data. User acceptance testing done on fabricated data teaches staff the software but not their job. Testing on a copy of the actual business data — with real customer names, real part numbers, real open orders — surfaces issues that generic testing misses.
Create a rollback trigger. Before go-live, define the conditions under which you would rollback to the legacy system. Knowing that there is a clear, agreed reversal path reduces anxiety and actually makes teams more willing to commit to the cutover.
Do not underestimate the human side. Staff who have used a system for years have deep muscle memory. The frustration of a new interface, even a better one, is real. Structured training, superuser networks, and visible management commitment all reduce the resistance that causes migration projects to stall.
---
The role of specialist guidance
Modernisation projects that stall or fail most often do so because the business tried to manage both the technical migration and the internal change management using internal resources alone — resources that already have day jobs running a plant or managing accounts. External ERP consulting support is most valuable not in selecting software (which the business can often do) but in structuring the migration, managing the data preparation, and holding the parallel running process to a timeline.
The goal is not to outsource the decision-making. The goal is to bring in structured experience so that the project moves at a pace the business can sustain without losing operational control.
---
Start the assessment before the crisis does
The worst time to begin a legacy modernisation is after the system has failed, the developer cannot be reached, and the plant is waiting on manual workarounds. If your current system is unsupported, undocumented or increasingly bridged by spreadsheets, the assessment work can and should begin now — not as a procurement exercise but as a risk management one.
If you would like to talk through where your current setup sits on this curve, start a conversation with our team. We are based in Surat and work with industrial businesses across Gujarat on exactly these transitions.