The first sign of trouble came on the morning of orientation week. The new campus management system had been live for three days, and the admissions queue was fourteen hundred students deep. The platform had been crashing intermittently since Sunday night. By Tuesday, the admissions office had quietly opened a spreadsheet (the same kind of spreadsheet the new system was supposed to retire) and started processing students by hand. By Friday, the spreadsheet had become the primary system of record for the week’s intake.
The parallel run that was supposed to catch this had been quietly abandoned three weeks earlier, because the project timeline had no slack and the team was exhausted. By the time the system went live, nobody on the steering committee knew which scenarios it had been properly tested against. They found out alongside the students.
That implementation had taken three years and somewhere over two million ringgit. It involved a global vendor, a dedicated steering committee, six months of requirements gathering, four months of customisation, and a go-live date set by the academic calendar rather than by the project’s actual readiness. The system limped on for another eighteen months before the institution started quietly evaluating its replacement.
This isn’t an outlier story. Some version of it happens at most universities that attempt a campus management system implementation. The technology rarely fails outright. What fails is everything around it.
Why this story isn’t unusual
Most campus management system implementations don’t fail in any dramatic sense. They go live. They’re declared a success at the steering committee meeting. They appear in the annual report under “digital transformation initiatives.” And then, over the eighteen months that follow, the institution quietly works around the parts that didn’t quite work, retrains people on old habits the new system was supposed to break, and learns to expect less from the platform than was promised.
Across the sector, dissatisfaction rates for campus management implementations consistently run above forty percent, and that figure is measured against shipped systems, not abandoned ones. The institutions counted in it didn’t fail to implement. They failed to get what they paid for, and they noticed.
When you talk to the people who lived through these implementations, the registrars and finance heads and examination officers and IT teams left holding the pieces, the same pattern keeps surfacing. The diagnosis is rarely technical. The platform usually works the way the vendor said it would. What doesn’t work is the gap between what was bought and what the institution actually needed, and that gap is institutional.
The procurement starts the problem
The decision about which campus management system to buy is rarely made by the people who will spend the next decade using it. It’s made by a procurement committee that includes finance, IT, and sometimes senior academic leadership, working from a request-for-proposal document that mostly tests how comprehensively each vendor can claim to meet a checklist of features.
This selects for the wrong things. Vendors win RFPs by saying yes to everything. The cost of saying yes (the customisation, the workarounds, the modules that exist on the brochure but not in any deployed installation anywhere) surfaces during implementation, by which point the contract is signed and the integration team has inherited the gap.
The procurement process also tends to underweight the things that matter most in a long-running implementation. How does the system handle change? When the institution’s fee structure shifts, or a new accreditation requirement lands, or the academic calendar moves to a trimester model, what does that take to update inside the platform? Two clicks or two months? RFPs rarely ask. Vendor demonstrations rarely show.
And the people best placed to know whether a system will actually fit the institution, the registrars and finance officers and examination teams who will live inside it, are usually consulted at the requirements stage and then politely thanked. By the time the system goes live, half their original input has been lost in the gap between what was specified and what was scoped.
Customisation finishes it
Once a system is chosen, the institution starts customising. This is where the second failure pattern compounds the first.
Every university believes its policies are unique. Its progression rules, its fee structures, its examination governance, its committee approvals. Some of that uniqueness is real. Most of it isn’t. What gets called “our way of doing things” is usually a collection of accumulated workarounds from the previous system, codified into local practice and now defended as institutional identity.
When that accumulated practice gets translated into customised code inside the new platform, the system becomes brittle. Every upgrade is a project. Every integration with a new third-party tool requires rework. The vendor’s standard updates can’t be applied because they’ll break the customisations. Within five years, the institution is running a forked version of the product, maintained by a small group of consultants who know how the customisations were written, with no path back to standard.
One private institution we worked with had customised so heavily during their original implementation that each subsequent vendor upgrade took an average of nine months and cost roughly the same as the original deployment. Most of those customisations had been justified at the time as essential to the institution’s unique way of operating: a fee-calculation engine reworked to handle a scholarship category that applied to twelve students, an approval workflow rebuilt around a committee that met twice a year, a result-publication module wired to a faculty board structure that had since been reorganised. None of them, taken individually, turned out to be essential enough to justify the cost of maintaining them.
The institutions that get this right take the opposite approach. They configure aggressively, using the platform’s built-in tools to encode their actual rules, and customise minimally. Their policies live inside the system as configuration rather than as code, which means they can change without re-engineering and the platform can evolve without breaking their workflow.
Data migration is always underestimated
Of all the parts of a campus management system implementation, data migration is the one that consistently destroys timelines and the one that consistently gets allocated the smallest portion of the budget.
The reason is straightforward. Source data is always worse than anyone admits. Student records that have been maintained across three legacy systems over fifteen years contain duplicates, conflicting identifiers, inconsistent date formats, fields that meant one thing in 2009 and something else in 2017, and the kind of historical detritus that only emerges when you try to move it. The migration team starts with what looks like a clean count of thirty-eight thousand student records, and quickly discovers that around forty-five hundred of them have at least one issue requiring a human being to make a decision. That’s forty-five hundred individual judgement calls the project plan made no allowance for.
Migrations get planned on the assumption that source data is roughly accurate. They get scoped around the time required to map fields, write transformations, and run the load. The time required to actually clean the data, to reconcile, to decide which of three conflicting addresses for a student is the right one, to call a person who graduated in 2014 and ask which spelling of their name they prefer, that time is almost never budgeted.
When the migration runs late, the institution is already committed to a go-live date set by the academic calendar. Either the date slips, which is politically painful, or the data goes in dirty, which is operationally painful. Most institutions choose the second. And then they spend the next year cleaning the data inside the new system, which is harder than cleaning it before the move.
And then everyone moves on
The day the system goes live, the implementation team begins to disperse. The vendor consultants rotate to the next client. The internal project team gets reassigned. The training programme, which was intense for the four weeks before launch, drops to occasional refresher sessions and an internal helpdesk that fields questions on top of its existing workload.
Staff who were trained on day one start to forget the parts they don’t use daily. The parts they do use daily, they figure out their own way of doing, and their workarounds quietly become local practice the same way the old system’s workarounds did. New staff are onboarded with whatever materials happen to be available, which is usually a slide deck from the original training and the memory of whoever sits next to them.
By month eighteen, the new system looks a lot like the old system. Different software, same patterns. The institution wonders whether the implementation was worth it.
What the institutions that don’t repeat this do differently
A small number of universities run campus management system implementations that actually deliver what was promised. They start from a different premise: that a campus management system is a description of how the university operates, encoded into software, and that the work of implementing one is the work of writing that description carefully.
The practices that make it work aren’t independent. Each one addresses a specific failure point described above. Institutions that get all four right tend to get the implementation right. Institutions that get three right still fail, just more slowly.
They treat the implementation as institutional change, not as software installation. The executive sponsor is the registrar or the vice-chancellor’s office, not the IT department, and that sponsor stays involved through go-live and well beyond. The decision about what to encode in the platform, which policies, which workflows, which approval hierarchies, is made by the people who own those policies, not by a project team translating requirements they don’t fully understand.
They configure aggressively and customise minimally. They invest in the platform’s built-in configuration tooling rather than asking the vendor to build them something special. Their policies live as data inside the system, not as code on top of it, which means upgrades stay routine.
They plan data migration as its own project, with its own timeline, its own budget, and its own dedicated team. They start cleaning source data twelve months before go-live, not three. They go in clean or they don’t go in.
And they treat training as continuous. There’s a permanent role inside the institution, sometimes a small team, responsible for the system’s ongoing fit with how the university actually operates. When a new fee structure is introduced, the platform is updated within the same project. When a department develops a workaround, somebody notices and fixes it.
None of this is novel advice. It’s just consistently not followed, because it requires the institution to acknowledge that the system is part of how it operates, not a tool sitting beside how it operates.
The cost of learning the hard way
The institution from the opening of this piece, the one that processed orientation week intake by hand because the new platform was crashing, eventually replaced its campus management system about four years after go-live. The replacement implementation went better, mostly because the people running it had lived through the first one.
That is, in practice, how most institutions learn. They go through one bad implementation, lose three or four years of operational capacity, and emerge wiser about what to demand from the next one. The cost of that learning, calculated honestly, is enormous, and it falls disproportionately on the students who happened to be enrolled during the years when nothing quite worked.
