Getting your data out of your old software

The question that decides every software change in condominium management is not "what can the new one do". It is: can I get my data out of where I am now?

And it is almost always asked too late — once the contract with the new vendor has been signed. This article reverses the order.

Request the export before you do anything else

That is the whole trick, and it costs you one email. Before you watch demos, before you compare, before you decide anything: ask your current vendor for a complete data export.

Not as a threat, 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 — only reports as PDF, which is worthless for a migration.
2. How long it takes. Two days or six weeks makes the entire difference to your planning.
3. What is missing. And that is the real point.

A vendor who stalls on the export will not be a pleasure on anything else either. And you find 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 hand work is why 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 calculates
• 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 a 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. The three classics:

PDF instead of data. An annual statement as a PDF is a document, not a data source. Fine for filing; useless 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. For an opening balance that is entirely fine — you just need to know you will not be able to trace prior years from it. Discovering that after the migration leaves you with something to explain to 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 still resolves.

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 not an import, it is a leap. The dry run reads the same file and does the same arithmetic, but writes nothing — and hands you 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. Checked against the declaration of division, not against memory.
• Sum of opening balances. Must match the account balance at the cutover date.
• Owners with no unit, and units with no owner. Both occur, and both are a data error rather than a special case.

Only once that reconciliation is right do you commit. Condomana is built exactly that way: dry run, read the reconciliation, then commit — and re-importing creates no duplicates, 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: a column means exactly one thing, and whatever does not fit is visible.

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 into the importer — you map the columns once and the importer does the rest.

One note we will not skip: those mappers ship as Beta with us at first. Not as a hedging word, but because every vendor export looks different, and the first run against a new format is where you find out what that vendor does differently than expected. The reconciliation report is therefore not a formality — it is where you see it.

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 one is enough, except for resolutions and contracts.

The most common reason a migration peters out is the attempt to re-enter five years of accounting. That is not a migration, it is a second set of books.

And the way back out

One last point that gets forgotten 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 is a statement about the relationship they have in mind. A complete export, at any time, in the same format as the import, should be a given — your data is yours.

How this fits into a sensible order: the honest roadmap to going digital.