University of London Housing
Accommodation search and management for students and landlords, rebuilt so the team could run it themselves and students could trust what they were looking at.
The problem
University of London Housing Services sits between students looking for somewhere to live and hundreds of independent landlords listing thousands of properties between them. The service existed to make that search trustworthy, but it was running on a legacy database, more than twenty years old, that had been stretched well past what it was built for.
Landlords had no real way to manage their own listings, so every update went through the housing team by hand. Students were searching a system that couldn't filter or compare properties properly. And the university itself had no reliable way to report on what was actually happening across the portfolio.
What we had to solve
Search across thousands of properties
Hundreds of landlords listing thousands of properties between them meant students needed real filtering and comparison, not a static list inherited from the old database.
Landlords who aren't full-time administrators
Landlords needed to list, update and manage their own properties without training or a call to the housing team every time something changed.
Reporting the university could rely on
Housing services needed accurate, current reporting on listings and occupancy, which the legacy database had never been built to produce.
A database that had reached its limits
More than twenty years of records sat in a system that couldn't be extended safely, so every new requirement became a workaround rather than a feature, and the data carried the marks of every one of them.
Moving twenty years of data
The old platform had been running for more than twenty years, and the data showed it. As the service changed, fields had quietly been put to work for things they were never named for: free-text boxes doing the job of a status, columns holding one kind of value for years and another after that. None of it was written down, and all of it was information the housing team relied on every day.
So we didn't start by matching old columns to new ones. We started by finding out what the data actually meant, and who depended on it.
Reading the data, not the labels
We profiled every table and field for what was really in it: patterns, blanks, duplicates and outliers. Where a field had drifted from its original purpose, we traced when it changed and why, so nothing was moved on the strength of a column name.
Workshops in the team's own language
We ran sessions with the housing team and stakeholders built around questions they could answer from experience, like “When a landlord rings to say a room has gone, what do you change?” rather than “Which field holds occupancy status?” Their answers decided where each piece of information belonged in the new platform.
Rules the owners signed off
Every transformation was written as a plain-English rule and agreed with the people responsible for that data. Decisions about duplicates, conflicting records and what to leave behind were theirs to make, with the evidence in front of them.
Flagged, not guessed
Records that couldn't be fixed by a rule were set aside for someone who knew the context to review, rather than forced into shape by a script. Old records that no longer served a purpose were archived, not carried forward out of habit.
Rehearsed until it was routine
The migration was scripted and run end to end repeatedly against copies of live data. Each run produced a reconciliation report of counts, totals and sample records that the housing team could check against what they knew to be true.
A cutover without surprises
By launch the move had been rehearsed so often that it was a known quantity: a short, planned window, a final sync of recent changes, and the old system kept available read-only for reference while the team settled in.
What we built
We designed the full system from the architecture up and built the replacement on Drupal: a proper data model for properties, landlords and students, search and filtering that actually works at the scale the service runs at, and a landlord side built for people who log in a few times a year, not every day.
The build ran nine months end to end, from architecture through to launch, with one team accountable for the whole platform rather than the university coordinating pieces from different suppliers.
Filtering and comparison across thousands of listings from hundreds of landlords, built for how students actually search.
Landlords list and manage their own properties directly, without going through the housing team for routine updates.
Housing services can see occupancy and listing activity across the portfolio without exporting anything by hand.
A Drupal platform the university's own team can build on, rather than a system that has to be patched around.
The outcome
The platform launched after a nine month build on Drupal. Property search is something students can actually use, landlords manage their own listings instead of emailing the housing team, and the university has reporting on the portfolio it didn't have before.
Ask the client for a quote and two or three measurable results to sit here — landlord adoption, search-to-enquiry conversion, or time saved by the housing team.
A sentence from the housing team about what changed for them.
Got a process like this?
Applications, assessments, panels and deadlines. Thirty minutes on the phone is usually enough to tell you whether it is a six month job.
020 3608 2525