Amid ever-changing views on the role of housing management systems (HMS), Housing Technology interviewed a few experts on the ERP vs. HMS debate, when to replace your HMS, integration with other core systems and common mistakes to avoid when migrating to a new HMS.
When is an HMS too old?
Ben Charlton, head of migration at Migra Data, said, “There are no definite rules but there are certainly good indicators of when your HMS might be nearing its retirement age. In the context of your business processes, how many ‘work-arounds’ do you have that were developed to overcome system quirks, functional gaps or changing regulations that have now become ingrained into your BAU operations?
“It’s also worth considering whether the product roadmap for your HMS is keeping pace with technological trends and continues to support your business and IT strategy. It isn’t a necessity for a HMS to provide AI models to support predictive analytics, for example, but definitely ask whether your HMS can keep pace and support integration with systems and platforms that do.”
Lee Burke, chief revenue officer at Aareon, said, “There isn’t a hard ‘expiry date’. What matters is whether your HMS and its surrounding processes still support the outcomes you need, such as service quality, compliance, security, data access and automation.
“We’ve seen mature HMS platforms remain effective when housing providers have modernised their wrap‑around processes and selectively upgraded their operating model by moving an established HMS into a managed cloud/hosted model to improve performance, resilience and upgrade cadence without the need for wholesale replacement.”
Steve Dungworth, director and digital advisor at Golden Marzipan, said, “Age on its own isn’t the problem. We’ve seen older systems still delivering value because they’re well understood, properly maintained and supported by good processes. Equally, I’ve seen relatively new systems already creaking because they were poorly implemented or never aligned with business needs.
“A better question is whether the system still supports your purpose. Can it adapt to regulatory change, does it integrate easily and are your staff working around it rather than with it?”
Jeremy Squire, UK managing director at Solvares Field Service, said, “An HMS becomes ‘too old’ when it starts to create operational risk rather than mere inconvenience. Typically, systems more than 10 years old begin to show structural limitations such as outdated architecture, on-premise hosting, limited API capability and dependence on scarce specialist knowledge.
“If the system can’t integrate cleanly with finance platforms, CRM tools or modern reporting environments (or if upgrades are infrequent and disruptive), it is effectively ‘legacy’. The real test is capability: if the HMS restricts automation, forces manual workarounds, limits data visibility or slows regulatory reporting, it is functionally obsolete.”
Matthew Hedges, products director at TechLabs London, said, “Age is the wrong measure, whereas inflexibility is the correct one. An HMS is ‘too old’ the moment it can’t keep pace with regulatory changes, open integration patterns, modern security baselines or quarterly upgrade cadences without costly, disruptive projects.
“If you’re compensating with spreadsheets, swivel-chair processes or a growing ring of tactical integrations, the system is already past its useful life, regardless of its birth year. In a sector facing increasing scrutiny around safety, transparency and service quality, architectural rigidity quickly becomes a service risk, not just a technical risk.”
Modern vs. legacy HMS
Emma Mahy, founder and CEO of IoT Solutions Group (IoTSG), said, “Modern HMSs are built for continuous improvement, resilience and integration. Cloud-based delivery typically means faster release cycles, better scalability, stronger disaster recovery options and a more sustainable security posture because patching and monitoring are designed to be ongoing rather than periodic.
“Just as importantly, modern systems tend to support open APIs and cleaner data access, which is what enables joined-up services across repairs, compliance, customer contact, finance, BI and specialist tools.”
Trevor Hampton, director of housing solutions at NEC Software Solutions, said, “These products are modern, SaaS-based and can be deployed quickly and efficiently. They scale well, so if you’re small and growing fast, they might be a good choice. Modern HMSs are also mobile-enabled as standard and deliver great user experiences.
“What the modern systems sometimes lack is the depth of functionality that many housing providers need. It may have slick user interfaces but can it manage debt recovery and escalation policies in the same way as your legacy systems? An HMS that combines the best of new technologies and depth of functionality is often what is required, certainly for larger housing providers.”
TechLabs London’s Hedges said, “Modern platforms trade slow, monolithic upgrades for continuous delivery, open APIs and a data model designed for people, properties, assets and agreements to work as one.
“Those yield faster time to value, better mobile experiences for colleagues, frictionless resident self-service and front-end configurable analytics for surfacing data such as arrears risks, compliance exposure and damp/mould hotspots. These all form the foundation for predictive and AI-assisted decision-making rather than retrospective reporting from teams heroically building out these insights every month.”
Aareon’s Burke said, “It really depends on the legacy systems and processes an organisation has. Cloud‑native HMSs typically cut technical debt and total cost of ownership by moving hosting, upgrades and security into managed SaaS, with continuous updates. They bring stronger integration and analytics for real‑time decisions, plus better UX and automation so staff spend less time on administrative tasks.”
Are web services, middleware & APIs a viable route?
Engin Yilmaz, director of product innovation at Mobysoft, said, “In many cases, yes, integration layers and APIs can allow housing providers to retain a stable core HMS while connecting specialist systems that deliver deeper operational capability and better regulatory evidence.
“This approach avoids forcing complex, compliance-critical processes into a generalist platform that was never designed for that level of depth. However, integration can’t compensate for fundamentally poor data-quality or weak governance in the core system.”
Solvares Field Service’s Squire said, “Web services, APIs and middleware are useful short-term bridges to extend an existing HMS’s life and add functionality. They empower housing providers to layer specialist capabilities onto established platforms without the expense of a full system replacement.
“APIs enable housing providers to modernise incrementally while protecting their existing investments and maintaining service continuity. Best-of-breed solutions can integrate directly into the core HMS, delivering enhanced functionality without destabilising operations.”
IoTSG’s Mahy said, “Web services, middleware and APIs can be a pragmatic bridge and sometimes they’re the best short-term option to reduce manual work and connect specialist systems.
“But they aren’t a permanent substitute if the HMS itself has weak APIs, brittle data access, slow upgrade paths or high integration costs. In those cases, middleware becomes an expensive ‘compatibility layer’ that you end up having to maintain forever without ever actually fixing your fundamental constraints around data quality, workflow capability and change velocity.”
Specialised HMS & generic ERP
Ivan Blythe, solutions consultant at Xledger, said, “Generic ERP systems offer a lot of functionality (e.g. finance, HR & procurement) for housing providers but without any of the housing-specific capabilities found in an HMS, such as property management, tenancy management, CRM, asset and home-swapper tools, to name a just few.
“Neither solution fulfils all of a housing provider’s requirements, but when integrated with best-of-breed applications, either solution (ERP or HMS) could be part of a robust housing technology ecosystem.”
Golden Marzipan’s Dungworth said, “The ERP versus HMS question is now being asked more often. On the one hand, generic ERP platforms are increasingly capable, and some housing providers are successfully building housing-specific capabilities on enterprise platforms.
“However, our sector has some very specific regulatory, tenancy, asset and compliance requirements. Housing providers therefore need to be realistic about the level of configuration, sector expertise and governance required when considering ERP platforms.”
NEC’s Hampton said, “A few years ago there was a lot of talk from the big ERP providers that they would soon have solutions for the housing sector but that hasn’t really happened.
“ERP was initially developed as a technology to manage the hugely-complex workflows associated with, say, the aerospace or large-scale manufacturing sectors. As such, ERP systems don’t really translate to the social housing sector – ERP systems provide you with a set of technologies that you need to stitch together to work in a housing context. There is no plug and play income or repairs model, for example.”
TechLabs London’s Hedges said, “ERP systems excel at finance, procurement and HR, but housing’s ‘domain DNA’, such as allocations and lettings, voids, responsive repairs, compliance cycles, service charges, arrears and tenancy sustainment, reflects real-life resident journeys and regulatory duties, all of which would have to be developed in an ERP system at significant cost and risk.
“Most housing providers get better outcomes from pairing a housing-centric operational core, typically an HMS, with the strongest parts of an ERP system, rather than forcing an ERP system to become an HMS or CRM through expensive over-customisation.”
Are HMSs becoming more specialised or functionally wider?
Mobysoft’s Yilmaz said, “They’re simultaneously becoming more specialised and functionally wider, which is creating tension. HMS suppliers are expanding their products’ functional coverage, while regulatory pressure is increasing the need for specialist depth in areas such as repairs, safety and compliance.
“The risk is that as HMS platforms expand their functional scope, critical processes become over-simplified to fit a general model, resulting in data that’s adequate for reporting but weak for operational control and auditing.”
IoTSG’s Mahy said, “Organisations often adopt best-of-breed applications when specific areas such as repairs, CRM, analytics or compliance need a step-change, then later try to reduce ‘application sprawl’ by pushing more back into their HMS.
“The more durable model isn’t ‘more features’ but a strong core HMS that behaves like a platform, with stable data, strong workflows and easy, well-governed integration.”
Golden Marzipan’s Dungworth said, “Some HMS suppliers are expanding their products’ functionality to become broader platforms while others are specialising deeply in areas such as compliance, repairs optimisation, tenant engagement or analytics.
“Housing providers’ IT estates are becoming more federated. The idea of a single system holding the entire truth about customers and homes is fading. Instead, data is assembled across multiple platforms, which places much greater emphasis on integration, data standards and governance.”
TechLabs London’s Hedges said, “The core footprint of an HMS is broadening, with native field-service capabilities, asset and programme management, casework and omni-channel engagement.
“At the same time, a native integration layer makes it easier to plug in specialist tools in areas such as diagnostics, IoT, surveys and data analytics. We believe the direction of travel is a composable platform that’s solid enough for everyday work and porous enough to welcome depth where it matters.”
All-in-one or best-of-breed?
Xledger’s Blythe said, “A single HMS might work for smaller housing providers if they’re willing to manage some lower volume processes offline. However, for larger organisations, attempting to support every business function through a single HMS can become extremely expensive, with different point solutions being needed in addition to the core HMS.
“Investing in best-of-breed applications that can integrate with an HMS is a more pragmatic approach. When integrated seamlessly, this model ensures housing providers maintain complete operational oversight and control while using best-of-breed applications.”
NEC’s Hampton said, “An HMS should aim to meet the majority of your needs. After all, most housing providers don’t want to be managing multiple suppliers for every need – they just don’t have the time.
“However, best-of-breed applications can add value. For example, electrical compliance is incredibly specialised so when you’re getting to that level of detail, a specialist option may be best.”
Solvares Field Service’s Squire said, “A common mistake is assuming that one platform can do everything. While all-in-one systems have the advantages of centralised data, they can lack the specialised functionality and flexibility required. Best-of-breed solutions can adapt to the specific needs of different business areas and are flexible and have easy implementation paths.”
Mobysoft’s Yilmaz said, “A HMS shouldn’t aim to do everything. A more resilient approach is to treat the HMS as the authoritative ‘system of record’ and then connect specialist applications where deeper workflows, decision-making and evidence are needed.
“Although best-of-breed systems can introduce integration complexity, they also reduce the risk of over-stretching a core platform in areas where regulatory failure carries serious consequences.”
Critical HMS selection factors
IoTSG’s Mahy said, “A cloud-native architecture rather than ‘hosted legacy’ should be your baseline, alongside demonstrably strong security, identity and audit capabilities. Integration should be assessed as a first-class requirement: API depth, documentation quality, event/webhook support and sandbox environments, alongside real-world references where the proposed supplier has integrated with multiple specialist systems.
“Data ownership and terms of access matter just as much as features; for example, housing providers should be able to extract and use their data without punitive costs. Finally, look for a product that is configurable rather than heavily customised, and a delivery approach that is proven, repeatable and honest about migration and change management.”
Golden Marzipan’s Dungworth said, “Clarity of purpose comes first, so what problem are you actually trying to solve? Too many procurements start with system features rather than service outcomes. And don’t underestimate user adoption; if your front-line teams don’t trust or understand the system, the intended benefits simply won’t materialise.
“The ‘softer’ procurement and supplier considerations also matter. Post-implementation support, quality of ongoing service, account management and how easily you can make changes without relying on consultancy can all shape your long-term success.
“Finally, as many housing providers have found to their cost, the bigger the supplier, the more important it is to understand how responsive and adaptable they’ll actually be once the contract is signed.”
TechLabs London’s Hedges said, “Start with your outcomes and measurables metrics, such as repair durations, first-time fixes, arrears trajectories, void turnarounds, compliance exceptions, resident satisfaction, digital adoption and complaint resolution times. Then evaluate how the platform’s data model, APIs and roadmap support those outcomes with minimal customisation.
“Some other things to look for include a clear product roadmap, robust approaches to security, discipline around SaaS releases, pathways for adoption instead of customisation, credible tooling for migration, accessible reporting, AI readiness and strong digital channels for residents.”
Common mistakes – HMS selection & implementation
Migra Data’s Charlton said, “Neglecting a thorough requirements analysis and documentation process can be an expensive mistake. Selecting a new HMS is a big investment so it’s critical that the procurement and selection process is backed by an extensive, prioritised set of requirements that cover the ‘must haves’ across all business units for day one and the critical elements of the long-term business strategy.
“The ‘corner cases’ that cause the most pain in BAU are often still not remediated by the selected solution, therefore diminishing the realised benefits. In addition, not paying enough attention to the cross-party roles and responsibilities for the full implementation plan is a stumbling block we see frequently, particularly when it comes to source-data preparation, the definition of reference data and configuration, and data migration.
“The purchasing party needs to be crystal clear on what they’re on the hook for (along with the heavy resourcing requirements) when it comes to ensuring the system is ready for each test cycle and cutover for day one operations. Be honest about your own internal capabilities and seek help where you need it.”
NEC’s Hampton said, “IT teams are obviously a vital part of any system change but they shouldn’t lead it. Those actually doing the job know exactly what they need the system to achieve, so neglecting the business end-users until it’s too late will definitely result in problems further down the line.
“Strong leadership is critical. Without it, there’s no one to explain the vision of the change to the workforce. Instead, your colleagues may only see the disruption to their working day rather than the end goal.
“Finally, not getting your data in order before you switch is one of the biggest mistakes we see. A great system can’t do anything with poor data so never rush that part of the process.”
Solvares Field Service’s Squire said, “Common mistakes include a lack of clarity in terms of long-term objectives and future needs or selecting a system that’s too complicated for staff to use, resulting in low rates of adoption.
“Front-line users should be involved in the selection and design process and integration capabilities must be a focus. Your change-management programmes might be brilliant but ultimate success depends on securing end-users’ buy-in before configuration begins.”
Mobysoft’s Yilmaz said, “The most common mistake is treating consolidation as an outcome in itself rather than focusing on service quality, compliance and evidence.
“Other frequent problems include underestimating the effort needed for data migration, replicating legacy processes instead of redesigning them, over-customising early, and failing to plan integration and change management properly.”
Housing Technology would like to thank Lee Burke (Aareon), Steve Dungworth (Golden Marzipan), Emma Mahy (IoT Solutions Group), Ben Charlton (Migra Data), Engin Yilmaz (Mobysoft), Trevor Hampton (NEC Software Solutions), Jeremy Squire (Solvares Field Service), Matthew Hedges (TechLabs London) and Ivan Blythe (Xledger) for their contributions to this article.
