Migrate from Temenos Transact to Mifos X

Decide the boundary before anyone extracts a record. The carve-out should name the lending and savings products that Mifos X and Apache Fineract will own, the customer segments those products serve, and the legal entities and branches in scope. Everything else, including retail and corporate banking functions that Transact runs today, stays on Temenos Transact during the first phase unless the bank has deliberately decided otherwise. Write the list product by product: loan product codes, savings product codes, and the GL accounts that post for each. Ask the Temenos team and your internal product owners to sign the list, and ask your own compliance function to confirm which regulatory reports depend on data that will move. Products that span both sides, such as a customer who holds a savings account in one system and a card or current account in the other, need an explicit owner for each piece.

Once the boundary is fixed, define how the two systems keep talking during transition. Identify every interface that crosses the line: customer identity and KYC references, GL postings, payment instructions, collateral records, and regulatory extracts. For each one, decide whether the data flows from Transact to Fineract, Fineract to Transact, or both, and whether the link is a file exchange, an API call through the Transact APIs, or a message on a queue. Fineract supports ActiveMQ and Apache Kafka for events, so confirm which of these your integration layer will use and who will operate it. Record the system of record for each customer and account at every point in the transition. Ambiguity here is what produces duplicate customers and unexplained balance differences during parallel runs.

Put the boundary, the interface inventory and the system-of-record rules in one signed document before data extraction begins. This document becomes the test oracle for later reconciliation: if a balance or customer appears in the wrong system, the team can point to the written rule rather than debate it after cutover. Include a change procedure so that moving a product into or out of the carve-out requires the same sign-off as the original decision. Expect the list to change once extraction reveals edge cases such as joint accounts, closed-but-reportable loans and products with legacy terms. Ask any implementation partner to price the work against this written scope, so that changes to the boundary show up as explicit scope changes rather than hidden effort.

Reconciliation in a parallel run answers one question: do Temenos Transact and Apache Fineract, fed the same business day, agree on what the portfolio owes and holds? Compare five measures for every cycle: active client counts by office, loan principal outstanding by product, accrued interest, savings balances by product, and general ledger totals by account. Run the comparison at the same cut-off time on both sides, because a loan repayment posted after one system's end-of-day will show up as a false break. Build the comparison from the Fineract side as well as the Temenos side, so that each total can be traced to individual loan and savings account IDs rather than only to summary figures.

Set tolerances and exception rules before the first cycle, and have finance, credit risk and operations sign them off in writing. Separate breaks into two classes: rounding differences that arise from interest calculation conventions, and substantive breaks such as a missing account, a principal mismatch or a GL posting on the wrong account. Agree in advance who owns each exception queue, the time allowed to clear it, and whether a break blocks sign-off for the cycle. Where Fineract's product configuration differs from Transact's (for example, how a grace period or a penalty is applied), document the configuration decision next to the break so reviewers do not reopen it every cycle. Ask your implementation partner to confirm how the interest accrual method maps between the two products before you define any tolerance.

Keep evidence that an external auditor can follow without access to either system: the reconciliation reports for each cycle, the exception log with root cause and resolution, the sign-off record from each owner, the data extraction and load logs, and the versions of the Fineract build and configuration in use on each run date. Store these under your records retention policy, with access restricted to the reconciliation team. Confirm with your auditors which control evidence they expect for the migration and for the parallel period, since the format they accept is their decision and not something this section can set. Also keep a record of the parallel period's scope, so that the end of parallel running is a documented decision rather than a date that drifted.

DeployOpen prepares the systems, controls and evidence that a compliance assessment will examine, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and the migration should be planned so that the people who will test it can see a clear trail. The most useful habit is to treat every cutover step as evidence from day one: who approved the field mapping, who ran each reconciliation, who granted and removed access, and what was changed in the Mifos X and Fineract configuration along the way.

Three evidence sets are worth keeping for the migration itself. First, signed mapping sign-offs for each Transact-to-Fineract field, covering client identifiers, loan products, interest and fee rules, savings accounts and the chart of accounts that feeds Fineract's accounting module. Second, reconciliation packs from each parallel run, showing source balances from Transact, loaded balances in Fineract, and every exception with its owner and resolution. Third, access reviews for the Mifos X web app roles, the Fineract tenant configuration, the database accounts behind PostgreSQL, and the operators who can run batch or Liquibase migrations. Store these records in the client's own document system, with versions and timestamps, so they can be produced without reconstruction.

Regulator notifications depend on the jurisdiction, the licence type and the nature of the change, so the reader must confirm them with legal counsel and the supervisor, not with the implementation partner. Ask whether moving a loan book to a new system of record requires prior notice, whether customer-facing terms or privacy notices must be updated, and whether outsourcing or material change rules apply to the hosting arrangement. Also confirm the retention period for migrated records and any data residency rules that govern where the Fineract database and backups sit. Agree these questions in writing before the first load, because they set the timing of the cutover.