An old records system rebuilt piece by piece

The challenge

What was going wrong

1. 1

   Understand what exists

   We read the old code, mapped its data and interviewed registrars about how they really used it. This showed which features mattered and which were unused.

2. 2

   Plan safe slices

   We split the system into parts and ranked them by risk and value. A new interface sat in front, so users never saw which parts were old or new.

3. 3

   Rebuild and test

   We rebuilt each part as its own service and wrote automated tests that compared old and new results on the same data before anything went live.

4. 4

   Switch over gradually

   We moved one module at a time, watched closely after each switch, and kept a clear way back until the team was fully confident.

• Stable API layer

  One interface sits in front, so apps work the same during the migration.

• Modular services

  Enrollment, grades and timetables are now separate and can change independently.

• Automated regression tests

  Tests compare new results with the old system on real scenarios.

• Clean data migration

  Student records were checked, cleaned and moved with full audit trails.

• Enrollment never stopped

  Staff and students used the system as normal while parts were replaced behind the scenes.

• Changes are safe again

  Developers can update one module without fear of breaking unrelated features.

• Reports on demand

  Registrars get the reports they need without waiting for manual preparation.

• Java Proven language for large, long-lived enterprise systems.
• Spring Boot Java framework for dependable enterprise back ends.
• PostgreSQL Dependable database for complex business data.
• Docker Packages software so it runs the same everywhere.
• React Component-based user interfaces for web apps.
• Jenkins Runs automated builds, tests and releases on every change.