Switch Gestionale Without Stopping the Studio

A studio changes its gestionale condominiale rarely and reluctantly, and the fear is justified: the old program holds years of registries, balances and fee history, and a rendiconto is due at the end of the year. The point is that the switch does not have to stop the studio. Fees keep falling due, owners keep calling and requests keep coming in, even in the week you change systems.

This guide follows the order in which things happen: what to export, how to clean it, how to carry the balances, how to run the two systems side by side and what can go wrong.

What to export from the old program

Before touching anything, get an export from the old gestionale (Excel is fine) with these lists:

• Buildings. Name, address and whatever else identifies the building.
• Units. Staircase, flat number, surface area. One row per unit, with a code that stays the same in every file.
• Owners. Who owns which unit, co-ownerships included, with phone and e-mail.
• Opening balances. Each owner's balance at a precise date, with the right sign: who owes and who has paid in advance.
• Fee history. It answers an owner who disputes a balance and helps reconciliation. How to bring it into the new system we decide together, case by case.

Of all this Unitify imports apartments, owners and opening balances; nobody re-types balances by hand. The rest we keep as a reference for reconciliation.

Mapping and clean-up before the import

The time lost in a migration is almost never in the import itself: it is in the data nobody ever cleaned. Before you send us the file, check four things.

• Duplicates. The same owner written two ways, or one row per building.
• Units without an owner, or with two owners that are really one co-ownership.
• Codes. If the old program uses a code per owner, keep it in every file: it is what lets you find a row again after the import.
• Balance signs. A debit and a credit must not be mixed up in the export.

A note on millesimi. The millesimal tables remain a matter for the assembly and the rules of the building, and we covered the legal side here. On the software side, splitting by millesimi is not a ready-made rule today: charges are calculated per square meter, per apartment, per resident or as a flat amount. If your studio splits by millesimi, tell us before you start, not halfway through the switch.

Opening balances and the first rendiconto after the switch

Choose a switch date and fix the balances at that date. Then reconcile them: we compare them with your records, so balances match before anyone relies on the new numbers. The condominium bank account remains the reference: every sum received and paid on behalf of the building goes through it (art. 1129 of the Civil Code), and its statements are what you check the numbers against.

The rendiconto condominiale is drawn up every year, and the assembly to approve it must be convened within 180 days (arts. 1130 and 1130-bis of the Civil Code). If the switch falls mid-year, that year's rendiconto will have two sources: the old program's export up to the switch date and Unitify from then on. That is not a legal rule, it is organization, and it is worth choosing the switch date with it in mind, for example at the start of a management year or at the end of a quarter.

For how the rendiconto is built and how to read it next to the preventivo, see Italian condominium accounts: preventivo vs consuntivo. The regulation and its millesimal tables travel with the building's data: what the regulation contains is in Italian condominium regulation: contents and approval.

Side by side, or mirroring

Once you give us access, we move you over within one week. Or Unitify runs on top of your current system and mirrors its data, so you do not have to switch everything at once.

There are four steps: you share access or exports; we import and reconcile; a trial period alongside, or mirroring mode; then you switch.

During the parallel period compare owner by owner, not on totals: two equal totals can hide two errors that cancel out. The normal differences are few (rounding, booking dates), and a real error usually shows at once on a single row. Switch when the rows agree, not when you are tired of keeping two programs open.

What can go wrong

• The millesimal tables. If the split by millesimi is the core of your calculation, the new system does not replicate it by itself: it has to be decided beforehand.
• Different structures between programs. One program keeps ordinary and extraordinary management or the funds apart, another does not. The file you export shows how entries are grouped: check that nothing ends up in a single balance unless you want it.
• Old contacts. Outdated phone numbers and e-mail addresses send notices and reminders into the void. The switch is the right moment to clean them.
• The wrong switch day. Changing system the day before a due date or an assembly is the most expensive choice.

An honest note on language

Today the app does not have an Italian interface yet. Text fields are free, so notices, messages and replies to owners are written in Italian; the interface you use and the one the owner sees are not, not yet. It is better to know before choosing.

How it is done in Unitify

The free plan is a real plan, not a trial: you can add your first building and see how it behaves with your data. To load the rest, send us the building registry (apartments, owners and opening balances) as an Excel file or an export from your current system; we transfer the data and set everything up with you. The price list is on pricing, and we keep the picture of the Italian market on the Italy page. What a gestionale has to do, from daily work to the assembly, we set out here; the comparison with free tools and Excel here.

If you are weighing the switch, book a demo and bring an export of your program: you will see your own data in the new system before you decide.