Migrate from Temenos Transact to Apache Fineract

Migrating lending books from Temenos Transact to Apache Fineract

Apache Fineract can take over carved-out loan and savings products from Temenos Transact, but it cannot take over the whole bank. A lender that wants to own its lending core usually moves one portfolio at a time, and the work is mostly data mapping, integration rebuild and parallel reconciliation, not writing new banking logic. The internal platform team normally owns the migration plan, the target architecture and sign-off, while an implementation partner often carries the mapping scripts, the interface rebuild and the test evidence. Fineract is headless: it exposes REST APIs and provides no user interface of its own, so tellers, loan officers and customers need a separate front end. The project's Kubernetes example uses the Mifos X web application for that role.

Start by listing every Transact product, account type, fee and accounting entry that the carved-out book depends on. Then decide which of them Fineract's configurable products and business rules can express, and record each gap as a decision that someone signs off. Map each client, loan and savings field to a Fineract object and keep the mapping under version control. Plan the environment early, because Fineract is multi-tenant: every API call carries the Fineract-Platform-TenantId header, and tenant connections are configured from a tenants database. The project recommends PostgreSQL, so confirm the database strategy with your own database standards. The documentation separates read, write and batch instances, and Liquibase migrations run only on write instances, so the release runbook must name which instance applies schema changes. Check these details against the Fineract documentation before the design is frozen.

Budget for the warning in the project's README: a production deployment can be complex, costly and time-consuming, the project does not provide a comprehensive production deployment guide, and organizations may pay a vendor for deployment and maintenance. The repository also warns that its Docker images are not production-ready. Treat the parallel run as the acceptance gate. Run Transact and Fineract side by side for a period agreed in writing, reconcile balances, accruals and repayment schedules on a fixed cadence, and keep Transact authoritative until every variance is explained. Ask any partner for a written scope that covers mapping, interface rebuild, parallel run exit criteria, cutover rehearsal and rollback. Finally, confirm in writing what stays on Temenos for retail and corporate banking, since the migration moves only the carved-out book.

Which Temenos Transact capabilities map cleanly to Fineract

This table compares the Transact capability areas a lending or microfinance book typically uses with their Fineract counterparts, marked clean, needs rework or gap. Read it as a scoping aid: a clean match still needs product-by-product validation against your own Transact configuration. The main takeaway is that Fineract covers the loan and savings core well, while retail current accounts, cards, corporate cash management and payments stay outside this migration.

Capability	Temenos Transact area	Apache Fineract fit
Loan and savings portfolio management	Lending and deposit products, schedules, repayments, balances	Clean: Fineract's loan and savings portfolio management covers the lending and savings books in scope
Client and KYC data	Customer records, identity and KYC documents	Clean: client data and KYC documents are native, but field mapping and document migration need rework
Accounting	General ledger postings and product-driven accounting entries	Needs rework: real-time integrated accounting exists, but chart of accounts and posting rules must be rebuilt and reconciled
Configurable products and business rules	Product definitions, fees, limits and conditions	Needs rework: configurable products are available, but each Transact product must be mapped and re-tested
Reporting	Regulatory and management reports built on Transact data	Needs rework: reporting is included, but regulatory returns usually need rebuilding against Fineract data
Integration APIs	Transact APIs for channels and downstream systems	Needs rework: Fineract exposes REST APIs, so every existing interface must be rewritten and tested
Retail current accounts and card management	Current accounts, cards and related channel processing	Gap for this migration: remain on Temenos or another system; confirm module scope in the Transact APIs documentation
Corporate cash management and payments	Corporate cash, payment initiation and clearing	Gap for this migration: not covered by a Fineract migration and remain on Temenos or another payment system

What data and integrations move, and what must be rebuilt

A Fineract migration moves a defined set of records, but the integrations around them do not move on their own. The cards below separate what can be extracted from Temenos Transact, what must be mapped into Fineract's model, and what has to be designed fresh on the Fineract side.

Client records and KYC documents

Client profiles, identifiers, contact details and KYC documents are the first extraction set. Fineract's client data and KYC document support covers this area, but field-level mapping from Transact customer records is your work. Confirm with your Transact team which export paths your version supports, and reconcile document counts and identifiers before any load. Missing or mismatched KYC evidence is a compliance finding, not just a data defect.

Loan schedules and balances

Loan accounts must carry their repayment schedules, principal and interest balances, arrears status and disbursement history into Fineract without recalculation drift. Confirm whether your Transact version exports schedules as stored or only as parameters that must be recomputed. Each product's interest and fee rules need a documented mapping, so a schedule that rebuilds differently on day one is caught in the parallel run.

Savings accounts and GL mappings

Savings balances, interest accruals and transaction histories move with their ledger treatment. Map every Transact general ledger account to the Fineract chart and accounting rules that will post the same entries. Real-time integrated accounting in Fineract changes when and how postings happen, so the mapping must cover both balances and the journal entries behind them.

Transact APIs as the integration inventory

Start the integration inventory from the Transact APIs, since every consumer of those endpoints is a dependency to account for. List each system that reads or writes loans, savings or customer data, including payment, reporting and channel systems. Decide for each one whether it is retired, repointed to Fineract's REST APIs, or replaced by a new feed.

Fineract tenant headers and API design

Fineract is multi-tenant, and every API request carries a Fineract-Platform-TenantId header, so tenant routing must be designed into each client integration rather than copied from Transact calls. Define service accounts, authorization and tenant boundaries before building consumers. Confirm the header and tenant configuration against the README for the release you deploy.

Event streams on ActiveMQ or Kafka

Fineract supports ActiveMQ and Apache Kafka for events, so downstream consumers such as data warehouses, notification services and fraud monitoring need an event design, not a copy of Transact's feeds. Decide which broker your operations team can run, define the topics and payload contracts, and test replay and ordering during the parallel run. Fineract's images are not production-ready, so broker and deployment hardening is part of the scope.

Migration sequence from inventory to decommission

This sequence moves a lending or microfinance book from Temenos Transact to Apache Fineract in controlled stages, with each stage producing evidence that the next one depends on. Retail and corporate products stay on Transact throughout unless a later decision says otherwise.

Inventory products, integrations and data owners
Your bank's product, customer and integration teams list every Transact product, account type, fee and interest rule, batch job and downstream interface that touches the carve-out book. Each item is tagged as moving to Fineract, staying on Transact, or being retired, and each has a named business owner. The output is a product catalogue with integration dependencies. The step is done when no in-scope product or interface is unassigned and the business owners have signed the catalogue.
Write the data mapping specification
Working with the Transact administrators and Fineract configuration specialists, map each Transact field and product parameter to its Fineract equivalent, including client identifiers, KYC document references, interest accrual methods, repayment schedules and accounting ledger codes. Record the fields with no direct equivalent and decide how each will be handled. The output is a mapping specification reviewed by finance, credit risk and compliance. The step is done when every in-scope field has a target or a documented exception.
Build the target environment and extract a pilot
Stand up the Fineract environment in your own infrastructure, with PostgreSQL as the database, as the project recommends, and confirm that the tenant configuration and the write, batch and read instances behave as designed. Extract one loan product with a bounded set of accounts and load it through a repeatable script. The output is a loaded pilot book and a load log. The step is done when the load completes without manual edits and the environment passes your security and operations checks. Note that Fineract's own documentation warns that its images are not production-ready, so your team must harden and test the build.
Reconcile the pilot balances
Compare principal, interest, fees, arrears and account status for every pilot account between Transact and Fineract at the cut-off date, then repeat the comparison after a set of agreed postings such as repayments, disbursements and interest accruals. Investigate every difference until it is explained by an approved mapping rule or corrected in the source data. The output is a reconciliation report signed by finance operations. The step is done when the pilot shows zero unexplained variances across the agreed test cycles.
Run a parallel comparison of outputs
For a defined period, run the same daily transactions through Transact and Fineract, and compare ledger entries, statements, regulatory reports and customer-facing notifications. Include month-end and any product events such as rate changes, restructures and write-offs in the scope of the comparison. Differences are logged, classified and fixed in the mapping or configuration. The output is a parallel run report with a defect register. The step is done when the defect register has no open high-severity items and the business has accepted the reports in writing.
Cut over by product or cohort
Prepare a cutover runbook that sets the freeze window, the final extraction and validation steps, the rollback criteria and the decision owner for each product or customer cohort. Execute the cutover in the agreed order, then confirm balances and ledger totals against the frozen Transact position. Keep Transact available in read-only mode for the agreed fallback period. The output is the cutover runbook with a signed execution record for each wave. The step is done when each wave passes its balance check and the rollback path has been tested.
Decommission carved-out Transact products
After the fallback period closes, disable the retired Transact products, interfaces and batch jobs, archive the data your retention policy requires, and remove access for users who no longer need it. Confirm that Transact still serves retail and corporate products without dependency on the retired lending components. The output is retirement evidence: change records, archive manifests, access reviews and an updated architecture diagram. The step is done when your compliance and audit teams accept the evidence and the retired components no longer appear in production monitoring.

How the migration differs by lender type and starting point

A microfinance institution that runs one lending product is the closest fit for Apache Fineract. The scope is usually bounded: one client base, one loan product family, and a small number of accounting and reporting rules. Fineract covers client records, KYC documents, loan portfolio management and real-time accounting, so most of the work is mapping the existing product configuration into Fineract's product and business rule model and extracting clean client and loan histories.

Scope: One product family, one currency and a defined set of fee and repayment rules make the mapping and test cases manageable.
Integration load: Typically limited to a few feeds, such as a general ledger export, a credit bureau file and a reporting extract. Confirm each interface with the people who own it.
Parallel-run complexity: A short run against a fixed cut-off date is usually enough, with daily balance reconciliation between Transact and Fineract.
Staffing: The team is often small, so confirm who will operate Fineract's database, backups and upgrades after go-live.
Ask for: A written list of products, fee rules and interfaces, and a reconciliation sign-off criteria document before any build starts.

Before committing, confirm that your Transact product rules can be expressed in Fineract's configurable products and that your reporting obligations can be met from its data model.

How to run parallel reconciliation and cut over safely

The cutover plan for a Fineract migration rests on one decision made early: how the platform is deployed and where its database lives. Fineract separates work into write, batch and read instances, configured through environment variables, and the Fineract documentation recommends one write instance, one batch instance and several read instances on database read replicas for high load. Liquibase schema migrations run only on write instances, and on Kubernetes they can be run separately with the liquibase-only Spring profile, so your deployment pipeline should run that migration step once before any write instance starts. The README recommends PostgreSQL as the database and deprecates MariaDB and MySQL under FSIP-9, so choose PostgreSQL unless you have a documented reason not to. Treat the official Docker images as a starting point only: the project warns they are not production-ready, so hardening, secrets handling, backup and restore testing and monitoring are scoped work for your team or your implementation partner, not defaults you inherit.

Run the parallel period against the same cut-off dates on both systems and reconcile three things separately: balances per loan and savings account, interest accruals per period, and general ledger postings by product and branch. Balances tell you whether the portfolio moved intact, accruals reveal day-count and rounding differences that balances hide, and GL postings show whether the accounting entries match the subledger. Agree tolerances with finance and risk before the first run, and log every variance with a root cause, because unexplained differences are the usual reason a go decision slips. Write the go or no-go criteria down in advance: for example, zero unexplained variances on balances, documented and approved mapping exceptions only, a successful restore of the Fineract database from backup, and sign-off from named owners in finance, operations and compliance. Define the rollback plan with the same care: specify who can freeze the Temenos ledger for the migrated products, how long Temenos remains the system of record after a rollback, and how postings made in Fineract during a failed window are reversed or re-entered. Confirm these steps with your Temenos and Fineract administrators and with your regulator's expectations before the cutover window is fixed.

What usually goes wrong in a Temenos to Fineract move

Most failed lending migrations fail on details that looked settled during scoping. The six risks below cover product logic, ledger mapping, integration effort, ownership, skills and evidence, and each one comes with a check to run before cutover.

Interest and fee logic drift

Day count conventions, accrual timing, penalty rules, rounding and fee capitalization built into Temenos Transact products rarely map one to one onto Fineract loan products. A small difference on each loan compounds across a book and shows up as balance breaks weeks after cutover. Before migration, document every accrual and fee rule per product, then replay a sample of live loans in Fineract and compare the schedule line by line. Treat any unexplained difference as a blocker.

General ledger mapping gaps

Temenos Transact posts to its own accounting structure, and every transaction type needs a destination account in the Fineract chart of accounts. Gaps appear in suspense items, write-offs, interest receivable and reversal entries, which are often configured in Transact by convention rather than by explicit rule. Build a mapping table covering every transaction type in scope, assign an owner for each account, and reconcile opening trial balances in both systems before the first parallel run.

Underestimated integration rebuild

Every system that reads from or writes to Transact, including payment rails, credit bureau feeds, collections tools, data warehouses and regulatory reporting, must be rebuilt against Fineract's REST APIs or its event outputs. Teams often budget for the core and forget these interfaces, which then surface as late scope changes. List every interface from the Transact integration catalog, classify each as retire, rebuild or keep, and test the rebuilt flows during parallel run.

Unclear ownership after cutover

Once Fineract runs the loan book, questions about who approves configuration changes, who applies upgrades and who answers incident calls need named owners. Fineract is a headless application with no vendor support contract by default, so the bank or its implementation partner must hold those roles. Write a responsibility matrix that covers the application, the database, the integrations and the hosting layer, and agree it before cutover rather than after the first incident.

Missing PostgreSQL operations skills

Fineract recommends PostgreSQL, and the official Docker image ships only the PostgreSQL JDBC driver. Teams that run Transact on a different database stack may lack staff who can tune replication, plan backups, run Liquibase migrations and restore tenant databases. Confirm that named engineers can perform these tasks in a non-production environment, including a restore test, before the core moves. If the skill is not in-house, price the training or the partner support as part of the scope.

Compliance evidence gaps

Regulators and auditors will ask how the migrated balances were validated, who approved each configuration, how access was controlled and how changes are logged. These records often sit in Transact's operational history and are not carried over automatically. Define the evidence list with your compliance team before the first parallel run, store reconciliation reports and change approvals in a system of record, and remember that DeployOpen prepares this evidence while independent auditors issue any assessment.

What drives cost and duration in this migration

This table lists the factors that most change the effort of moving lending and savings books from Temenos Transact to Apache Fineract, with why each matters and how to keep it under control. Use it to shape your written scope before asking for a quote, since the quote follows from that scope and its cost components.

Driver	Why it changes cost or effort	How to keep it down
Number of products carved out	Each loan or savings product needs its own mapping of terms, fees, interest rules and accounting, and each one needs testing in Fineract.	Start with the smallest set of products that justifies a Fineract core, and retire or leave unused variants in Transact.
Integration count	Every channel, payment rail, general ledger feed and reporting extract that reads from Transact must be repointed to Fineract's REST APIs or rebuilt.	Inventory interfaces early and group them by owner, then migrate the read-only feeds first.
Data quality in Transact	Duplicate customers, inconsistent KYC documents, and unreconciled balances slow extraction and mapping and can block loading.	Run profiling and cleansing on the source extract before design work, and set acceptance rules for what loads.
Reconciliation depth	Parallel runs need balance, accrual and accounting tie-outs at client, loan and ledger level, which takes more effort the more sub-ledgers are involved.	Agree the reconciliation tolerances and reports in the written scope, and automate the daily comparison where possible.
PostgreSQL and Kubernetes skills	Fineract's README recommends PostgreSQL, and its documentation describes separate read, write and batch instances, so staff must operate that topology well.	Confirm which skills your team already has, and decide whether training, hiring or a support retainer fills the gap.
Hardening and backup scope	Fineract's README warns that production deployment can be complex and that the project provides no comprehensive production guide, so the hardening, backup, restore and monitoring work is largely your responsibility.	Define the security baseline, backup frequency and restore tests in the scope, and reuse your existing controls where they fit.
Compliance testing and evidence	Your regulator and external auditors will expect evidence that the new core performs as designed, and DeployOpen prepares that evidence but does not issue audit reports.	Ask your assessor early which evidence they expect, and agree which tests and documents are in scope.
Source of the quote	A fixed-scope quote covers the agreed deliverables, timelines and cost components, so changes to any driver above change the quote.	Write down assumptions and exclusions, and ask for each cost component to be priced separately.

Questions buyers ask before moving off Temenos Transact

Can Apache Fineract replace all of Temenos Transact?

No. Fineract covers a defined part of a bank's book, mainly client records, loan and savings portfolio management, real-time integrated accounting, reporting and configurable products and business rules, as described on the Fineract website. It is a headless application with REST APIs and does not provide its own user interface, so front ends must be built or chosen separately. Retail and corporate banking breadth, such as card and payment processing, treasury, trade finance and the wider product catalog Transact supports, typically stays on Temenos or moves to other systems. Map your product list against Fineract's documented scope before deciding what leaves Transact.

What drives the cost of moving lending books from Temenos to Fineract?

Cost splits into one-time work and recurring work. One-time items include product mapping, data extraction and transformation, integration with channels and accounting, testing, parallel runs and staff training. Recurring items include hosting, database operations, security patching, upgrades and support. The Fineract README warns that a production deployment can be complex, costly and time-consuming, and that organizations may pay a vendor for deployment and maintenance, so ask for that cost explicitly. The main drivers are the number of distinct loan and savings products, the cleanliness of source data, the number of downstream systems, and the depth of your compliance evidence. Ask any provider for a quote built from a written scope.

How long does a migration off Temenos Transact take?

Duration depends on scope, not on Fineract alone. A single product line with clean data and few integrations is a very different project from a multi-branch lender with many product variants, legacy channels and regulatory reporting that must be rebuilt. The phases that usually set the timeline are scope and product design, data mapping and reconciliation, integration build, parallel runs and cutover planning. No duration figure is supplied for this work, so ask any partner, including DeployOpen, to state phases, deliverables and dates in a written scope before work starts.

What must our internal team provide during the migration?

Your team owns the business decisions and the source knowledge. That means confirming which products move, defining how balances, interest and fees are calculated in each product, approving data mappings, signing off reconciliation results, and naming owners for accounting and regulatory reports. Your operations staff must also be available for parallel runs and cutover rehearsals. Technical staff should own the target environment, including Kubernetes or other hosting, PostgreSQL administration, backups, and identity and access controls. Plan these roles early, because the largest delays usually come from unanswered product rules, not from software installation.

Can our own engineers run the migration without an implementation partner?

Possibly, if you already run production systems and have people who understand both Transact's product logic and Fineract's configuration model. The Fineract documentation covers read, write and batch instances, Liquibase migrations and tenant configuration, but the project does not provide a comprehensive production deployment guide, according to its README. That gap is where most in-house teams need outside help: hardening, backups, upgrade runbooks and compliance evidence. Assess your skills against that list. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under a fixed-scope written agreement.

How does the Fineract quarterly release model affect upgrades?

Official Fineract releases are created quarterly, at the end of each quarter, under the Apache Software Foundation release policy, and end-of-life releases are archived, according to the project README. Current stable is 1.15.0, and its documentation was built on July 10, 2026. This means you must plan a repeatable upgrade process, test each release against your custom products and integrations, and decide which version you run in production and for how long. Confirm the support window for any release you choose, since the project's end-of-life archiving sets when you must move. Upgrades remain your responsibility unless you contract for them.

What happens to Temenos Transact support during the move?

Your Temenos licence and support terms continue until you decide otherwise, so review the contract for notice periods, termination conditions and data return obligations before you start. Run Transact and Fineract in parallel for the migrated books until reconciliation is complete, then plan a controlled cutover. Once a book leaves Transact, vendor support for that book ends, and vendor-supplied fixes, upgrades and regulatory updates for it become your responsibility or your partner's. Ask Temenos what support, data export and archive options apply, and confirm with your regulator what evidence is needed for decommissioning.

Official sources for planning this migration

Start with the Apache Fineract platform documentation, because it defines how the core is deployed and operated before any data moves. Read the sections on instance types and Liquibase migrations closely. The documentation describes read, write and batch instances set by environment variables, and it recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. Your architecture team should map those roles onto your Kubernetes or VM layout, and confirm with your own load tests whether the read replica count fits your branch and channel traffic. Also check which Fineract release you plan to target, since the project's current stable line is listed on its website and its release notes cover upgrade steps. Link to the documentation in your planning pack as the baseline reference for the cutover runbook.

The apache/fineract repository README is the second read. It warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Treat that warning as a planning input. Confirm whether your deployment will rely on your own engineers, a systems integrator or a commercial support provider, and write that decision into the scope. The README also documents the multi-tenant model, including the Fineract-Platform-TenantId header and the tenants database, which will shape how you separate lending and microfinance products from any other books you run.

Read FSIP-9, the Apache Fineract proposal to standardize on PostgreSQL, before you choose a database engine. The proposal explains why PostgreSQL is the recommended database and why MariaDB and MySQL are deprecated. If your bank runs MySQL or MariaDB for other workloads, this decision affects your database skills, backup tooling and DBA staffing, so involve your database team early. Finally, use the Temenos Transact APIs page to build your integration inventory. List every Transact API your channels, general ledger and reporting use, then decide which calls move to Fineract endpoints, which are replaced by middleware and which stay on Transact. Confirm the API versions and any licensing terms for API access with your Temenos account team.

How DeployOpen scopes and runs a Fineract migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Temenos Transact to Apache Fineract move, we start with a written scope that separates the lending and savings books being moved from the retail and corporate banking functions that stay on Temenos.

How we scope

Agree in writing which loan and savings products move to Fineract and which stay on Temenos Transact
Map source data fields, customer records and KYC documents to Fineract's client and portfolio model
Confirm the target environment, PostgreSQL database layout and tenant configuration before any build work starts
Define parallel run criteria, reconciliation tolerances and cutover acceptance tests in the scope document

How we build

Deploy Fineract in your own cloud account, data center or air-gapped network with separate read, write and batch instances
Build extraction, transformation and loading jobs that reconcile balances against Temenos source reports at each stage
Integrate Fineract with your existing channels, accounting, reporting and identity systems through its REST APIs
Run security testing of the APIs and infrastructure before the parallel run starts, and document the findings

How we hand over

Deliver runbooks for deployment, Liquibase migrations, backups, upgrades and tenant administration
Document the mapping rules, reconciliation results and cutover decisions so auditors and internal teams can trace them
Train your operations and technology staff on the configured products, the Fineract APIs and the operational procedures
Provide compliance evidence and control documentation for independent auditors, noting that DeployOpen prepares evidence but does not issue audit reports

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
Ongoing support, upgrades and continuous security testing are available as a retainer after handover
Ask for a quote built from the written scope, listing each deliverable, integration and testing activity separately
Confirm with your team which Fineract release line you will run, since official releases are created quarterly