Loan servicing migration must preserve the account’s obligations, payment history and balance calculations, not just its current balance. Mambu’s migration documentation shows why the chosen import method matters: its Excel route accepts fixed schedules and past loan transactions, but does not support dynamic schedules or revolving credit loans. The controls below use those documented limits to build a migration checklist.
This is a documentation-based guide, not a report of a migration we performed. Mambu’s behavior is the worked example; another servicing platform may use different import rules. Start with the loan servicing platform guide for the broader software comparison.
Separate the six data sheets from the reference sheets
Mambu’s Excel migration template documentation describes ten sheets. Six hold migration data: Clients, Groups, Accounts, Schedules, Transactions and Chart of Accounts. Four contain existing configuration for reference: Branches, Credit Officers, Loan Products and Deposit Products. Editing those reference sheets does not import new configuration.
That distinction determines the preparation order. Mambu requires users and permissions, branches, custom-field definitions, and loan and deposit products to be set up before import. A loan’s product ID then points to a product already present in the destination. Copying a product name into the spreadsheet is not a replacement for creating that product.
The general lesson is to keep a configuration checklist separate from the account data file. For each legacy product and branch, record its destination ID and verify that the mapping exists. Mambu validates links between clients, accounts, products and organizational IDs; a readable name alone does not establish a valid reference.
Choose the import method before preparing schedules
Mambu recommends its APIs, or APIs together with Excel, in the data management overview. Its spreadsheet method has specific gaps:
| Case | Documented Excel limitation | Migration decision to resolve |
|---|---|---|
| Dynamic loan schedule | Cannot be imported as a dynamic schedule | Confirm the destination’s recalculation logic and supported API route |
| Revolving credit loan | Not supported by the Excel route | Select a supported method before creating the import file |
| Account-specific penalty rate | Cannot be specified at import | Determine how the rate will be configured and checked |
| Deposit history alongside loans | Only the current deposit balance is imported | Keep historical records and plan their separate treatment |
These are Mambu limits, not universal rules for loan software. They explain why a migration estimate based only on row counts can be incomplete. A portfolio with simple fixed installments and one with revolving accounts can require different preparation even when both contain the same number of customers.
The template documentation also excludes Solidarity and Hybrid Group loan accounts from import, while allowing Pure Group accounts. Product and borrower structures should therefore be checked before the file is populated.
Compare schedules before accepting the closing balance
Mambu permits fixed loan schedules to be imported. Its documentation says the imported interest, fees and penalties are used even when the product’s settings differ. The imported schedule is retained rather than regenerated, and account dues and balances are updated from that schedule and the repayment state.
Payment-due fees are not applied to imported schedules. Late fees are not applied to installments already late at import. A migration team cannot therefore assume that running the destination product’s fee rules will reconstruct every historical amount.
For reconciliation, compare installment dates, expected principal, expected interest, fees and penalties separately. A single total balance does not identify which component differs. Include accounts with overdue installments and previously paid fees in the review sample, rather than checking only loans with regular payments.
This reconciliation checklist is an editorial inference from the documented behavior. It is not an additional Mambu guarantee or a claim that every portfolio needs the same fee treatment.
Transaction history can override account-sheet values
The transaction import changes which fields control the result. Mambu says that if transactions are supplied for an account, a disbursement transaction is mandatory. Its amount and date take precedence over the loan amount and disbursement date on the account sheet. Account-sheet interest and principal paid values are also ignored when any transactions are supplied.
A preparation file should consequently make one representation authoritative. If a historical disbursement is wrong, correcting only the summary account row will not fix it. The migration evidence should show where the authoritative amount came from and why it matches the legacy ledger.
Mambu requires transactions in ascending date order, with disbursement before repayments, fees or penalties. Transactions must also be grouped by account. The order in the import table becomes their posting order.
| Check | Why it matters in the documented route |
|---|---|
| Disbursement present for every account with transactions | Required to reconstruct the account |
| Dates ordered within each account | Controls posting sequence |
| Account rows grouped together | Required transaction sequencing |
| Summary and history reconciled | History can override account-sheet totals |
| Imported fee and penalty amounts reviewed | Product settings do not necessarily recalculate them |
The documentation says no accounting is logged for imported transactions. It separately accepts opening balances in the Chart of Accounts sheet, where debits and credits must balance. A loan-history import should not be treated as proof that the general ledger has been recreated transaction by transaction.
Preserve the difference between historical and import dates
Mambu records a transaction’s creation date as the approval date of the import event, while the imported transaction carries its own date. It also sets last interest calculation, latest interest storage and latest account appraisal dates to the migration time.
For reports that depend on chronology, retain the original transaction date and the evidence linking it to the legacy record. Using the import creation date as if it were the original lending event would change the historical account timeline.
Before confirmation, compare representative account histories with the legacy export. Include a recently originated account, one with multiple repayments and one with arrears. The exact sample and acceptance thresholds depend on the portfolio; this guide does not prescribe a universal tolerance.
File validation is one checkpoint
The Excel documentation limits a submission to 5 MB, requires XLSX rather than XLS, disallows formulas and copied formatting, and requires dates in dd.MM.yyyy format. Larger migrations must be split into separate submissions. These file rules do not replace financial reconciliation.
Mambu’s workflow validates the submission, allows review and correction, and then requires confirmation to complete the import. Its overview advises backing up the data and planning timing to reduce performance impact on an already live organization.
A useful acceptance record therefore has two parts: validation results for the file, and reconciliation results for the accounts and ledger. Passing the first does not establish the second.
