Most small caretaking operations run on a spreadsheet, a shared photo folder, and a person who knows everything. That combination works longer than software vendors like to admit. It fails at a specific point, which is when the person who knows everything becomes a bottleneck or leaves.
By then the operation is busy, and the migration has to happen without interrupting a season. Here is the sequence that works.
Start with the agreements, not the properties
The instinct is to load the property list first, because it is the easiest export. Resist it.
The agreement is what determines every charge. Load properties without agreements and you get a system that knows what exists and cannot bill for any of it, which is worse than the spreadsheet because it looks like progress.
Take the signed agreements, one at a time, and enter each fee schedule as data. Every line, with its rate, its unit, its billing trigger, its seasonal window, its minimum period, and its renewal rate if there is one.
This is slower than an import and it is where the value is, for a reason that has nothing to do with software.
What you will find while doing it
Entering fee schedules as structured data forces you to read them precisely, and precision surfaces problems that have been sitting there for years.
Agreements whose stated annual total does not equal the sum of their lines. Monthly fees with no stated season, so nobody knows whether they run six months or twelve. Two clients on identical scope at different prices for reasons no one remembers. Agreements past their renewal date still billing at introductory rates. Verbal arrangements that never made it into any document.
Every one of those is currently costing money or goodwill. The migration is the first time in years that anyone has looked at all of them at once, and fixing them is worth more than the software.
Verify each one against its own stated totals
Before an agreement goes live, produce the annual programme total from the entered lines and compare it to the figure written in the document.
They should match to the cent. When they do not, one of two things is true: the data was entered wrong, or the agreement contains an arithmetic error. Both are worth knowing, and both are far cheaper to find now than on an invoice.
This check is also the single best test of whether the system models your business correctly. If the software cannot reproduce your own contract's totals, it does not understand your pricing, and you will be fighting it every month.
Then properties, owners, and the current season
With agreements in, load the properties and attach each to its owner. Verify the owner's email individually, because that address determines who receives invoices, and a wrong one fails in the most visible possible way.
Load the current season's schedule and nothing historical. Past invoices stay where they are. Migrating years of history is expensive, delays the cutover, and is almost never consulted.
Run parallel for one cycle, then stop
Do one full billing cycle in both systems and compare the output line by line. Differences are either migration errors or existing errors the spreadsheet was hiding. Both need resolving before you rely on the new one.
Then stop. Running parallel for a second cycle feels prudent and is how migrations die, because the old system stays authoritative and nobody ever fully commits. One cycle to verify, then the spreadsheet becomes an archive.