What Has to Move Together When Your LMS Migrates
A loan book migration breaks when systems move on different clocks. What has to move together, in what order, so classification, the ledger and bureau reporting stay correct through cutover.
You already know your loan management system has to go. The symptoms are on the table: manual workarounds for a workflow the vendor was supposed to handle, a change request that takes six weeks to price and ship, a report your team rebuilds by hand every month because the system cannot produce it. What nobody in the vendor’s demo room asks is the only question that decides whether the switch is safe: what happens the night you cut over.
An LMS migration is a sequencing problem, not a data export problem. Six things have to move together against one freeze date, the loan master and terms, the repayment schedule as billed, the ledger and GL history, the full classification history, the charges and waivers ledger, and the bureau reporting history. Move any of these on its own timeline and the new system starts reporting a different reality than the one your borrowers and your regulator have been living in.
Most migration plans read like an IT project: export, transform, load, go live. That plan works for a CRM. It does not work for a live loan book, because a loan is not one record. It is a chain of events, disbursal, repayments, a fee waived here, a rate reset there, a DPD counter that has been running since the day a payment was missed, and every one of those events has to agree with every other one on what day it happened. Split the chain across two systems that disagree about the freeze date, and the new system does not fail loudly. It fails quietly, in a classification date, a reopened waiver, or a bureau file that no longer matches the account’s real history.
Pick one freeze date, and hold every number to it
Before any file moves, agree on a single moment: the exact date and time every number in the old system becomes the number the new system has to match. Not “end of month”, a timestamp. Every extract, every reconciliation, every parallel-run comparison gets checked against that one point, because a loan book does not stop moving while you migrate it. Repayments post, charges accrue, and if two team members pull “current state” twelve hours apart, they are pulling two different books.
The freeze date is also the point every downstream check refers back to. When something looks wrong three weeks into the new system, the first question is not “what changed”, it is “did this account match the freeze-date snapshot on day one.” Without a named freeze date, that question has no fixed answer to check against.
What moves as one unit, not four exports
A migration plan that treats the loan master, the schedule, the ledger and the classification history as four separate exports is where most of the damage starts. They are not four data sets. They are one loan, described from four angles, and each angle has to agree with the others about the freeze date.
| What has to move | What breaks if it moves on its own | What it must agree with, at the freeze date |
|---|---|---|
| Loan master and terms | The new system computes a different EMI or maturity date from day one. | Every live loan’s rate, tenor and product code, as they stand today, not as originally sanctioned. |
| Repayment schedule | Past and future instalments look inconsistent with what the borrower was actually billed. | The schedule as billed after every reset and part-payment, not the original disbursal-day schedule. |
| Ledger and GL postings | Opening balances do not tie out, so the first month-end close on the new system does not reconcile. | Every posting since disbursal, not just the current outstanding balance. |
| Classification history (DPD, SMA, NPA) | An account’s NPA date resets to “today”, understating provisioning and misstating the account’s real risk history. | The full days-past-due trail, not just the bucket the account sits in right now. |
| Charges, waivers and part-payments | A previously waived charge reappears, or a part-payment silently changes the tenor instead of the EMI. | Every charge event tied to the loan it belongs to, not the net balance after the event. |
| Bureau history and CKYC linkage | The bureau file shows the account as newly opened, confusing the borrower’s own credit history. | The account’s existing bureau reference number, not a freshly generated one. |
Notice what the middle column has in common: none of these are IT failures. They are audit-by-design failures. A system that treats history as optional metadata, rather than the thing that proves a classification date or a waiver decision was correct, produces a migration that looks clean in a demo and falls apart the first time an auditor asks why an account’s NPA date changed.
The parallel run: prove agreement before you trust it
Data mapping tells you the fields lined up. It does not tell you the numbers agree. The only way to know that is to run the old and new systems side by side, on the same live loans, for at least one full billing cycle, and reconcile every output before you let the old system go.
A test on a handful of sample accounts will not catch what a parallel run catches. Sample accounts are picked because they are simple. The failures live in the accounts that are not simple: the one with three part-payments and a waived late fee, the one that moved from SMA-1 back to standard last quarter, the co-lent account split two ways. A parallel run puts the whole book through both systems and asks a narrow question about every single account: does the new system’s number match the old system’s number, for the ledger balance, the classification bucket and the next instalment due. Anywhere it does not match, you find out before go-live, not after.
This is also where synthetic test data earns its keep. Running edge cases, an account near an NPA boundary, a part-prepayment mid-cycle, a co-lending split, through a realistic but non-production book before the real parallel run starts catches structural mismatches without risking a live account. It is the same discipline behind building a living digital twin of a lender’s book for QA: break the system on a copy first, so the parallel run on the real book is confirming, not discovering.
Cutover weekend: the order that keeps classification correct
When the parallel run agrees, cutover itself is short, and the order matters more than the speed. Stop new transaction entry in the old system first, so nothing posts after the freeze date on one side and not the other. Take the final ledger and classification snapshot second, timestamped to the freeze date, not “whenever the export finished.” Load that snapshot into the new system third, and run the new system’s own day-end classification job against it before anyone touches a live account, so you catch a bucket that shifted on load before a borrower or a bureau ever sees it. Only after that day-end run agrees with the old system’s last known state do you open the new system for live transactions.
Skip the order and run the new system’s day-end job before confirming the loaded snapshot, and you are debugging classification and production traffic at the same time, on the same weekend.
Day one in the new system: what has to reconcile first
The morning after cutover, before a single new payment posts, three numbers have to tie out against the freeze-date snapshot: total ledger balance across the book, count of accounts by classification bucket, and total charges outstanding. These are cheap to check and expensive to discover wrong three weeks later, once a month’s worth of new activity has been layered on top of a bad starting point.
Bureau reporting is the other first-day check, and it is unforgiving of a bad migration in a specific way: a lender reports to credit bureaus on a fixed monthly cadence, and the first file the new system produces has to carry the account’s existing bureau reference, not a new one. Get this wrong and the borrower’s own credit history looks discontinuous, which is the kind of error that generates support calls and bureau complaints, not just an internal reconciliation flag.
What goes wrong when a step is skipped
The failure modes are not exotic. They are the same handful, every time a step above gets skipped or rushed.
Classification history did not migrate as a trail, only as a current bucket, so the new system has no record of how long an account has actually been overdue. An SMA-2 account looks brand new.
The waivers ledger moved on a different export than the charges it applies to, so the new system re-bills something a collections team already agreed to drop.
The schedule migrated as a snapshot of today’s instalment, not a history of every reset, so a part-payment the borrower expects to shorten the tenor instead recalculates the EMI, or the reverse.
The split was reconstructed from the current balance rather than carried across as its own record, so each co-lender’s share of the same loan slowly disagrees between the two books.
Every one of these traces back to the same root cause: something was treated as a snapshot when it needed to travel as history. Loan management systems that hold classification, charges and postings as an event-sourced ledger rather than a mutable current-state table do not have this problem on the way in, because the history is the record, not a derived report.
The migration is a sequencing problem, not a data problem
Every field in the loan book will map to something in the new system. That was never the hard part. The hard part is making six different views of the same loan agree with each other on the same freeze date, proving that agreement in a full parallel run before you trust it, and cutting over in an order that checks classification before it goes live rather than after. Get the sequence right and the migration is uneventful. Get it wrong and you find out from an auditor, a bureau complaint, or a borrower who calls asking why a fee they were told was waived just showed up again.
None of this is free. A proper parallel run costs a full billing cycle you might be tempted to compress, and a small team feels every week of it. There are three ways to spend that cost. Run the migration yourself, on your existing tools, and treat the sequence above as a manual checklist your team owns end to end. Bring in a migration specialist to run the parallel-run process for you, which buys speed at the cost of building no internal muscle for the next system change. Or move onto a platform where the loan master, schedule, ledger and classification history are one event-sourced record instead of four systems that have to be kept in sync, which does not remove the freeze-date discipline but shrinks what has to migrate down to one history instead of four exports.
Frequently asked questions
What data has to migrate together when an NBFC switches loan management systems?
Six things, tied to one freeze date: the loan master and terms, the repayment schedule as actually billed, the ledger and GL postings to date, the full DPD and SMA/NPA classification history, the charges and waivers ledger, and the bureau reporting history and CKYC linkage. Moving these on separate timelines is what breaks classification and reporting after cutover, because each one depends on the others agreeing about the same freeze date.
What is a parallel run in an LMS migration, and why does it matter?
A parallel run is at least one full billing cycle, usually a full month-end, where the old and new systems process the same live loans side by side and every number is reconciled before the old system is switched off. It matters because a mismatch that looks small in a test account (a wrong DPD count, a missing waiver) shows up in production as a wrong SMA date or a wrong bureau file, and by then the old system is already gone.
How long does a loan management system migration take?
There is no single answer, because it depends on book size, product variety and how much classification and charge history has to carry over, and any migration vendor who quotes a fixed week count before seeing the book is guessing. What is fixed is the shape of the timeline: data mapping and validation, then a parallel run of at least one full billing cycle, then cutover, then a reconciled first month-end close on the new system.
What usually goes wrong in an LMS migration?
The same handful of failures recur: DPD counters reset to zero because classification history did not migrate, a waived charge reappears because the waivers ledger moved separately from the charge it applies to, a part-payment silently changes the tenor because the schedule migrated as a snapshot instead of a history, and a co-lender's share of a loan drifts because the split was reconstructed rather than carried across.
Read next:
- Every Lender Replaces Their LMS Eventually: the five symptoms that tell you it is time to migrate, before you plan how.
- SMA and NPA classification for NBFCs: the day-end rules a migration’s classification history has to hold intact.
- We stopped copying dummy rows and built a living digital twin: the same edge-case testing discipline that de-risks a parallel run.
Chandramouli is the co-founder and CEO of Lokta, the agentic loan servicing platform. He has spent two decades building AI for decisions that change people’s lives, and has served as an independent director on an NBFC board. He writes here about the mechanics that decide whether a system change is safe.
