Taking the “Help me, somebody!” out of migrating your HMS
We’ve all sat through the sales pitch. The slide deck is sleek, the interface looks modern and cool and the promise is seductive. This new housing management system (HMS) won’t just store your data, it will revolutionise your business – it is a ‘single source of truth’ offering ‘seamless interoperability’. The IT supplier’s account executive smiles, the board nods and the project gets the green light.
Then, six months later, the project status is ‘amber’, the budget is strained and nobody can quite explain why Mrs Miggins at No. 4 has suddenly acquired three garages and a rent balance from 1998.
The problem is rarely the destination system itself. Modern platforms are generally robust, offering logic and workflows that legacy systems simply cannot match; the problem is the journey.
Data adapts to its surroundings over time, meaning that when it comes to migration, it’s less ‘lift and shift’ and more ‘unravel and rebuild’.
A tenancy is a tenancy, right?
The first significant hurdle is the compatibility, or lack thereof, of HMS solutions. Rarely is a ‘tenancy’ in System A the same as a ‘tenancy’ in System B. Legacy systems often treat data in ways that reflected the technology of their time.
For example, your old system might treat a joint tenancy as a single entity with two linked contacts. However, a modern ERP solution might treat it as two distinct account headers linked by a relationship object.
Trying to force data from a legacy schema into a rigid new structure requires more than just mapping fields, it requires fundamental transformation. You aren’t just moving data, you’re translating it and this becomes even more granular when we look at assets.
In your legacy system, a block of flats might be a single asset with child units. In the new world, the communal areas, the roof and the lift might all be distinct entities requiring their own maintenance schedules and depreciation logic. And that’s all before we start trying to apportion service charges.
If the data migration strategy doesn’t account for this explosion of detail, your asset management module will be effectively empty on day one.
Mind the data gap
We often come across the assumption, particularly at decision-making levels, that the HMS is the only source of key data and processes. In reality, it usually isn’t.
‘Grey IT’ sources, such as spreadsheets, macros and Access databases, are ubiquitous in all organisations, particularly ones as complex as housing providers, so we always strongly recommend an amnesty on other off-system processes whenever a migration programme kicks off. These types of often rudimentary, ungoverned and unsupported sources only add to the complications of data mapping yet they can be indispensable in certain key activities.
Understanding which processes have evolved beyond the capabilities of the current architecture is an essential piece of intelligence to be gathered when designing the new solution, so the sooner that is understood, the greater the chance that the spreadsheets can be consigned to the Big Recycle Bin In The Sky.
Of course, the kicker is that your new solution is likely to rely on ‘standard industry processes’. This is often a euphemism for ‘change your business or the system won’t work’.
When the data reflects a process you are abandoning, where does that history go? Often, it ends up in a memo field or an attachment, the twin graveyards of searchable intelligence.
The wheel keeps turning
Then there is the complexity of point-in-time data. Data is seldom static, so while we’re extracting, transforming and loading, the business carries on. Rents are posted, repairs are raised and voids are filled. Managing this successfully is a gift that comes only with experience.
Capturing a static snapshot of a dynamic arrears history is particularly intricate. If you migrate balances only, you lose the audit trail required for court cases. If you try to migrate the transaction history, you invariably find that the logic used to calculate debits in 2015 contradicts the logic in the new system or performance is degraded due to 20 years of transaction history trying to find its new home.
Know your data before you move it
The most effective mitigation to these challenges is an early and wide-ranging data discovery phase. Don’t wait for the implementation partner to ask for a data extract. Start well before, during the planning stage, by profiling your data to understand its shape (such as how many active tenancies have no start date or how many properties have zero bedrooms) and to identify anomalies as early as possible.
Cleanse the data in the source system where possible; if Mrs Miggins is listed twice, merge her records now. It is infinitely cheaper to fix data in a system your staff know than to fix it in flight or in a new system they are still learning to use.
Use that knowledge to shape the new solution. Changing the way things currently operate is inevitable and, ultimately, the point of the exercise. Making those changes transparent, logical and, importantly, easy to adapt to, will be critical to the success of the programme.
Rely on specialist expertise
This brings us to responsibility. While it’s common and entirely reasonable to rely on the software vendor or systems integrator for loading data into the new system, preparing the data to move is usually outside their scope; they unload the van but they don’t pack the boxes.
They may not understand the archaeological layers of your legacy data or the nuances of UK social housing regulations. You need people who understand that a Section 20 notice isn’t just a document but a data trigger.
Specialists can bridge the gap between technical schemas and business reality. They act as the translator, ensuring that what the business thinks it has matches what the database actually holds. They can also provide the tools and scripts to automate the transformation, providing a repeatable, auditable trail that auditors will love.
The potential of the latest batch of housing management systems is incredible. They can transform efficiency, provide truly novel insights through analytics and ultimately improve tenants’ experience but that potential is entirely dependent on the quality of the data fuel you put in their engine.
If you respect the complexity of the migration, invest in the preparation and work with partners who understand the terrain, the project will succeed.
It will still be hard work but it will be the good kind of hard work – the kind that leads to genuine transformation and, hopefully, no extra garages for Mrs Miggins.
David Bamford is the commercial director of Migra Data.
For further details, please see: www.migra.co.uk.
