Back to all case studies

From Chaos to Control: Stabilising a 30-Year Legacy ERP Without Rewriting It

Snapshot

A mid-sized German ERP software manufacturer with a 30-year-old codebase (Visual Basic 6, .NET 3.5, InterSystems Caché) operating without version control, automated testing, or individual development environments. All developers worked simultaneously in a shared source directory on a single terminal server—management believed this prevented IP theft. Service cases exceeded 20 per day; deployments were trial-and-error exercises; Windows updates routinely broke the development environment.

Delivery model: Principal-led engagement (Stefan, Founder & Principal Consultant) Client: Ironbridge ERP (German ERP vendor for equipment trade and rental)

The Challenge

The product worked—customers valued its features—but instability was driving everyone to breaking point. Developers shouted across the office hunting for whoever "broke" the system. Regression was constant but untraceable. The gap between development and release branches spanned thousands of unexplained lines of code. Customer deployments had no scripted installers; technicians fought through errors on-site until the system booted. Post-deployment service spikes lasted weeks.

The development environment itself was fragile: orphaned ActiveX components, undocumented internal libraries, and dependencies no one could reproduce. Every Windows update triggered days of trial-and-error reinstallations. The Sales Director—who led software development despite no technical background—resisted change. Long-tenured developers were hostile to object-oriented programming and unwilling to learn. Projects were implemented as isolated, customer-specific code with zero reusable abstraction.

Constraints

Political: The Sales Director financially benefited from selling "individual programming" and viewed abstraction as a threat to revenue and control.

Cultural: Legacy developers rejected new tooling and modern practices; management equated the terminal server model with IP protection.

Technical: A ~30-year codebase touched by countless developers, with no documentation of how custom tooling (code generators, protocols) functioned. The system could no longer be installed on a fresh machine.

Operational: The team was under extreme pressure—20+ daily service cases, toxic morale, and customer frustration at breaking point.

Approach

1. Map the Mess Documented the current state: which systems existed, how they interacted, what dependencies were present. This became the foundation for all subsequent work.

2. Introduce Version Control (Git) Placed Visual Basic, C#, and Caché components under Git. Automated daily exports from the Caché server to create snapshots of backend changes. This ended the "manhunt" culture and made regression traceable for the first time.

3. Separate the Branches Enforced strict separation: Unstable Development, Testing, Release. Developers stopped manually copying code line-by-line into a "release branch" whose divergence from development no one could explain.

4. Build Individual Development Environments Ended the shared terminal server model. Each developer received a local workstation with their own environment. Pull requests and merging replaced chaotic simultaneous edits to shared directories. This required intensive negotiation with management, who feared IP theft—Vionix demonstrated that copy-paste made terminal servers irrelevant for that purpose.

5. Automate and Stabilize Installations Bundled all components (including legacy ActiveX dependencies) into a single scripted installer. Created a comprehensive manifest file for the VB6 application and automated its generation, making the system self-healing when dependencies changed. Configured legacy components to run reliably on modern Windows.

6. Train and Adapt Gradually Conducted recurring training sessions: Git workflows, SOLID principles, software architecture, abstraction techniques. Used real projects as examples for example extracting a reusable CSV export class rather than reimplementing it per customer. Gave developers time between changes to adapt.

7. Restructure Team Dynamics Created mixed teams: technically proficient developers built abstractions (objects, reusable modules); legacy developers consumed them in their imperative code. This approach preserved existing skills while introducing modern patterns, built trust, and transformed isolated work into collaboration.

What Was Delivered

• Version-controlled codebase (Git) with automated daily snapshots of Caché backend changes
• Branch strategy enforcing separation between unstable development, testing, and release
• Individual local development environments replacing the shared terminal server
• Automated installer with dependency resolution and self-healing manifest generation
• Training curriculum covering Git, architecture principles, and practical abstraction techniques
• Reorganized team structure enabling collaboration between old-guard and modern-skilled developers

Results

Service Case Resolution Time: Reduced from days to hours. Version control enabled side-by-side code comparison instead of manual archaeology through thousands of lines.

Deployment Stability: Customer IT departments no longer feared Windows updates or version upgrades. Scripted installers eliminated trial-and-error on-site troubleshooting.

Traceability: The company could now prove whether issues stemmed from code changes or user error—previously impossible. Management valued this transparency highly.

Developer Morale: Stress levels dropped significantly. Developers had their own environments, understood their tooling, and stopped being blamed for untraceable regressions.

Service Case Nature: While total volume didn't immediately drop, the character shifted—user errors could be definitively identified, and regression-driven cases became resolvable quickly.

Why It Worked

Vionix didn't fight the legacy—Vionix stabilized it first. Version control and environment isolation created accountability and psychological safety before asking anyone to change how they coded.

Political resistance was addressed with economic logic. The terminal server argument collapsed once Vionix demonstrated that copy-paste made it irrelevant for IP protection. The Sales Director's resistance was bypassed by delivering results that management and customers valued.

Vionix met developers where they were. Rather than forcing OOP adoption, Vionix let technically proficient team members create abstractions while legacy developers consumed them imperatively. This built trust through demonstrated value, not ideology.

Automation removed fragility. The self-healing manifest and scripted installer eliminated the Windows update panic cycle, freeing cognitive space for improvement.

How Vionix Worked

This was a two-year engagement with a single Vionix consultant embedded in an advisory and active restructuring role. Changes were implemented gradually with training periods in between, allowing the team to internalize each shift before the next. The engagement concluded amicably when the company was acquired by a larger corporation capable of sustaining the systems independently.