To switch property management software without losing your books, export everything while you still have access, close and reconcile one final month in the old system, and start the new system from that month-end's balances, proven with a trial balance from each side. Records you work with daily, properties, residents, and leases, move by re-entry; accounting history moves by import or stays archived. Cancel the old subscription only after the new books balance.
The decision is usually made long before anyone says it out loud. Maybe it happened for you on the 28th, retyping unit 14's work order into a screen that spins between saves, when you heard yourself think: after month-end, we are done. Then the second thought arrived, the one that has kept the portfolio on this software for years: five years of rent history, deposits, and ledgers live in there. Leaving feels like walking away from your own records.
What actually happens to your data when you leave
The fear that keeps operators on software they resent is losing the record: the ledgers, the deposit history, the proof of what was charged and paid. Here is the honest shape of that risk. Your data does not vanish when you decide to leave; it becomes inaccessible when the subscription ends, on terms that vary by vendor and contract. Some platforms keep read access open for a window after cancellation, some do not, and export features you assumed were complete can turn out to be partial or fee-gated. None of that is yours to control. What you control is sequencing: the one risk you cannot manage your way out of, losing access to the records themselves, retires the day your exports are done. Export first. Give notice second. Everything after that is bookkeeping, and bookkeeping you can check.
What to export while you still have access
Take everything, in the most portable format offered, before you tell anyone you are leaving. The table lists what a complete export set contains and what each piece is for. Spreadsheet formats beat PDFs for anything you plan to re-enter or import; PDFs are fine for the pure archive. Store the set somewhere that outlives the subscription, and open every file once to confirm it holds what its name promises.
| Export | Why you need it |
|---|---|
| Resident and lease roster: contacts, units, rent amounts, deposit amounts, dates | The source you re-create records from, and check them against |
| General ledger, full history | The permanent archive; answers any question about the past without a login |
| Trial balance as of the planned cutover date | The one set of numbers the new books must match |
| Accounts receivable aging | Who owes what on moving day, resident by resident |
| Security deposit liabilities by resident | A liability you may have to prove per person, years from now |
| Bank statements and completed reconciliations | The cash trail; your bank re-issues statements, it does not re-issue your matching |
| Vendor list and open payables | Who you owe, so nothing goes unpaid in the gap |
| Documents: signed leases, photos, inspection reports | Attachments rarely ride along in a data export, and are the loudest loss when found missing late |
| Owner statements already sent | The record of what you told owners, for continuity and year-end questions |
Pick a month-end cutover date
A cutover date is the boundary line between the two systems: everything through that date is the old system's history, and everything after it posts in the new one. Make it the last day of a month, because a month-end is the only date you can prove. The old system prints a trial balance as of that day, the new system starts from it, and the two must agree to the cent. A mid-month cutover leaves both systems half-owning one month, which is how balances drift.
Any month works. Year-end is the cleanest break on paper and also the season owner packages and tax preparation already own, so weigh the tidiness against the workload honestly. The stronger rule is not to wait: a clean cutover in an ordinary month beats a perfect cutover postponed twice. The close discipline underneath all of this, posting the month completely and locking it, is covered in Property Management Accounting: The Complete Operational Guide.
The switch, step by step
The procedure assumes nothing about the software on either side; it is the sequence that keeps the books provable through the move.
- Export the full set first. Everything in the table above, while your access is intact and before notice is given.
- Pick the month-end cutover date, and put the go-live, the first day of the following month, on the team calendar.
- Close the final month completely in the old system. Post every invoice and receipt, reconcile every bank account, send the owner statements, and print the trial balance, receivables aging, and deposit liability report as of the cutover date.
- Build the foundation in the new system. Chart of accounts first, then properties and units, then residents, then leases with their real terms, dates, and deposits.
- Land the opening balances. Enter or import the trial balance as of the cutover date, so every account starts where the old system verifiably ended.
- Bring the bank forward. Record each bank account's statement balance as of the cutover date, so the first reconciliation starts clean.
- Run the landing checks, covered in the next section, before anything new posts.
- Go live on day one of the new month, and keep the export set archived permanently, wherever your other records live.
Opening balances are the per-account totals a new ledger starts from, dated to the cutover: assets, liabilities, equity, and, when the cutover falls mid-fiscal-year, the year-to-date income and expense figures that keep the current year's reports whole. They are the entire bridge between the systems, which is why they come from a printed trial balance and never from memory.
The checks that prove the books survived
Four comparisons, run before the new system takes its first live transaction, turn "we think it went fine" into a record.
The trial balance matches. Print it from both systems as of the cutover date and compare account by account, to the cent. This is the master check; if it passes, the ledger moved intact.
Receivables match by resident. The old system's aging and the new system's open balances name the same people owing the same amounts. A total that matches while the detail does not is a wrong number that happens to add up.
Deposit liabilities match by resident. Deposits are the balance you may have to prove years from now, one person at a time, so this check runs at that level, never in total.
The first reconciliation closes clean. When the first post-cutover bank statement arrives, it should reconcile without any variance that predates the move; when it will not balance, the opening bank balance is usually the culprit. The workspace and the method are their own guide: Bank Reconciliation for Property Managers: A Step-by-Step Guide.
How the landing works in Scaalr
Scaalr's side of a software switch is a guided landing rather than a migration service, and it is honest about which is which. Setup runs on a getting-started checklist: see the sample story, add your first property, your first resident, a lease, a rent collection, an invoice. Each step ticks itself off the moment the record actually exists and links straight to the screen where it happens, so the checklist always shows what exists and what is still missing. It offers only the steps your permissions allow, and it disappears once the list is done.
The books come over by CSV. The journal import starts from a downloadable template, previews the file as grouped batches with totals and validation errors before anything saves, and enforces what an accountant would: debits equal credits, amounts positive, accounts valid and active, one currency and one date per batch, and an open fiscal period. A batch saves all or nothing, posts automatically or lands as drafts, and a reference column can tie lines to existing invoices or rent records. For opening balances specifically there is an even shorter path: while a manual journal entry is still a draft, rows paste straight in from a spreadsheet.
Bank statements import the same way: the CSV your bank exports, previewed and column-mapped before committing, in any column order, with one signed amount column or separate debit and credit columns, and a report of any rows skipped. Each bank account takes a seeded opening balance so the first reconciliation does not open with a variance that predates the system, and the report suite prints the trial balance that closes the landing checks.
Two boundaries belong in the same breath. There is no bulk portfolio import: properties, units, residents, and leases are entered through guided screens, one at a time, with the checklist keeping score. And there are no PMS integrations: Scaalr replaces a property management system rather than plugging into one, and nothing connects to Yardi, RealPage, or AppFolio to pull records across. The import surface is exactly two files wide, journal entries and bank statements; everything else moves by the procedure above. All of it, the checklist, both CSV imports, and the reports, is on every plan, including Starter. Once the leases are in, the operating cycle starts itself: rent charges generate nightly from each lease, which is its own guide: Automated Rent Collection: From Scheduled Charge to Cleared Payment.
Key questions
What should I export before canceling my old property management software?
Nine things, while your login still works: the resident and lease roster with rent and deposit amounts, the full general ledger, a trial balance as of your planned cutover date, the receivables aging, security deposit liabilities by resident, bank statements and completed reconciliations, the vendor list with open payables, every attached document and photo, and the owner statements you have already sent. Export first, give notice second; read access after cancellation varies by vendor and contract.
When is the best time to switch property management software?
The last day of a month, any month you can close calmly. A month-end cutover gives you a trial balance to land opening balances from and a clean line between the old books and the new. Year-end is the cleanest break on paper and the worst season to attempt it, because owner packages and tax preparation are competing for the same hours. A well-run October beats a chaotic January.
How long does it take to switch property management software?
It scales with the portfolio, not the software: exporting takes hours, re-creating properties, residents, and leases is the long pole, and opening balances take an afternoon once the trial balance is in hand. Vendor-run migrations move on the vendor's schedule; a self-serve landing moves on yours, so a small portfolio can cut over inside a week while a larger one plans a month. The proof step, the first reconciled month, takes a month by definition.
Can I bring my accounting history into the new system?
Opening balances always; full history where the new system accepts it. Scaalr imports journal entries from CSV with a downloadable template, a preview that groups entries into batches with totals and validation errors, and an all-or-nothing save, so you can land opening balances only, the current year, or deeper history at your own choice of depth. Whatever you do not import stays covered by the archived exports from the old system.
Do I have to re-enter my properties and residents by hand?
In Scaalr, yes: there is no bulk portfolio import, so properties, units, residents, and leases are entered through guided screens, with the getting-started checklist tracking what exists and what is still missing. The books are the exception: journal entries and bank statements import from CSV. Re-keying a portfolio is real work, and it is also the one moment you will ever audit every lease term against the source documents, so the portfolio lands cleaner than it left.