The number one reason a small property manager tells me they will not switch software is not price. It is the trust account. They are afraid that if they move their ledgers to a new system, they will lose the history that proves where every deposit and owner dollar went, and then a TREC audit or an angry owner will find the hole. That fear is worth taking seriously. It is also very manageable, and you can switch mid-year without losing anything if you plan the records side first.
I practice law in Fort Worth, I run my own family's rentals, and I built KeyTurn for operators who are stuck on software that no longer fits. Here is how I would switch, and what I checked in the rules before writing this.
What the rule actually requires
Start with the one sentence that drives everything. Under 22 Texas Administrative Code Section 535.146(e), "A broker must maintain all documentation regarding a trust account for four years from the date the document is received or created by the broker." That is the rule I read on the Cornell Legal Information Institute copy, and TREC's own record retention FAQ points to the same subsection.
Two details matter for a software switch. First, the clock runs per document, from the day it is received or created. A deposit slip from March 2024 can be discarded in March 2028, not at the end of that year. Second, the rule says nothing about which software holds the records. Section 535.2(h) separately says a broker must keep a list of records, including property management contracts and receipts and disbursements of compensation, "in a format that is readily available to the Commission" for at least four years. So the test is not "is it in the old system." The test is "can I produce it, readable, for the full four years."
Section 535.146(c)(6) adds the daily mechanics. The broker must keep "a documentary record of each deposit or withdrawal from the trust account and provide an accounting to each beneficiary of trust money at least monthly if there has been any activity in the account." Put those together and you get the real job of a migration: carry forward the transaction record for every trust dollar, and keep the monthly accountings you already sent to owners.
One honest limit. I read these rules on Cornell's copy, which notes amendments through 2016 for 535.146 and 2023 for 535.2. Confirm the current text on the Texas Administrative Code before you rely on my summary, and I did not find any rule that speaks to changing software specifically. The rules are format neutral, which is the good news.
What counts as trust account history
When people say "my trust history," they usually mean one number, the current balance. The rule is about the documents behind it. For a small manager I would sort them into four buckets:
- Deposit and withdrawal records. Every receipt into the trust account and every disbursement out, with date, amount, payer or payee, and purpose.
- Tenant ledgers. Who owes what, what security deposit you hold for each tenant, and when each charge and payment posted.
- Owner ledgers and statements. The monthly accountings you sent each owner, which is how you show you met the monthly accounting duty.
- Bank records. Statements, canceled items, and your own reconciliations for the trust account. These live at the bank and in your files, not in the software, which is a point in your favor.
Notice what is not on the list: the software itself. The bank is your source of truth for what moved. The software is the organized view of it.
The cutover plan I would use
Mid-year switches go wrong when someone tries to move everything on the same day they stop using the old system. Split it into steps instead.
1. Pick a clean cutover date at a month end
Choose the last day of a month, after you have sent that month's owner statements from the old system. That gives you a hard line: everything on or before that date lives in the old system's archive, everything after lives in the new one. If you cut over on the 14th, you will spend a week explaining to owners why their statement is split across two layouts.
2. Reconcile the trust account to the penny in the old system first
Before you export anything, tie the old system to the bank. Three numbers should agree on the cutover date: the bank balance, the total of tenant and owner liabilities in the ledger, and any reconciling items you can name. If they do not agree, you are about to import a problem. Fix it where you can still see the history that explains it.
3. Export the history, then archive it as PDF and CSV
Pull the structured data as CSV: tenant ledgers, the general ledger, owner ledgers, and the deposit register. Then also save the monthly owner statements and the trust account reconciliation reports as PDF. The CSV is for reloading. The PDF is for proving what you actually sent. I walk through what the common export reports look like in my AppFolio export guide, and the same logic applies to any platform.
Store two copies, one off the old vendor's servers. Do not let your only copy sit inside an account you are about to cancel.
4. Load balances forward, not just totals
In the new system, bring in each tenant's open balance and each tenant's security deposit held as of the cutover date, plus each owner's ending balance. Do not load one lump sum for "trust." If a deposit is owed back to a tenant, the new system needs to know whose dollars those are. Security deposit accounting in particular depends on a per tenant balance, as I explain in the security deposit checklist.
5. Reconcile again in the new system, on the same date
This is the step people skip. After the import, run the same three way tie out: bank balance, total liabilities in the new ledger, and reconciling items. If the new system matches the number you proved in step 2, you have shown that nothing was lost in the move. Save that report. It is your bridge document, and it is the thing I would hand an auditor first.
6. Run both systems for one month, read only on the old one
Keep the old account open and read only for at least a month, and ideally through your next full owner statement cycle. That lets you pull a missing document without begging a vendor after your subscription ends. Check your contract for what happens to your data after cancellation, because some vendors delete accounts on a fixed schedule.
A worked example
Say you manage 40 doors and a cutover date of June 30. At the end of June, the trust account bank balance is $61,420. The old ledger shows $58,900 in tenant security deposits held, $2,300 in owner funds not yet disbursed, and a $220 outstanding check that has not cleared. The tie out works like this:
| Line | Amount |
|---|---|
| Tenant security deposits held | $58,900 |
| Owner funds not yet disbursed | $2,300 |
| Total liabilities | $61,200 |
| Add outstanding check | $220 |
| Total that should equal the bank | $61,420 |
Those figures are an illustration, not real accounts. The point is that the same five lines should appear in the old system on June 30 and in the new system on June 30. When they do, the migration is proven. When one line is off by $40, you found it on day one instead of in an owner dispute eight months later.
What to ask any new vendor before you sign
- Can I import a per tenant deposit balance and a per owner balance as of a specific date?
- Can I export all my data, including ledgers and documents, at any time, in a format I can open without your software?
- What happens to my data if I cancel? How long can I still download it?
- Does the system lock closed months so my archived statements cannot be quietly changed?
If the answer to the export question is vague, that is your answer. The same test applies to the system you are leaving, which is why I keep a copy of everything outside the vendor.
Common mistakes I would avoid
The first is switching on a day when deposits are in flight. A deposit made on the 29th that does not post until the 2nd will show up in one system and not the other. Pick a date, then list every item in transit. The second is treating the old data as disposable because the new system "has everything." It does not have your sent statements, and those are the proof of what you told owners. The third is skipping the owners. A short note saying "your July statement will come from a new system, here is what it looks like, and your balance carried over to the dollar" prevents a week of phone calls.
None of this is exotic. It is a tie out done twice and an archive kept off the vendor's servers. The fear of the switch is bigger than the work of the switch.
See how a small Texas manager made the move
Lockwood Property Management moved its ledger, deposits, and owner statements onto KeyTurn. The case study shows what changed and what it cost.
Read the Lockwood case studyIf you are weighing a switch of your own, the beta request form is on the KeyTurn home page. Tell me your door count and where your records live today, and I will tell you honestly whether KeyTurn fits.
Related reading
- How to export your data from AppFolio
- Security deposit rules in Texas: a property manager checklist
- Owner statements for small property managers
Sources
- 22 Tex. Admin. Code 535.146, Maintaining Trust Money, retrieved November 2, 2026
- 22 Tex. Admin. Code 535.2, Broker Responsibility, retrieved November 2, 2026
- TREC FAQ: How long does a license holder have to keep financial and real estate transactions on file?, retrieved November 2, 2026
I am the founder of KeyTurn. This post is general information, not legal advice for your situation, and it does not create an attorney client relationship. Rules change, so confirm the current text before you rely on it.