Software choice
Mistakes to avoid when migrating software
Most migration problems come not from the software but from avoidable method mistakes. Switching software looks like a technical operation, but the real risk is carrying the old system's errors into the new one, or introducing new ones with hasty, untested imports. The result is wrong splits, reminders to people who have already paid, tables that do not close and document archives with gaps that surface only when precisely that document is needed. This guide gathers the most common mistakes seen in software switches and, for each, the practical measure that prevents it, so you approach the migration with a checklist instead of the hope that it will go well.
The ten mistakes not to make
- Importing dirty data without a preliminary cleanup of duplicates and contacts
- Leaving units with no linked owner, which then receive no instalments
- Loading only the general table and forgetting the special tables
- Counting receipts already on the books twice when migrating mid-year
- Migrating right before meetings or year-end closings
- Not keeping the export and a safety copy of the old data
- Dumping documents into a single folder with no structure
- Treating electronic invoices as mere PDFs with no tax value
- Skipping the test with a trial split and account reconciliation
- Not training the office, wasting the new software's features
Carrying the old system's dirty data into the new one
The most widespread mistake is treating migration as a simple transfer: you export from the old and import into the new, duplicates included. The result is an archive that is born disorderly, with the same owner present twice, obsolete contacts and suppliers written with different spellings. Migration is instead the ideal chance to clean up the data.
The measure is simple: cleanup is done first, on the source files, not afterwards in the new system. Consolidate duplicates using the tax code as the key, separate email and certified email, check that every unit has an owner. Fixing at source costs a fraction of the time compared with tidying downstream across hundreds of already loaded positions.
Getting the thousandths tables wrong
Tables are the criterion for splits and an error here propagates to every expense. The typical mistakes are two: importing only the general table while forgetting the special ones for stairs, lift and heating, and loading tables that do not close to one thousand. In the first case everyone is charged for expenses owed by only some, in breach of the criteria of Articles 1123 and 1124 of the Italian Civil Code.
The measure is the balancing check on every table and verification with a test split. You record a known expense for each table and compare the result with the old system's last split: if the quotas match, the tables are correct. This comparison must be run on the special tables, not just the general one, because that is where the errors hide.
Double counting in accounting
When migrating mid-year, the error that distorts balances is counting the same amount twice: recording as a new movement a receipt already included in the opening balance, or splitting an expense already charged. The owner then sees a debt they do not have, or the account does not match the bank.
The measure is the single-euro rule: every amount appears only once, within the opening balance or as a movement after the switchover date, never in both. The final check is reconciliation with the dedicated bank account required by Article 1129 of the Italian Civil Code: if the reconstructed accounting balance matches the bank one, there is no double counting.
Choosing the wrong moment and keeping no copies
Migrating right before the meetings season or the year-end closings turns every small hitch into a delay towards owners. The measure is to choose a calm window of the year, ideally the switch between two financial years, so that settling in does not weigh on imminent deadlines.
The other mistake is not keeping the complete export and an untouched copy of the old data. If something in the import goes wrong, without a safety net you are left without the original data. The copy must be kept before starting and left untouched: it is the only guarantee of being able to restart in case of problems, besides covering the ten-year document retention obligation set by Article 1130 bis.
Skipping the test and not training the office
The last group of mistakes concerns the rush to declare everything ready. Skipping the test means discovering the problems when the system is already in use: the most insidious errors, a table that does not close or a doubled receipt, are not visible at a glance but only with a test split, account reconciliation and a document completeness check.
Finally, even a technically perfect migration delivers little if the office does not know how to use the new software: features go unused and old habits return. The measure is to plan training together with go-live, focusing on recurring processes. Software like AmministraPro reduces these risks with assisted import, balancing checks and testing tools; the /funzioni page describes the features and /prezzi lists the plans for planning the switch.
Frequently asked questions
What is the most costly mistake in a software migration?
Accounting double counting when migrating mid-year, because it distorts owners' balances and the reconciliation with the bank, generating reminders to those who have already paid or non-existent credits. It is prevented with the single-euro rule, every amount only once, and with the final reconciliation of the dedicated bank account: if the accounting balance matches the bank statement, there are no duplications. It is the check that safely closes the transfer of the financial part.
How do I avoid transferring the old archive's duplicates?
By doing the cleanup first, on the source files, not afterwards in the new system. You consolidate owners using the tax code as the key, so the same person appears only once linked to all their units, you separate email and certified email, and you check every unit has an owner. Cleaning at source takes a fraction of the time compared with correcting hundreds of already loaded positions downstream in the software.
Why is it risky to migrate during the meetings season?
Because in that period accounting is at its busiest and every migration hitch immediately affects deadlines and communications towards owners. The settling-in period that follows any software change, with its normal residual corrections, weighs far more if it falls right before meeting notices and year-end closings. It is best to choose a calm window, ideally the switch between two financial years, to absorb the adjustments without pressure.
Should I keep the old software after migration?
Yes, at least read-only for the history, together with the complete data export kept as a safety copy. It serves both as a safety net in case of import problems and to comply with the ten-year retention obligation for supporting management documents set by Article 1130 bis of the Italian Civil Code. The copy of the old data should be prepared before starting and left unmodified, so you can restart from the original data if something goes wrong.
Is importing the data well enough, or do I also need to train staff?
Both are needed. A technically correct migration delivers little if the office does not know the new software's flows: features go unused and old habits return, wasting the change. Training should be planned together with go-live and focused on recurring processes, recording invoices, issuing instalments, reminders and meeting notices. Identifying an internal reference person who becomes the first expert helps the rest of the team during settling in.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.