Setup Wizard & CSV Import: Moving a Community Without Data Loss

The setup wizard is not just a "create new record" screen

When a management firm switches to a new community platform, the step people underestimate most isn't buying a license or training the team — it's the first data migration that runs through the setup wizard. Managers tend to picture it as typing unit numbers into an empty system. In practice, setup is the moment where years of balances, meter readings and resident details scattered across spreadsheets and paper ledgers finally have to agree with each other, in one pass. Rush that step, or skip it, and the new system starts carrying the old system's mistakes from day one.

The real problem is almost never the software — it's data quality. If a unit's balance shows three different numbers in three different files, a well-built import flow doesn't make that conflict bigger, but it won't hide it either: it surfaces the mismatch right at setup time and puts it in front of the manager. That's the actual difference a good wizard makes — whether you catch the problem before go-live, or three months later while arguing with a resident about their bill.

What actually needs to move

Standing up a new community means migrating records that depend on each other, not a single flat list:

• Blocks and units. How many blocks, how many units per block, each unit's floor area and land share — get this wrong and cost allocation is broken from the first invoice run.
• Residents and owners. Who owns, who rents, how many people live in each unit; missing contact details mean announcements and payment reminders miss their target from day one.
• Opening balances. Each unit's debt or credit as of the cutover date; if this figure is wrong, every collection report is unreliable for the first month.
• Meter indexes. Water, gas or shared-area meter readings at the cutover date; skip this and the next billing period has to split consumption by estimate.
• Parking and access-card assignments. Which bay belongs to which unit, which card belongs to whom; import this incompletely and the guard post spends its first weeks managing exceptions by hand.

The order matters. Structure (blocks and units) has to land first, then residents, then balances and meters, and access records last. Reverse the order — try to import balances before residents exist — and the system has nothing to attach the balance to.

How the CSV import actually works

The setup wizard and CSV import module inside Site-Park asks for these records one at a time, in sequence, rather than all at once. A manager downloads the block-and-unit template first, reshapes the existing spreadsheet to match it, and uploads the file. On upload, every row gets validated: a missing unit number, a duplicate record, a negative floor area — these show up on screen before anything is written. Not a single record lands in the database until those errors are resolved.

The same validation logic applies to resident, balance and meter files. If a balance row references a unit number the system doesn't recognize, that row is flagged as unmatched rather than halting the whole batch — only that row waits for manual review. This design choice matters in practice: a single bad row in a file of several thousand doesn't force you to restart the entire import.

Once an import finishes, the system shows a summary — units, residents, total opening balance. That summary should be checked by hand against the source file's own totals. The wizard validates structure, but it has no way to catch an error baked into the source data itself, like a balance that was miscalculated before it ever reached the spreadsheet.

Bring the full ledger, or start from an opening balance?

The decision managers argue over most during setup is whether to migrate every historical accounting entry or start clean with just a current opening balance. For most communities, the second option is the sounder one: old ledgers stay archived as PDF or spreadsheet exports, and the new system only records the net balance as of the cutover date. That approach both lowers import risk and keeps any errors buried in the old system from following it into the new one.

Migrating the full transaction history is only worth the effort in specific cases — for example, when an audit or legal proceeding is expected soon and having every movement visible in one system is genuinely useful. Even then, importing period totals rather than individual transactions keeps both the migration and later reporting simpler.

A data-cleanup checklist before you build the file

Running source data through these checks before preparing the import file cuts down the number of errors the wizard will flag:

• Make sure unit numbering follows one consistent scheme (a stable code, not "Block A Floor 3 whatever the tenant calls it") across every source file.
• If the same resident's name is spelled differently across files, reconcile it to one spelling before import.
• Flag vacant or inactive units in advance (for sale, for rent, empty); this status feeds directly into how exemption and discount rules get applied correctly.
• Cross-check opening balance figures against the current bank statement and the latest collection records once, line by line — doing this after go-live is far harder.
• Record meter indexes from a reading as close to the cutover date as possible; using one from months earlier guarantees a dispute at the next billing cycle.

Where setup time actually goes

A community usually goes live through the setup wizard within a few days, assuming the source data is clean. But most of that time is spent on the data-cleanup steps above, not on the software itself. Many managers get this balance backwards: they ask how fast the software can be set up, then leave data preparation to the last few hours before cutover. The result is a setup that finishes quickly on paper and a first month full of correction requests.

A sounder plan sets aside one to two weeks before the cutover date purely for data cleanup, and runs the CSV files through the system once as a dry run before the real import. The validation screen's error list tends to surface problems in the source data that nobody had noticed yet. It's the same lesson that keeps showing up in SaaS migration projects generally: a pilot run before go-live is the cheapest debugging you'll ever do.

If you're not sure how data migration will go for your next community setup, get in touch and we'll walk through Site-Park's setup wizard and CSV import flow together.