How to migrate to new software without losing data

What to actually migrate: four categories of data

Not all condominium data carries the same weight in a migration. It helps to separate four categories and treat each with a different priority.

Registries (owners, units, suppliers, the property manager) are the foundation everything else rests on: if a name or a tax code is imported incorrectly, the error propagates into statements and communications. Ownership shares and any special apportionment tables (stairwells, elevator, heating) must be checked line by line, since they derive from an apportionment deed and a single transcription error distorts every subsequent cost split, with real consequences under the expense apportionment rules of the Italian Civil Code (articles 1123 and 1124). Account balances (each owner's credit or debit position at the cutover date) are the most delicate item: they should be imported as an opening balance, never rebuilt by summing historical transactions one by one, to avoid rounding mismatches. Document history (meeting minutes, approved financial statements, active contracts) can either stay archived in the old system or be uploaded as attachments in the new one, with no need to turn it into structured data.

• Registries: owners, units, suppliers, the property manager
• Ownership shares: the main apportionment table and special tables (stairwells, elevator, heating)
• Account balances: each owner's credit or debit at cutover, imported as an opening balance
• Document history: minutes, approved statements, contracts, best kept as attachments

The right sequence: clean the export before you import

The most frequent mistake is importing raw data straight from the old system without an intermediate cleanup step. It is better to export everything into a readable format (spreadsheets or exchange files), review it visually for the most common issues, namely units with no owner attached, ownership shares that do not add up to the expected total, or duplicate owners recorded under slightly different spellings, and fix those before proceeding.

Only then should the import into the new system begin, always starting with registries, then ownership share tables, and finally balances. Importing balances before registries and share tables is the single most common cause of duplicate records: the system automatically creates a placeholder unit for a balance it cannot match, and that phantom unit lingers in reports until someone notices it.

The transition window: how to avoid duplicates

The riskiest period is the one where both systems run in parallel, typically the two or three weeks around the switch. To prevent the same payment or expense from being recorded twice, it helps to set a precise cutover date, communicated to residents as well if the change also affects an online consultation portal, after which every new transaction is entered only in the new system.

A useful safeguard is to freeze the old system to read only right after the final export, so it remains available for reference but nobody can still enter data into it that would later need to be re-imported. For a mid-sized condominium, the technical migration itself usually takes days for the import and one or two weeks for full verification, not months: perceived slowness almost always comes from cleaning up data that accumulated errors over time, not from the import itself.

Checks to run before going live

Before considering the switch complete, the most important check is comparing the total cash balance in the old system at the cutover date against the opening balance in the new one: if they do not match to the cent, there is a missing or duplicated record to find before, not after, communicating balances to residents. It is also worth checking that the sum of ownership shares in each table matches the expected total and that the number of imported units matches the old system.

A final check concerns personal data protection compliance: when switching between two software providers, the outgoing one must guarantee the ability to export the data and, once migration is verified, to delete or return it as set out in the contract and under the General Data Protection Regulation (GDPR), so the same data does not remain live on two platforms longer than needed for verification.

Frequently asked questions