Context
The client is a group of private colleges and a university in southern India. Admissions, fee collection, student records, examinations and hostel management all ran on an ERP built in-house fifteen years earlier in PHP, extended by a succession of developers, most of whom had moved on. It worked, in the sense that the institution ran on it every day. It also ran on an unsupported PHP version, on a server nobody wanted to touch, with no API, thousands of lines of undocumented business logic, and a reporting process that meant a request to the IT team and a wait of days.
Two vendors had proposed a full rewrite on a commercial platform: two years, a large budget and a migration risk the registrar was not willing to take during a period of growing enrolment. The group also wanted to use AI for the document-heavy admissions process and to give administrators self-serve reporting, and neither was possible on the existing system.
The problem to solve
Modernise the ERP to a supported, secure stack, expose it through an API so new capabilities could be built around it, add AI where it removed manual work, and do all of it without stopping admissions, examinations or fee collection. The academic calendar set the constraints: no changes to examinations during exam periods, no changes to fees during collection windows, no downtime in the admissions season.
Approach
We began with a two-week Sprint Zero assessment rather than a proposal. It produced a map of the system: the modules, their dependencies, the database tables nobody was sure were still used, the cron jobs that turned out to be critical, and a risk-and-effort rating for each part. The recommendation was a strangler programme in four phases, keeping the database as the stable core, wrapping the legacy application with an API façade, and replacing modules one at a time behind it, with the PHP runtime upgraded in place once test coverage existed.
- Characterisation tests written against the live system's behaviour before any change, so refactoring could be checked against what the system actually did rather than what anyone thought it did.
- An API façade in Node.js over the legacy database and application, giving every module a clean interface and making the order of replacement a choice rather than a constraint.
- PHP 5 to PHP 8 migration in a slice-by-slice cutover with the characterisation tests as the gate, scheduled around the academic calendar.
- Admissions module rebuilt in React on the façade, with an AI document pipeline that reads application documents and mark sheets, extracts fields with confidence scores and queues exceptions for staff.
- A natural-language reporting layer with a semantic model over the student, fee and examination data, read-only, with row-level security by role, replacing the request-to-IT process.
- AI-assisted regeneration of documentation for the modules that were kept, reviewed by the group's IT lead.
What we built
Phase one delivered the characterisation tests, the façade and the runtime migration for the lowest-risk modules, hostel and library, during a term break. Phase two migrated fees and records with the tests as the safety net, timed between collection windows. Phase three rebuilt admissions on the new stack with the document pipeline, launched ahead of the admissions season and run in parallel with the old process for the first fortnight. Phase four added the reporting layer and completed the runtime migration for examinations after the exam period.
The group's IT team paired with ours throughout, because the explicit goal was that they would own the system afterwards. Every module carries regenerated documentation, every deployment is scripted, and the façade means the next module to be replaced can be replaced by whoever the group chooses.
Delivery
Sixteen weeks across four phases, each with a business sign-off before cutover and a rollback plan tested in staging. The characterisation tests caught a fee calculation quirk that had existed for years and that the finance office had been correcting by hand; it was fixed, with their agreement, in the migrated module. There was no term-time downtime. The admissions parallel run found one document type, a state board mark sheet with a non-standard layout, that the pipeline could not read reliably; it is routed to staff by design.
Outcomes
The ERP runs on a supported stack on infrastructure the IT team can rebuild, with test coverage where there was none and documentation where there was folklore. Admissions staff review pre-filled applications rather than typing them, and the exception queue tells them where to look. Administrators ask the reporting layer questions in plain language and get answers in seconds, within their role's permissions, and the IT team's report-request backlog has largely disappeared. The group has since added a parent-facing portal on the façade, built by their own team.
What we measured
- Modules migrated per phase against plan
- Term-time downtime: zero
- Characterisation test coverage of kept modules
- Admissions applications processed without full manual entry
- Report requests to IT before and after the reporting layer
- Infrastructure and support cost after migration
Architecture in brief
The database remained the stable core throughout; nothing else was allowed to become a second source of truth. The Node.js façade exposes each module as a versioned API and, during the programme, routed each call either to the legacy PHP application or to its replacement depending on a per-module switch, which is what made every cutover reversible in minutes. New modules are React applications on the façade, with the document pipeline and the reporting layer as separate services beside it. The reporting layer's semantic model defines the group's metrics once, in plain language the registrar's office maintains, and every query is validated and executed read-only under the requesting user's role.
The migrated runtime, the façade and the new services are all defined in infrastructure-as-code and deploy through a pipeline the group's IT team runs. The characterisation tests run on every deployment, and the group has added tests of its own for the parent portal.
What we learned
Writing tests against the system's real behaviour before touching it was the decision that made the rest safe. The façade was the second: it turned a monolith into a set of choices about what to replace next, and it is what let the group's own team build the parent portal without us. And scheduling around the academic calendar, which looked like a constraint, gave every phase a natural deadline and a natural rehearsal window.
The group is on a Standard Care Plan, and we review the next module to replace with their IT lead each quarter.
"Two vendors told us to throw the system away and start again, which would have taken two years we did not have. Eazyware told us which parts to keep, and then kept them running while everything around them changed."
Client details are anonymised. Figures are described qualitatively and are available under NDA on a call.