Legacy ERP Modernisation — Migrating 10 Years of Business Logic

The Problem

At a large manufacturing firm, the ERP system had been the backbone of operations for a decade. It started as a standard SAP implementation but had been customised relentlessly — 200+ custom reports, dozens of bespoke workflows, and business logic embedded in stored procedures that nobody fully understood. The original implementation team had long since left, and documentation was essentially nonexistent.

The system was creaking. Performance had degraded to the point where month-end closing took 14 hours. The on-premise infrastructure was expensive to maintain and approaching end-of-life. Integration with newer systems required brittle file-based data exchanges. But the scariest part was the risk: critical business rules lived in undocumented stored procedures, and nobody could confidently say what would break if anything changed.

Leadership wanted to move to the cloud, but a big-bang migration was out of the question. The business could not afford downtime, and the risk of losing embedded logic was too high.

What I Did

I structured the modernisation in three phases: understand, abstract, and migrate.

In the understand phase, I assembled a small team of analysts and developers to reverse-engineer the business logic. We traced every custom report back to its source queries, mapped stored procedures to business processes, and documented decision rules by interviewing the finance and operations teams who used the system daily. Over eight weeks, we built a comprehensive catalogue of 340 business rules, classified by criticality and module.

In the abstract phase, we built an API facade over the legacy ERP. Instead of other systems connecting directly to the database or file exports, they connected through a RESTful API layer that encapsulated the legacy system. This was critical — it meant we could swap out the backend module by module without downstream systems noticing.

In the migrate phase, we moved modules incrementally to cloud-native microservices. We started with the least critical modules — reporting and analytics — and progressed to inventory management and order processing. Each module was rebuilt using the documented business rules, tested against the legacy system's outputs for validation, and then switched over behind the API facade.

I ran the entire programme with a parallel-run strategy. Both old and new systems processed the same transactions, and we compared outputs until we had confidence in the new implementation.

The Outcome

Within six months, 60% of the business logic was running on cloud-native services. API response times improved by 5x — queries that took 8 seconds in the legacy system returned in under 2 seconds. Month-end closing dropped from 14 hours to 3 hours.

Operating costs decreased by 35% as we decommissioned on-premise infrastructure and reduced licensing fees. The remaining 40% of business logic was migrated over the following two quarters, and the legacy ERP was fully decommissioned within 14 months. The API facade pattern we established became the standard approach for all subsequent system modernisations in the organisation.