Your loan history is the reason you have not switched. Let us start there.
Migration is the single biggest blocker to changing loan management systems, and it is the part of this work we treat most seriously. Here is the method, what it proved, and what it cannot promise.
Migrating a loan book means rebuilding every loan’s complete history (sanction, each disbursement, each repayment, each rate change, each waiver) inside the new system, then proving that the resulting balances reconcile against the figures the organisation has been reporting. It is an accounting exercise with a software component, not the other way round.
GoDravix has done this on a live government loan book. Below is exactly how, including the part where the numbers did not initially agree.
How a legacy loan book actually gets moved
The reconciliation happens before cut-over, not after.
Records assessment
Establish what exists, what is legible, and what has to be reconstructed from adjacent evidence.
Method decision
Identify the interest convention the legacy book used and agree in writing how it will be treated.
Masters setup
Configure schemes, rates, borrowing entities and users so migrated loans land against real reference data.
Timeline rebuild
Enter each loan’s events in true chronological order with a migration opening reference.
Interleaved recompute
Recompute interest month by month as each repayment is entered, not in a single batch at the end.
Reconciliation sign-off
Compare old and new balances loan by loan, document every variance, and get written acceptance before cut-over.
Phase five is not optional and not negotiable. The interest engine is currently order-sensitive: entering a batch of back-dated repayments and recomputing once at the end can produce wrong or negative interest. The interleaved procedure exists because of that defect. Making the engine order-independent is scheduled work; until it lands, the procedure is how we guarantee a correct result.
Reconciled loan
by loan.
A legacy book is rebuilt event by event, recomputed by the same engine that runs every live loan, then compared against your existing figures. The variance is stated per loan before cut-over is signed.
See how migration worksOne loan, rebuilt line by line, and what it taught us
During the live deployment we took a single municipal loan with multiple disbursements and more than a dozen repayments spread across several years, rebuilt it from the legacy register, and compared the result to the board’s own historical figure.
It did not match exactly. Neither simple interest nor monthly compounding reproduced the historical number, because the original book had been maintained under a convention that was never formally documented.
That finding is the most useful thing this exercise produced. It is why the method now puts the interest-convention decision in phase two rather than discovering it during reconciliation, and why every engagement gets a written position on the residual before anyone signs off on cut-over.
Replicate the historical method
Reproduce the legacy convention so opening balances tie to the last audited figure exactly. Cleanest for audit continuity. Means carrying a convention you may not want long term.
Adopt the new method, adjust the residual
Move to simple or monthly-compound interest and treat the difference as a documented waiver or adjustment, approved through the normal waiver workflow with an order reference attached.
Either way it is written down. The variance is quantified per loan and accepted in writing before cut-over. Nobody discovers it in an audit two years later.
Is your loan book ready to migrate?
Eight questions we ask at the start of every assessment. Tick what is true. Nothing is submitted anywhere, this runs entirely in your browser.
What migration does not include
Stated so the scope of an engagement is clear before it starts.
- AI-assisted migrationToday this is a documented procedure run by our team. The Migration Copilot would automate it, and is first in the AI sequence.
- Automated data extractionScanned registers and PDFs are read by people. Document intelligence would take that over, and is built against your own document formats.
- Direct system-to-system transferData arrives as files. A connector that pulls from another LMS or core banking system is a scoped build.
- Guaranteed exact balance matchWhere a legacy interest convention cannot be reproduced, we quantify the variance and document it rather than promise a zero.
Some of it is built into an engagement, some is genuinely out of scope, and some is development we can quote against your requirement. Which one it is depends on your workflow, and that is a fifteen-minute conversation rather than a guess.
About migration
It depends far more on the state of your records than on the size of your book. A portfolio with clean digital records of every disbursement and repayment moves quickly. A portfolio where repayments exist only in paper registers and the interest convention has to be reverse-engineered takes considerably longer, and most of that time is reconstruction and reconciliation rather than software work.
We scope it after a records assessment rather than quoting a duration up front, because a number given before seeing the data is a guess.
Often, but we will not promise it universally, and any vendor who does has not migrated a fifteen-year-old book. Where the legacy convention is identifiable and reproducible, balances tie exactly. Where it is not (and we have seen this on real data) we quantify the variance per loan, present it, and agree in writing whether to replicate the old method or adopt the new one and treat the difference as a documented adjustment.
Yes, with the caveat that somebody has to read them. Scanned registers and physical files are transcribed by people, ours or yours or both, because document intelligence is not running yet. It is the slowest and most expensive migration path, and the place where the Migration Copilot would make the largest difference.
It stays running. Cut-over happens after reconciliation is signed off, not before, so you retain a working system and an authoritative set of figures to reconcile against throughout. We would not ask an organisation to decommission its ledger on the strength of an untested import.
Both, if you need both. Open loans require full timeline reconstruction because their balances must be live and correct. Closed loans can often be brought across as historical records with their final position rather than a full event rebuild, which is faster and usually sufficient for retention and audit purposes. We agree the treatment per category during the assessment.
Send us one difficult loan
Pick the messiest loan in your book, the one with the restructure, the partial waiver and the missing paperwork. We will walk through how it would be reconstructed.
45 minutes | On the live deployment | A straight answer on fit