From Spreadsheets to Software: A Migration Guide for AHBs Managing 500+ Units

If you run an AHB with more than 500 units, you almost certainly have a software stack rather than a software platform. Some combination of a legacy housing system from the 1990s or 2000s, a finance ledger that does not talk to the housing system, a fleet of Excel files that bridge the gaps, and a small army of email folders that hold the actual decisions.

This works, in the sense that rents get collected and tenants get housed. It does not work in the sense that NOAC reporting takes a week, audits take a month, and any change in scheme rules requires manual reconciliation across three systems. The AHBR’s Tier 3 standards have effectively made this stack untenable as the regulator’s audit standard rises.

This piece is the practical migration guide for AHBs choosing to move from stack to platform. The core lesson is unflattering: the technology is the easy part. The data is the hard part. The change management is the hardest part.

What you almost certainly have now

The typical mid-size AHB stack:

• A housing management system holding tenant records, tenancy details and waitlist data
• A separate finance ledger for rent collection, arrears, supplier payments and NOAC financial reporting
• One or more Excel files for differential rent calculations, property compliance tracking, maintenance scheduling, and any reporting that does not fit the other two
• An email-and-shared-drive culture for officer notes, change-of-circumstance evidence and audit trails

None of these are bad in isolation. Together, they require manual reconciliation at every reporting cycle. We covered the cost in our fragmentation analysis; the same logic applies to AHBs.

What the integrated state looks like

One platform, one tenant record, one rent ledger, one compliance tracker, one audit trail. Differential rent calculation, RTB registration, S.I. 137 inspection scheduling and NOAC export all run from the same dataset. Officer activity, finance activity and tenant activity all timestamp into the same audit log.

The reduction in reconciliation work is the headline. The improvement in audit posture is the part that matters under AHBR Tier 3 standards. The improvement in decision quality (because the data is consistent across functions) is the under-counted gain.

The migration phases

1. Phase 1, scoping and design (weeks 1-2). Map the current stack. Identify the data sources of record for each entity (tenant, tenancy, rent, property). Design the target schema. Agree the cutover criteria.
2. Phase 2, data sanitisation (weeks 3-8). Extract from each source. Reconcile duplicates. Identify and resolve contradictions. This is the longest and most surprising phase. Plan to discover that 5-15% of records have issues.
3. Phase 3, parallel run (weeks 9-12). New system in place, old systems still authoritative. Officers work in both. Discrepancies surface and get resolved. NOAC reporting runs from both, with the discrepancies investigated.
4. Phase 4, cutover (weeks 13-14). Old systems become read-only. New system becomes authoritative. Final reconciliation. Sign-off on the migration.
5. Phase 5, optimisation (weeks 15-16+). Workflow refinement. Reporting refinement. Officer training on advanced features.

Where migrations actually fail

Almost never on the technology. Almost always on the data. The most common failures we see in AHB migrations:

• Tenant records duplicated across systems. The same person counted twice, or three times, with slightly different name spellings or address formats. Reconciliation has to be deliberate.
• Rent ledger discrepancies. Finance and housing show different rent due figures because differential rent reassessments happened in housing without flowing to finance. The reconciliation has to identify which is correct, case by case.
• Compliance certificates with no source of truth. S.I. 137 inspection dates in Excel, electrical certs in email, gas certs in a paper file. The migration has to centralise these or they will be missed at the next audit.

Change management is the hardest part

The team has been working a particular way for years, often decades. The migration is not just a system change, it is a process change. Officers who used to write notes in email folders now write them in the system, where they are searchable and auditable. That sounds neutral; it is felt as scrutiny.

The technique that works is co-design. Officers identify the workflow improvements; the platform configures around them; nobody is being told to use a system they did not help shape. The technique that fails is top-down rollout with training but no input.

How Rentalize handles this for you

Rentalize Core is the target platform. Migration is delivered as a fixed-scope project: scoping, sanitisation, parallel run, cutover, optimisation. The team works with the AHB’s housing officers, finance team and IT lead through each phase, with a single project manager on our side and a single sponsor on yours.

Our AHB customers typically come live within 14 weeks. The first NOAC reporting cycle on the new platform takes a fraction of the previous time. The first AHBR audit on the new platform passes on the documentation already there.

Frequently asked questions

How long does a 500-unit AHB migration take?

12-16 weeks elapsed, with 6 weeks of data sanitisation in the middle of that.

What is the biggest migration risk?

Data quality. Bad data in a new system produces worse results than the same data in the old system because the new system surfaces the inconsistencies.

Will my staff lose their jobs?

No, in our experience. Throughput improves; staff move from reconciliation to higher-value work.

Does the AHBR mandate integrated software?

Effectively yes for Tier 3 AHBs. The audit standard requires evidence that a stack of spreadsheets cannot reliably produce.

What does the migration cost?

Variable with portfolio size and complexity. Typically 6-12 months payback period from operational savings alone, before counting audit and compliance benefits.

Can the migration be done in-house?

The data sanitisation must involve the AHB’s own staff because they hold the institutional knowledge. The platform configuration is delivered by the vendor. The split works.

If you would like to see how Rentalize handles this in practice, you can book a 20-minute walkthrough. We will use one of your own properties as the worked example.