Migrating a Housing Asset Register, Components and All, into Oracle Fusion
Data is usually the biggest worry in a housing finance replacement, and the asset register is the biggest part of it. This is how we migrate balances, suppliers and tens of thousands of components so that finance can sign every number off.
Housing finance teams ask three questions about migration before anything else.
Will our balances be right? Will the asset register come across with its components? And how much history do we have to bring? The answers shape the whole migration plan, so we settle them early and in the open.
Every load is reconciled to your control totals and approved by your finance team. That rule does not bend.
Why housing asset registers are different
A housing association does not hold a few thousand assets. It holds tens of thousands of properties, and under component accounting each property is split into roofs, kitchens, bathrooms, heating systems, windows and doors, each with its own cost, life and depreciation. A register of twenty thousand properties can easily mean two hundred thousand components.
Each component also has to sit in the right place in the reporting structure: the scheme, block and property it belongs to, and where relevant the grant that funded it. If that link is lost in migration, the register still balances but stops being useful for asset management, impairment reviews or regulatory returns.
So we migrate asset by asset, component by component, and map each one to scheme, block and property during the load, not afterwards.
What comes across
Balances
Opening balances and open items in payables, receivables and purchase orders, reconciled to your control totals.
Asset register
Every asset and component, with cost, accumulated depreciation, life and its scheme, block and property.
Suppliers
Mapped once from both the old finance system and the old P2P tool, de-duplicated, with bank details verified.
History
You choose how many years come across. Older years can be kept as a searchable archive.
Three loads, each one reconciled
We never load legacy data straight into production. Migration runs in cycles, and each cycle is a full rehearsal of the real thing:
- First mock migration. Run during the build phase, once mappings are agreed. It shows where the data needs cleansing and proves the load works end to end. Finance reviews the results and signs off the first data check.
- Second mock migration. Run with cleansing fixes applied, ahead of system testing, so testers work with realistic data. Its reconciliation feeds the gate where system testing passes and the data is confirmed.
- Final load. Run at cutover, after the old systems freeze. Delta loads bring across the last transactions, and finance approves the opening balances before anyone uses the new system.
Every cycle produces record counts, control totals and an exceptions report. Balances, open items, purchase orders and fixed assets are reconciled to agreed legacy reports. The component population is checked with automated validation plus sampled business checks, because no one can eyeball two hundred thousand rows.
Extraction and cleansing, agreed on real findings
Who extracts what, in which format, and who cleanses which records are agreed jointly after the data has been profiled in the first weeks of the programme. We do not assume all of it sits with the housing provider, and we do not price it as a surprise later: the migration service and its reconciliation are part of the implementation.
Profiling early means decisions are made on what is actually in the old systems, not on what everyone remembers is in them.
How much history to bring
Bringing every year of history into a new ledger is rarely worth the cost. Most housing providers bring opening balances, open items, the full asset register and one or two years of summarised history, and keep older detail in an archive their auditors can still search.
The right answer depends on audit, regulatory and reporting needs, so it is agreed with your data owners in discovery and written into the migration scope.
Done before, at scale
At Riverside, PCL One migrated more than 600,000 property and non-property assets across over 30,000 properties, around five million balances and more than 8,000 suppliers onto one Oracle finance platform, across 40 legal companies.
A typical housing association register sits comfortably inside the scale we already run.