Most agencies that try to leave spreadsheets do it twice. The first attempt imports the list of units and tenants, starts billing, and discovers within a fortnight that half the tenants dispute their opening balance. The spreadsheet comes back out "just for now", and two systems run side by side until somebody gives up on one of them.
The software is rarely the reason. The reason is that a list of tenants is not a set of books. What has to move across is not who lives where, but who owes what, who has paid ahead, whose deposit you are holding, and what you owe each landlord, all as of a single date that everybody agrees on.
Pick a cutover date, and make it a month end
Everything in a migration hangs off one date: the day the old records stop and the new ones start. Make it the last day of a billing period. The month's rent has been billed, most of it has been paid, and the spreadsheet has a natural closing position.
Do not pick the busiest week of the collection cycle. If most of your tenants pay in the first five days of the month, a cutover on the 1st means the first week in the new system is also the week with the most payments to match.
Tell staff the date three weeks ahead. From that date, nothing is recorded in the spreadsheet.
What has to move across
In order of how much trouble each causes when it is wrong:
1. Opening balance per tenant. What each tenant owed, or had paid in advance, at the close of the cutover date. One figure per tenancy, signed off. If you only get one thing right, make it this.
2. Deposits held. Every deposit, against the tenancy it belongs to, at the amount actually received. A deposit that does not come across is a deposit you will be asked to refund from your own pocket at move-out.
3. Landlord balances. What you owe each landlord as of the cutover, and any amounts you have paid ahead or deducted. This is where the landlord remittance for the first month in the new system either reconciles or starts an argument.
4. Unallocated money. Payments received that you have not yet matched to anybody. Do not guess them onto an account to make the spreadsheet tidy. Bring them across as unallocated payments and resolve them in the new system, where the queue is visible.
5. Units, leases and charges. Rent amounts, lease dates, what is billed besides rent, and the last meter reading for every metered unit. The last reading matters: without it, the first water bill in the new system has no starting point.
6. People. Tenant contacts, landlord contacts and bank details for remittance.
What you do not need to import is every historical transaction. Bring opening balances across, archive the spreadsheet read-only, and keep it. Trying to re-enter three years of payments transaction by transaction is how a migration becomes a six-month project.
Clean the balances before you move them
The worst thing a migration can do is carry a wrong number into a system that will then present it with confidence on a receipt.
Before the cutover:
- Reconcile the last full month against your M-Pesa and bank statements. If you have not been doing this, start with the method in reconciling M-Pesa rent payments.
- Age the arrears. Anything owed for longer than a few months is worth a look before it gets imported. Some of it is real. Some of it is a payment that was never recorded. Arrears ageing explains how to read the list.
- Check deposits against bank records, not against what the lease says was due.
- Agree the landlord balances with each landlord in writing, even a single line by message.
Run one cycle in parallel, then stop
For the first billing period after cutover, run the bills in the new system and check a sample against what the spreadsheet would have produced. Do the first billing run as a preview, before anything is sent to tenants. A wrong rent amount found in a preview is a correction. The same mistake found by fifty tenants is a week of phone calls. Running a billing run has the full checklist.
Then stop the parallel run. One cycle is enough to catch a systematic error. Two cycles mean double the work, and by the third nobody is sure which system is the record.
Tell tenants what changes, and only that
Tenants do not need to know you have changed software. They do need to know if anything they do changes:
- A new paybill or account reference. If you are moving from a till number or from free-text references to structured account numbers, this is the moment, and it is worth the effort. The reasons are set out in paybill vs till number for rent.
- Their opening balance. Send each tenant their balance as at the cutover date, with an invitation to query it within a fixed window. Disputes raised in week one are cheap. Disputes raised at move-out are not.
- Where receipts and statements now come from.
Give each person their own login
The migration is the moment to stop sharing one password across the office. Each person's actions should be attributable to them: the cashier who receipted a payment, the manager who approved a waiver, the caretaker who logged a repair. A shared login makes the audit trail meaningless at exactly the point you start relying on it.
Agree who can do what before go-live. In most agencies the person who records payments should not be the person who can delete them.
What goes wrong
Balances imported but never signed off. Nobody can later say whether a disputed figure was wrong in the spreadsheet or wrong in the import.
Deposits left out because they are "not rent". They are a liability you hold, and they belong in the books from day one. See client account.
Historic transactions re-keyed by hand. Weeks of work, and every typo becomes a dispute.
The spreadsheet kept "live" for a few people. Two records means no record.
Cutover in the middle of collection week. The busiest week, in an unfamiliar system, with balances nobody has checked yet.
Common questions
How long does it take to move from Excel to property management software?
For a small to mid-sized agency, the work that matters is a few days of cleaning balances before the cutover date and one billing cycle in parallel afterwards. Most of the elapsed time is reconciling the old records, which is worth doing whatever software you choose.
Do I need to import all my old rent payments?
No. Import an agreed opening balance per tenant as of the cutover date and keep the old spreadsheet, read-only, as the historical record. Re-entering old transactions is slow and introduces errors.
What should I do with payments I cannot match to a tenant?
Bring them across as unallocated payments and resolve them in the new system. Guessing them onto an account to tidy the spreadsheet moves the problem into the new records with no trace of where it came from.
Should tenants be told we are changing systems?
Only about what changes for them: a new payment reference, where receipts come from, and their opening balance with a window to query it.
Which software should a letting agency move to?
Test any candidate against your own data, not a demo portfolio, using the checklist in choosing property management software. If you are considering our letting agency software, our team sets the account up with you, and the opening balances are the first thing worth agreeing on that call.
