Migrating off legacy property software

Start with an honest data audit

Before any mapping, count the existing records: owners, units, active leases, mandates, documents and open tickets. Then count the duplicates. In most legacy systems, five to fifteen per cent of owner records are duplicates or dormant.

Decide early who arbitrates when two records conflict. Migration projects stall on unanswered questions, not on technical problems.

Extraction, in order of difficulty

• Structured exports, if the vendor provides them. This is the simplest case.
• Direct database extraction where the contract allows it.
• Report-based extraction. It is slower, but often the only option on closed systems.
• Documents. They are usually the largest volume and the least structured.
• Historical financial movements. You decide how many years to carry over.

Map to the target model, not to the old one

Recreating the legacy structure so the team recognises it imports the original problem. A mandate stored as a text field must become a mandate object, even if this requires a decision per record during migration.

Where the old system had no equivalent, for example a mandate or a ticket cost, plan a short data enrichment phase. Do not assume the field exists.

Waves and parallel running

Migrate one office or one owner group at a time. Run both systems in parallel for one full monthly cycle: produce the same statements in each, then compare them line by line. Only this comparison reveals discrepancies.

Set a fixed cut-over date per wave and inform the team in advance. Archive the legacy system in read-only mode rather than switching it off abruptly.

Expected result at the end

• One unit list that every department accepts as the reference.
• Owner statements produced from the platform for a full cycle without manual correction.
• Documents attached to the right entity, findable without knowing where they were filed.
• A team that no longer opens the old system out of habit.