Property-software implementation checklist

Stage 1 — Scoping: agree what 'done' looks like

Scoping defines the boundaries of the project before any data moves. The goal is a shared, written understanding of which entities you are bringing on (schemes, HOAs, rental mandates), which modules you need, the migration cut-over date, and what success looks like. Vague scope is the most common reason implementations drift.

For a South African managing agent, scoping should explicitly capture your fiduciary obligations. Trust accounting under the Property Practitioners Act 22 of 2019 generally requires you to keep clients' money separate and reconcilable, and community-scheme work brings CSOS Act 9 of 2011 and STSMA (Act 8 of 2011) obligations into view. Naming these up front means the configuration stage is designed to support compliance rather than retrofitted to it.

• List every legal entity, scheme and mandate in scope — and anything deliberately excluded.
• Set a firm cut-over date and a fallback date.
• Identify your internal project owner and the vendor's implementation lead.
• Confirm which reports and statutory outputs must work on day one.

Stage 2 — Data collection: gather the source of truth

Data collection is where you assemble the records the new system will be built on. This typically means owner and tenant registers, the levy roll for each scheme, lease agreements and terms, opening trust balances, arrears positions, supplier and beneficiary details, and any historical transactions you need to retain. Collect from your current system's exports, your bank, and your paper or spreadsheet records.

This stage is overwhelmingly a customer responsibility, because only you can vouch for what is correct. A vendor can format and load data, but it cannot tell you whether an owner's balance is genuinely R4,212 or a stale figure. Decide early how much history to migrate — opening balances plus a defined window of transactions is usually enough, and dragging in years of unreconciled history often imports problems rather than value.

Stage 3 — Import and validation: reconcile to the cent

Import is the mechanical loading of your collected data; validation is the disciplined check that what came out matches what went in. The vendor generally runs the import using mapping templates, but validation is a joint exercise and the sign-off is yours. Trust balances, levy rolls and arrears should reconcile exactly — a tolerance of 'close enough' is not appropriate for clients' money.

Build validation as a packet-based process rather than all-or-nothing: load in batches, check each batch, and quarantine rows that fail rather than letting one bad record block the whole migration. Confirm control totals (total owners, total monthly levy, total arrears, opening cash) against your source system and your bank before you accept the import. Only sign off when the numbers tie out and you have a written record of any exceptions.

• Reconcile opening trust cash to the bank statement.
• Tie levy roll totals to your current billing.
• Match arrears balances owner-by-owner for a sample, totals for the rest.
• Keep a documented exceptions list with an owner for each item.

Stage 4 — Configuration: set up the system to match your operation

Configuration shapes the software to how you actually run — fee structures, levy and rental billing cycles, chart of accounts, document templates, user roles and approval workflows. This is primarily vendor-led with your input, because the vendor knows the system's options and you know your business rules. The output should be a configuration that is designed to support your statutory obligations, not just your convenience.

Pay particular attention to roles and permissions. Trustees, managing agents, accounts staff and tenants should each see only what their role requires, which supports both good control and POPIA's expectation that personal information is accessed on a need-to-know basis. Lock down trust-account postings and approval thresholds here so that controls are built in rather than bolted on after go-live.

Stage 5 — Training: build competence before cut-over

Training prepares the people who will use the system day to day. Effective training is role-based — accounts staff need the receipting and reconciliation flows, portfolio managers need the levy and lease workflows, and trustees or landlords need their portal and reporting views. Generic 'here is every button' demos generally leave staff under-prepared for their real tasks.

Train on a copy of your own migrated data where possible, not a blank demo environment, so the screens look familiar from day one. Schedule training close to go-live so the knowledge is fresh, and identify internal 'super-users' who can support colleagues once the vendor steps back. Record the sessions where you can, so new staff and refreshers do not depend on rebooking the vendor.

Stage 6 — Testing: prove the workflows end to end

Testing exercises the configured system with real scenarios before you commit. Run a full cycle in a test or staging environment: raise a levy or rent invoice, receipt a payment, allocate it, generate a statement, run a trust reconciliation, and produce the reports trustees or owners expect. The point is to surface gaps while they are cheap to fix.

Build a short test script covering your highest-volume and highest-risk flows — receipting, allocations, arrears letters, supplier payments and trust reconciliation — and have the people who will own each flow run it themselves. Treat any failed test as a blocker until resolved. This stage is shared: the vendor fixes configuration or data issues, and you confirm the outcomes match your expectations.

Stage 7 — Go-live: cut over with a clean break

Go-live is the controlled switch from your old system to the new one on the agreed cut-over date. The cleanest approach is a defined freeze: stop posting in the old system, take final balances, confirm they match the migrated opening balances, and begin live processing in the new system. A clear break avoids the confusion and reconciliation drift of running two systems in parallel indefinitely.

Plan go-live for a quiet point in your billing cycle where practical, and have the vendor on standby for the first live run. Communicate the change to staff, trustees, landlords and tenants in advance — especially anything that affects how they receive statements or make payments. Keep your old system available read-only for a defined period so you can answer historical queries without reopening it for posting.

Stage 8 — Post-launch: stabilise, then optimise

Post-launch covers the weeks after go-live when issues surface under real load. Expect a hypercare period of closer vendor support, an early reconciliation to confirm the first live cycle balanced, and a backlog of small refinements. Capture issues in one place and triage them rather than reacting ad hoc.

Once the core is stable, this is when you switch on the modules you sequenced for later — owner and tenant portals, AGM and meeting tools, advanced reporting, and any compliance dashboards. Schedule a review at 30 and 90 days to confirm the system is delivering what scoping promised, and revisit training for anything staff are working around rather than using as intended.

Customer vs vendor responsibilities, and sequencing modules

As a rule of thumb, the vendor owns the mechanics — import tooling, configuration, system training and technical fixes — while you own the truth: supplying accurate data, validating it, signing off reconciliations, and confirming workflows match your obligations. Disputes during implementation almost always trace back to an unwritten assumption about who owned a task. Put the split in writing during scoping.

Sequence modules so the financial base is solid before you build on it. A typical order is: core registers and the general ledger first; trust accounting and reconciliation next; then billing and collections (levies, rent, arrears); then portals for owners, tenants and landlords; and finally meetings, document management and advanced reporting. Standing up portals before the ledger reconciles generally just exposes wrong balances to the people most likely to complain about them.