Practical guide
Migrating historical data to new software
Switching property management software is delicate: you risk losing historical statements, mismatching resident balances, or duplicating registries that already exist. An orderly migration follows a precise sequence: building and resident registries first, then apportionment tables, then opening balances checked against the last approved statement, and finally historical documents. Each step should close with a reconciliation check before moving to the next, because an error in the tables propagates into every later apportionment. This guide describes the correct order, what to verify at each stage, and how to avoid the duplicates that appear when several data sources merge into the same archive.
Registries: building, residents and units
The first block to transfer is the basic registry: building data (tax code, address, current manager), the list of units, and resident records with their legal rights (ownership, usufruct, bare ownership). This is the moment to correct historical errors that have lingered for years, such as incomplete names or co-ownerships recorded incorrectly, since they directly affect the validity of meeting notices.
A typical duplicate appears when the same resident shows up twice under slightly different spellings of the name, or when a unit is linked to two different owners at different times, for example after a sale that was never properly recorded. Before importing, export the list from the old software, sort it by tax code, and check for duplicate values: it is the fastest and most effective check available.
Apportionment tables: the basis for every future cost split
Apportionment tables, general ownership, stairs, elevator, heating, and any use based tables, must be imported together with the approval date and the meeting resolution reference, not just the numeric values. Without that reference, if the table is ever challenged there is no way to demonstrate it was legitimately adopted, since Italian civil law requires cost apportionment to follow properly approved ownership shares.
Always check that the shares in each table add up to the expected total: a rounding error carried over unchanged from the old system generates small discrepancies that accumulate statement after statement and become very hard to trace years later.
Opening balances: the most delicate part of the migration
Each resident's opening balance, whether owed or overpaid, must match exactly the accounting position resulting from the last statement approved at the meeting. Simply transferring a number is not enough: it has to be checked line by line against the previous statement, because an error here affects every subsequent reminder and cost installment.
A reliable method: after the import, sum all debit balances and subtract all credit balances of residents, then compare the result against the building bank and cash balance at the same date, consistent with the legal requirement to keep building funds in a separate account. If the two figures do not match, the error must be found before moving forward, not left for year end.
Past statements and documents: what to keep and how to link it
Statements from previous years should be kept as consultable documents, not necessarily recalculated in the new system, and linked to the building record with the reference year clearly indicated. This guarantees historical continuity if a resident requests access to the records, a right recognized under Italian condominium law.
It is also useful to import meeting minutes from recent years, ongoing supplier contracts, and the updated resident register: these are the documents most often requested during a change of manager or a review by a new resident.
Final verification before going live
Before considering the migration complete, it is worth running the old and new system side by side for a month on a trial statement, comparing total spend by category, the apportionment for each resident, and the cash balance. This short but real parallel run period is the most concrete way to catch a duplicate or a table error before it ends up in an official statement.
AmministraPro supports structured import of registries, apportionment tables and historical balances with built in reconciliation checks, so managers can verify totals during import rather than discovering an inconsistency months later. Anyone evaluating the switch can review the features and pricing on AmministraPro to understand how to plan the migration with their own archive.
Frequently asked questions
How long does it take to migrate a building's historical data to new software?
It depends on the number of units and the years of history to link, but the real work is not the technical transfer, it is the verification: rechecking registries, apportionment tables and opening balances against the last approved statement usually takes longer than the import itself. For a medium sized building, between import and reconciliation checks, it is realistic to expect several days of actual work, not necessarily consecutive.
What if the old software does not allow exporting data in a readable format?
If a structured export is not available, the alternative is to manually rebuild registries and balances from the last statement approved at the meeting, which remains the legal reference document for the accounting position anyway. It is slower but safer than attempting a partial or unverified extraction, because a wrong value imported automatically is often harder to spot than one entered manually with direct verification.
How do you avoid duplicate residents after migration?
The most effective approach is to sort the exported list by tax code before importing: two rows with the same tax code almost always signal a duplicate, even if the name is spelled slightly differently through abbreviations, capitalization, or spacing. A second useful check is verifying that each unit has only one active owner as of the migration date, unless a genuine documented co-ownership exists.
Should previous years' statements be recalculated in the new system?
No, they do not need to be recalculated: statements already approved at the meeting are closed documents and should be preserved as such, linked to the building record with the relevant year. Recalculating them risks producing figures different from those approved by the meeting, affecting their legal validity. The new software should start from an opening balance consistent with the last statement, not rewrite the past.
Who should be responsible for verifying the migrated data?
Responsibility for the accuracy of accounting data remains with the current manager, who can delegate the technical import work to their own staff or to the new software provider's support team. It is still advisable that the manager, or someone they trust who knows the building's history, validate the opening balances and apportionment tables before going live, since they are the only ones able to recognize an anomaly against past statements.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.