Migrations fail in a predictable order: the data goes in, the balances do not agree, nobody can say which system is right, and three months later half the team is still working in the spreadsheet. This is the order to do it in, what to reconcile before you cut over, and the three checks that tell you it actually worked.
Before anything: decide what "done" means
Write down, in one sentence each, the three numbers that must match on cut-over day:
- Total outstanding principal across all active loans.
- The count of active loans, and the count of active clients.
- The sum of the next instalment due across the book, for the coming month.
If those three agree between the old records and the new system, you have migrated. If they do not, you have imported. The distinction is worth being pedantic about, because "the data is in" is a milestone people celebrate and it is not the milestone that matters.
The order
1. Chart of accounts and opening balances
First, always. Everything else posts into it, and a chart of accounts designed after the loans are loaded is a chart of accounts you will restructure with live data in it.
Take the trial balance as at your chosen cut-over date and enter it as opening balances. This is also the moment to fix a chart of accounts that has grown organically — merging six variations of "office expenses" is cheap now and expensive later.
2. Clients
Then people, because loans reference them. Expect this to be the messiest step: the same person appears three times with three spellings, ID numbers have spaces in some rows and not others, and a meaningful number of phone numbers are wrong.
Deduplicate on the ID number, not on the name. Names in Kenyan records are written in every possible order and with every possible spelling; the national ID is the only field that is reliably the same person. Where two rows share an ID and differ in everything else, that is one client and two data-entry events.
3. Loan products
Before loans, because every loan needs one. Resist the temptation to create a product per historical variation. If you have been quietly varying the interest rate per customer, you have one product with an override, not forty products.
4. Active loans, with balances and remaining schedules
The core of the migration, and the part to be conservative about. For each active loan you need: the client, the product, the disbursement date and amount, the interest terms, the amount currently outstanding, and the remaining instalments with their dates and amounts.
Import the remaining schedule, do not regenerate it. A system that recalculates the schedule from the original terms will produce mathematically correct instalments that differ from what the borrower has been told and has been paying. The borrower's expectation is the truth here, and arguing arithmetic with somebody holding a payment book you issued is not a conversation worth having at scale.
5. Repayment history — as much as is useful, no more
This is where migrations get expensive, and where the value curve flattens fast. Repayment history matters for three things: computing arrears status correctly, assessing a repeat borrower, and answering a customer dispute.
Twelve to twenty-four months of history serves all three. Six years of closed loans serves none of them, and it is precisely the data that is worst quality and takes longest to clean. Archive it as a read-only export instead — a spreadsheet in a folder answers a dispute perfectly well, and it costs nothing to keep.
6. Everything else, after go-live
Guarantors, collateral, documents, group structures, staff and payroll. All of these can be entered progressively while the system is live. Holding the cut-over hostage to scanning four thousand ID cards is how a two-month migration becomes a nine-month one.
The reconciliation, before you cut over
Run this on a copy, in a test environment, and do not go live until it passes:
| Check | What it catches |
|---|---|
| Total outstanding principal, new vs old | Missing loans, double-imported loans, balances taken as principal+interest in one system and principal-only in the other. |
| Active loan count and client count | Rows silently dropped by an import that reported success. This is the check that catches the failure mode where an import says "clean run" and skipped a column. |
| Sum of next month's instalments | Schedules regenerated rather than imported, and date-format errors — the classic being day/month swapped on every date in the file. |
| Arrears: count of loans past due, and total at risk | Days-past-due calculated from the wrong date field, which typically makes the entire book look either perfect or catastrophic. |
| Opening trial balance total, and that it balances | Everything about step 1. |
| Ten loans, checked by hand, end to end | Everything the totals hide. Pick the two largest, two smallest, two in arrears, two restructured, and two at random. |
That last row is not optional and is not a formality. Totals agree for the wrong reasons more often than people expect — two errors of opposite sign in the same import will produce a perfect total and a wrong book.
Cut-over day
- Freeze the old system. Read-only, and say so out loud in a meeting. Two systems accepting transactions at once is the one failure from which there is no clean recovery.
- Take a final delta. Whatever moved between the test import and the freeze. This is usually small and always exists.
- Re-run the six checks against the final import.
- Go live in the morning of a quiet day. Not a Friday, not month-end, not the day salaries land.
- Keep the old data available, read-only, for a year. Not as a fallback to work in — as evidence, for the dispute that arrives in month seven.
The first month afterwards
Two things go wrong in month one, reliably, and both are easier if you are expecting them.
People keep using the spreadsheet. Usually one person, for one report the new system does not produce in the shape they are used to. Find them, find the report, and build it. Every week that shadow spreadsheet survives, it accumulates data that is not in the system.
The first month-end is slow and reveals a definition mismatch. The new system's arrears report and the old one's do not agree, because the old one counted something differently. This is not a migration bug; it is two definitions meeting for the first time. Resolve it by writing the definition down — see PAR, OLB and collection rate — rather than by adjusting the number until it matches.
Related: choosing loan management software in Kenya, which covers how to get the migration scoped and quoted before you sign anything.