From Legacy PHP to an AI-Powered ERP: How We Transformed an Education Platform in Just 4 Weeks

The problem: a system that worked, but could not carry on

Old software rarely breaks all at once. It just gets harder to live with. Here is what that looked like day to day.

The technology behind it had stopped being supported

Programming languages are looked after for a set number of years. After that date, the people who maintain them stop sending out safety updates — including fixes for new problems found later. The version this platform ran on had passed that point some time ago.

That matters here more than it would elsewhere. The system holds student records, parent contact details and payment information. Keeping that kind of information on software that can no longer be patched is a risk that grows quietly every month.

People were doing work the software should have done

Wherever the system did not reach, a person reached instead. Attendance was written on paper and typed in afterwards. Fee reminders were written and sent one at a time. Report cards were put together in spreadsheets, from marks that were already stored in the system. Management reports were rebuilt from scratch at the end of every month.

That was nobody's fault. It is what happens when software stops growing and the institution around it keeps going.

Nobody could reach it from a phone

The system only worked on a computer, which in practice put it out of reach of most of the people who needed it. Parents do not sit at a desk to check whether a fee has cleared. Students do not open a laptop to find out which room a class has moved to. Teachers do not want to walk back to the office to mark attendance.

What they asked for?

The request was unusually clear, and that clarity is what made everything else possible.

• Keep every record. Years of student, fee, attendance and exam history had to come across complete.
• Keep every rule. Fee amounts, discounts, attendance rules, grading rules, including all the unusual cases built up over the years.
• Keep the parts the staff already knew. No retraining the office on something that works differently for no good reason.
• Replace what it sits on. New software, current technology, and a structure that can be changed safely.
• Do not go offline. An institution cannot lose a week of attendance, fees or results.

That last point shaped everything. We were not replacing the system. We were replacing what the system was built on, while it carried on running.

Why four weeks was possible?

Four weeks sounds unlikely, and it would be, if we had been designing a system from nothing. We were not. Five things were true at the start of this project that are not true of most projects.

They already knew what the system had to do

The platform had been running for years. Nobody had to work out what it should do, hold meetings to agree it, or write it all down from interviews. The working system was the plan, and everyone who used it had already tested it.

The way they worked was already proven

Every rule and every unusual case was visible — in the software, in the records, and in how the staff actually worked. When a fee calculation had an odd step in it, we could see the step and ask why, instead of finding out six weeks later that we had missed it.

Their information was already organised

We did not design a student record or a fee record from scratch. We read what was already there, kept what worked and tidied up the rest. Understanding how information is arranged takes days. Designing an arrangement that survives real use takes a great deal longer.

Our team had done this before

Our engineers have rebuilt systems like this many times. That matters less for the typing and more for the decisions: which parts to take first, where moving information usually goes wrong, which bits of old software are holding everything up and which only look that way. Those decisions were quick because they had been made before.

We agreed the list and did not add to it

The goal was everything the old system already did, not a wish list. Good ideas that came up along the way were written down for later instead of being added halfway through. Projects run late because the list grows, not because the work is slow.

What we actually changed underneath?

"Code rescue" is an easy phrase to use loosely. Here is exactly what it meant on this project.

What was wrong with the old software

• It was no longer supported. No safety updates were arriving, and none were coming.
• The rules were scattered. The instructions that worked out a fee sat inside the same page that displayed it. So the same rule existed in several places and had to be changed in all of them.
• Nothing else could read it. The information was locked inside the screens that showed it. That is why there were no mobile apps, and why nothing else could be connected to it.
• Changes were risky. There was no quick way to check that a change had not broken something elsewhere, so every change meant re-testing things by hand.
• The records had grown rather than been planned. Fields added over the years, names that did not match, and searches that took longer than they should.

What we rebuilt

• The software itself, part by part. Each part was written again on the new technology and compared against the old one before we called it finished.
• The screens and how people move through them. Faster and clearer, but deliberately familiar, the staff did not have to relearn their jobs.
• The way the information is organised. Same information, tidier shape: names that match, proper links between records, and searches that return quickly.
• The reports. They now read current figures instead of being put together by hand.
• Who is allowed to see what. Rebuilt as one clear set of rules rather than separate checks repeated on each screen.

The one new thing that made everything else possible

The most important addition is also the least visible: a single shared connection point.

Think of it as one door into the records that every app has to use. Before, each screen reached in and took what it wanted. Now every app, the office system, the three mobile apps, the learning area, the AI assistant, asks the same place for information, and the same rules decide who is allowed to see what.

This is why the apps, the learning area and the assistant could all be added afterwards without touching the main system again. It is also why the institution can add the next thing without coming back to us to redo the middle.

How we made sure nothing was lost

• Every part compared against the old one. Nothing was approved until the new version gave the same result as the old version for the same input, including the awkward cases.
• Information checked at both ends. We counted and compared records on both sides rather than simply declaring the move complete.
• Old and new running side by side. Both systems ran together before the switch, so the institution was never without a working one.
• Staff walked through it before go-live. The people who use it every day are the best test of whether anything is missing.

[FILL IN BEFORE PUBLISHING] Replace this line with one plain sentence naming the technology, for example: "The new system is built on [framework], with [mobile framework] for the apps and [database] holding the records."

The four weeks, week by week

To be completely clear, because this is the part most often misread: the four weeks was for the main system. The mobile apps, the learning area and the AI assistant were delivered in a later stage, once the main system was live and settled. They are part of the same project, but not part of the same four weeks.

The three mobile apps

This is the part that turned a rebuilt system into something the whole community could actually use. We built three apps, one for each group, because the three groups want very different things, and one app trying to serve all of them serves none of them well.

The student app

Students want short answers fast: today's timetable and any room change, assignment deadlines and submissions, marks and results, course material, their attendance record, fee balance and receipts, and notices that affect them.

The parent app

Parents ask the most questions, and usually outside office hours. The app gives them fee balance and payment, receipts and payment history, their own child's attendance, marks and progress, notices from the institution, and a way to raise a question with staff. Everything is limited to their own child, a parent cannot see another family's records, because the request itself only ever asks for theirs.

The teacher app

For teachers the app is a shortcut through the admin: class lists, marking attendance in class instead of on paper, entering and checking marks, uploading course material, timetable and cover duties, and student contact history.

How the apps stay in step with the office?

All three apps use that same shared connection as the office system. A fee paid in the parent app appears in the office straight away. Attendance marked on a phone is written straight to the student record, not into a separate app that someone has to match up later. There is no copying, no overnight update, and no second version of the truth.

The learning area

The learning area we built is a simple one, and it would be wrong to describe it as anything more.

It holds course material and lessons against the courses already in the system, lets teachers set assignments and students hand them in, supports simple tests, and sends marks back into the main system so results live in one place.

What it does not do: learning paths, certificates, discussion boards or detailed analysis. The institution did not need those, so we did not build them.

What makes it useful is the connection rather than the feature list. Because it reads the same student and course records as the main system, there are no duplicate class lists, no separate logins, and no question about which system is right.

The AI assistant

This is where the "AI-powered" part of the story earns its name. The assistant answers everyday questions from all three groups, at any hour, using the institution's own records. It was built for this project specifically, it is not a ready-made chatbot dropped on top.

A parent can ask what their fee balance is and get their actual balance, not a link to a policy page. A student can ask when an assignment is due. A teacher can ask for a class list.

Three things mattered more than how well it chats:

• It checks who is asking before it answers. A parent can only ever get their own child's information, because the question is limited to them before it ever reaches the records. The assistant is never trusted to decide who may see what.
• It answers from the records, or it says it does not know. It reads the institution's own information. It does not invent a fee deadline that sounds about right.
• It hands over properly. Anything sensitive, disputed or outside what it covers goes to a person, with the conversation attached, so nobody has to repeat themselves. Every conversation is saved.

Used this way, an assistant does not replace the support team. It answers the questions the system already knows the answer to, so the team can spend its time on the ones it does not.

The hand work we replaced

The rebuild made the system safe to look after. The automatic steps are what made it better than what came before.

Two things are worth pulling out of that list.

Nobody lost a decision they used to make. Attendance is still taken by the person teaching the class. It is simply recorded once, on a phone, and never typed again.

It also changed when information arrives. A monthly report tells you about a problem after the month that caused it. Up-to-date figures tell you while you can still do something about it.

How it all fits together

Read that picture from the bottom up and you have the whole idea. One set of records at the base. The rebuilt main system on top of it. One shared connection above that. Everything else, the office system, three apps, the learning area, the assistant, goes through that connection. Which is why each new piece got easier to add instead of harder.

The main dashboard, plus two or three key sections, ideally admissions, fees and attendance. Blur or replace real student names and contact details first.

Two or three app screens, one per group. Phone frames around them will match the style of the other images in this article.

What changed

• The system is safe to run again. It moved from software that no longer received safety updates to current technology that is still supported.
• The work the staff were doing by hand is now done by the system. Nobody lost a role. The office lost the typing.
• People can reach it. Students, parents and teachers use it from their phones, and get answers at any hour instead of only when the office is open.
• Everything is joined up. The main system, the learning area, the apps and the assistant all read and write the same records, so nothing is typed twice and nothing disagrees.
• It can be improved. They can build on this system instead of planning to replace it, which is the difference between something that helps them and something that holds them back.

[FILL IN BEFORE PUBLISHING] Add real numbers here if they can be checked and published, or delete this line: parts rebuilt, records and years of history moved, how many students, parents and staff use it, time saved on a specific job, or questions the assistant handles. A two-sentence quote from their IT lead or office head can go just below.

Talk to our team →

What this means if you are in the same position

The interesting part of this project is not the four weeks. It is why four weeks was available at all.

A working system holds something that no document holds and no tool can recreate from a description: years of decisions about how one particular organisation actually operates. The fee rules and their exceptions. The attendance policy and its odd cases. The report format the board expects. Nobody ever wrote those down, because nobody needed to, they were in the software.

Starting again from a blank page throws all of that away and hopes somebody remembers it in time. Rescuing the software reads it, keeps it, and replaces only what is genuinely broken. That is faster, safer, and what we would suggest to almost any organisation sitting on software that still works but can no longer be looked after.

If that sounds like your situation, the honest first step is not a proposal. It is a proper look at what you have. It is the cheapest part of the whole project, and the only part that tells you whether the rest is necessary.