Property-software migration checklist

Start with a migration plan, not a data dump

A clean migration begins before any file is exported. Decide the cut-off date (the moment the old system stops being authoritative), name an owner for the project, and agree what “done” looks like: reconciled balances, verified statements and a documented sign-off. For a managing agent moving multiple schemes or rental portfolios, sequence them rather than attempting everything at once, so lessons from the first migration improve the next.

Map your data sources honestly. Many South African agencies hold information in more than one place — the incumbent software, spreadsheets, a separate trust-accounting record and sometimes paper files. List every source, who controls it, and how you will get a complete, current export. The goal at this stage is a written plan that any reviewer can follow, not a heroic single push.

• Fix a cut-off date and freeze structural changes around it.
• Assign one accountable owner and a reviewer for sign-off.
• Inventory all data sources, including spreadsheets and trust records.
• Define success as reconciled, verified and signed-off — not merely “imported”.

What to extract: the complete dataset

Extract a full picture while you still have access to the old system, because re-exports later are painful. The core entities are properties and schemes, units (or sections and exclusive-use areas for sectional title), owners and members, tenants and leases, suppliers, and the documents attached to each.

On the financial side, extract invoices and credit notes, receipts, levy history for schemes, rent history for rentals, deposits held, opening balances per account, and an age analysis of arrears at the cut-off date. Capture banking and contact details too, but treat these as sensitive. The principle is to over-extract now and decide later what to import — missing source data discovered after go-live is far harder to recover.

• Entities: properties/schemes, units/sections, owners/members, tenants, leases, suppliers, documents.
• Financials: invoices, credit notes, receipts, levy and rent history, deposits held.
• Balances: opening balances per account and age-analysed arrears at the cut-off.
• Sensitive fields: ID numbers, contact details and banking information — handle under POPIA.

Clean before you import

Raw exports are rarely import-ready. Expect duplicate owners, inconsistent unit references, blank or malformed ID numbers, leases with no end date, and historical balances that don’t tie back to the bank. Do this work in a staging copy of the data, never against a live system, so mistakes are reversible.

De-duplicate people and entities first, because everything else hangs off them. Standardise formats — unit numbering, province codes, date formats and currency stored consistently as cents to avoid rounding drift. Where a record cannot be cleaned with confidence, flag it for manual review rather than guessing. Cleaning is usually the longest phase, and rushing it is where most migrations go wrong.

• Work in a staging copy; keep the original export untouched.
• De-duplicate owners, members and tenants before anything else.
• Standardise unit references, dates, provinces and monetary values.
• Flag uncertain records for review instead of importing assumptions.

Validate and reconcile the financials

Validation answers one question: does the new dataset agree with the old one and with the bank? For schemes, the levy roll and member balances should reconcile to the trust or operating account; for rentals, tenant balances and deposits held should reconcile to the trust account. Reconcile to the cent — small variances usually signal a real mapping or rounding error, not noise.

Trust money deserves particular care. Property practitioners are generally subject to strict trust-accounting duties under the Property Practitioners Act, and deposits held belong to tenants or owners, not the agency. Migrating an incorrect deposit or opening balance is not just an accounting slip; it can become a compliance and trust-integrity problem. Validate that every deposit held in the new system matches the amount actually held in the bank.

Build a short reconciliation pack: total owners and units before and after, total arrears, total deposits, and a per-account opening-balance comparison. If a figure won’t reconcile, quarantine the affected records and resolve them before go-live.

• Reconcile member, tenant and supplier balances to the bank, to the cent.
• Confirm deposits held match the actual trust-account holdings.
• Produce a before/after reconciliation pack covering counts, arrears and balances.
• Quarantine anything that won’t tie out rather than forcing it through.

Run the old and new systems in parallel

Parallel running is the safeguard that catches what reconciliation alone misses. Process at least one complete billing or levy cycle in both systems and compare the outputs: invoices raised, receipts allocated, statements produced and closing balances. Differences point you straight to mapping errors, missing transactions or configuration mistakes while the old system is still the source of truth.

Keep stakeholders informed during this window. Owners, trustees and tenants should not receive duplicate or contradictory statements, so decide which system issues communications during the overlap. The discipline of running both and proving they agree is what turns go-live from a leap of faith into a formality.

• Run a full cycle in both systems and compare statements line by line.
• Decide which system issues owner/tenant communications during the overlap.
• Use any discrepancy as a signal to investigate mapping or config, not to paper over.
• Only progress to go-live once the cycle reconciles cleanly.

Go-live and decommissioning the old system

Go-live should be the quiet end of a process, not its riskiest moment. Confirm the reconciliation pack is signed off, switch billing and communications to the new system, and announce the change to owners, trustees and tenants with clear contact points. Run the first live cycle with extra scrutiny and a rollback understanding in case something material surfaces.

Do not delete the old system immediately. Keep it accessible read-only for a defined retention period so you can answer historical queries, support disputes and satisfy record-keeping expectations under scheme and trust-accounting rules. When you do decommission, dispose of personal information responsibly in line with POPIA, removing working copies and exports that are no longer needed.

• Sign off the reconciliation pack before switching live billing.
• Communicate the change and watch the first live cycle closely.
• Retain the old system read-only for historical and dispute queries.
• Dispose of leftover personal data responsibly under POPIA.

How Regalis is designed to support migrations

Regalis is built around the South African reality that migration is mostly a financial and compliance exercise. It supports structured imports of properties, units, leases, owners, levy and rent history, with column mapping so messy exports can be matched to the right fields rather than reformatted by hand. Opening balances and deposits held are designed to post as idempotent entries, so re-running an import generally does not double-count.

The platform separates trust accounting from operating funds and posts financial activity through a journal-based ledger, which makes the before-and-after reconciliation that migrations depend on more straightforward. Records that cannot be cleaned confidently can typically be flagged for manual review rather than blocking the wider import, reflecting the principle that one bad row should never stop a migration. As always, validate imported figures against your own records before relying on them.