Leaving your old software: how to take your data with you

What decides every software change in condominium management in the end is one question: can I get my data out of the system it sits in now?

That question is almost always asked too late, once the contract with the new vendor has already been signed. It pays to turn the order round.

Request the export before you do anything else

It costs you no more than one email. Before you watch demos, compare alternatives or decide anything, ask your current vendor for a complete data export.

Treat the request as a test. What comes back tells you three things:

1. Whether it is possible at all. Some systems have no export worth the name. They only produce reports as PDF, and those are worthless for a migration.
2. How long it takes. Whether it is two days or six weeks changes your whole plan.
3. What is missing. That matters most.

A vendor who already stalls on the export will not be much of a pleasure on anything else either. This way you find that out while you have signed nothing.

What a complete export must contain

Check the export against this list. Anything missing you will have to enter by hand later, and that manual work is where migrations get abandoned.

Master data

• Buildings with address and designation
• Units per building, with number and location
• Co-ownership share (Miteigentumsanteil) per unit; without it nothing can be calculated
• Owners with contact details
• since when an owner has held a unit, and where ownership changed: until when

That last point is the one most often missing. Many systems store only the current owner. Without the date of change you cannot correctly apportion the statement for a year in which a unit was sold. And those are precisely the cases where somebody checks the arithmetic.

The figures

• Opening balances per building and per unit, at the cutover date
• Cost types with their distribution key
• The resolved advance payments (Hausgeld) per unit
• Outstanding items per owner
• Reserves, shown separately

The history

• The last annual statements, at minimum as documents
• The register of resolutions (Beschluss-Sammlung), complete and with its numbering
• Contracts, insurance policies, declarations of division

The difference between "exported" and "importable"

An export can be formally complete and still unusable. Three cases come up again and again.

PDF instead of data. An annual statement as a PDF is a document and not a data source. That is fine for filing, but not for carrying balances across. Ask explicitly for CSV, XML or a database extract.

Balances without provenance. "Unit 12: €1,847.32" is a number, not a booking. As an opening balance that is entirely fine; you just need to know that you will not be able to trace prior years from it. If you only discover that after the migration, you will have to explain it to the owners.

Number ranges that only mean something internally. Resolution numbers, document numbers and building keys are often tied to the old system. They have to survive the import, or no cross-reference in your minutes will still match.

The way in: dry run first, then commit

For the import itself there is one rule you should not bend: every import runs as a dry run first.

An import you cannot look at beforehand is a leap in the dark. The dry run reads the same file and does the same arithmetic, but writes nothing. You get a reconciliation you can read before anything happens.

What to check in it:

• Sum of co-ownership shares. It must match the total in the declaration of division, usually 1,000 or 10,000. If it does not, a unit is missing or one is duplicated.
• Number of units per building. Check it against the declaration of division, not from memory.
• Sum of opening balances. It must match the account balance at the cutover date.
• Owners with no unit, and units with no owner. Both occur, and in both cases you should assume a data error rather than a special case.

Only commit once that reconciliation is right. Condomana is built that way: dry run, read the reconciliation, then commit. Re-importing creates no duplicates, because it recognises what is already there. That matters more than it sounds, because you will import twice. Something is always missing the first time.

If you would rather not build the CSV yourself

The canonical-CSV route is the most reliable one because it guesses nothing. Each column means exactly one thing, and whatever does not fit stands out.

Hardly anyone wants to build such a file by hand, though. That is what guided mappers are for: they read an export from a particular predecessor system straight in. You map the columns once and the importer does the rest.

Those mappers ship as Beta with us at first. There is a practical reason: every vendor export looks different, and only the first run against a new format shows what that vendor does differently than expected. It becomes visible in the reconciliation report, which is what the report is for.

What you do not need to bring

Just as important as the list above is the list of what you can safely leave behind:

• Booking history of earlier years. Opening balances are enough. The old statements remain valid even though they came out of another system, and nobody requires you to re-enter them.
• Internal notes and reminders. They are tied to working habits you are in the middle of changing.
• Old document versions. The current version is enough, except for resolutions and contracts.

Migrations most often peter out because someone tries to re-enter five years of accounting. Whoever does that ends up running a second set of books.

And the way back out

One last point tends to get lost during a switch, because you are simply glad to have arrived: ask the new vendor what you asked the old one.

How do I get out of here? In what format? Does it cost anything? Is it tied to the subscription?

If a vendor releases the export only for a fee, only on request, or only while the subscription runs, that says something about the relationship they have in mind. A complete export, at any time and in the same format as the import, should be a given, because it is your data.

How all of this fits into a sensible order is in the five-step roadmap to going digital.