How to export your data from Mambu

How do you export your data from Mambu before moving to Apache Fineract?

If a renewal, a pricing change or an exit decision has put your Mambu core on the list for replacement, the first question is how to get your banking data out in a usable form. Mambu documents four extraction routes: Mambu Extract, which synchronizes near real-time data to cloud object storage; the Streaming API; database backups downloaded through the API; and a Mambu-Stitch ETL integration that loads data into warehouses or lakes. The documentation states that users can take database backups at any time, and the Streaming API is documented as a way to stream large volumes of events out through subscriptions, reading batches and committing cursors so a client can resume from its last committed position. Those mechanics matter for a one-time extract versus a parallel run, because a cursor-based stream supports continuous synchronization while a backup is a point-in-time snapshot.

What the public material does not settle clearly is coverage. Confirm with Mambu, in writing, which entities (clients, accounts, loan schedules, transactions, custom field values, product configuration and documents) each route delivers, in what format, and whether any are excluded from Mambu Extract or the Streaming API. Ask whether a database backup can be restored into a standard PostgreSQL environment, since that determines how much transformation your team must write before data reaches Fineract's schema. Also confirm retention limits, data egress terms in your contract, and whether Mambu supports a full extract during the notice period. The export is only one part of the migration. Extracted files still need mapping to Fineract products and multi-tenant configuration, reconciliation of balances and repayment schedules against the source, and a cutover plan that freezes or synchronizes postings during the final load. Plan that work before choosing a route, and treat the export as the input to a tested reconciliation, not the finish line.

Which Mambu data types can you export, by method?

This table maps each documented Mambu export route to its destination, delivery pattern and stated format or limits. Read it by first matching your migration pattern (one-time cutover or parallel run) to a route, then confirming the open items with Mambu before you plan the extract.

Route	Destination	Delivery pattern	Format and limits stated in the documentation
Mambu Extract	Cloud object storage	Near real-time synchronization	Entity list and file format not stated in the supplied sources; confirm with Mambu
Streaming API	Your own consumer or pipeline	Subscriptions to topics, reading batches of events and committing cursors	Batch and cursor model documented; batch size, retention and throughput limits not stated; confirm with Mambu
API database backups	Files you download and store	On demand, through the API; users can back up at any time	Backup file format, size limits and restore procedure not stated; confirm with Mambu
Mambu-Stitch ETL	Data warehouse or data lake	Scheduled or managed ETL integration	Supported targets and sync frequency not stated in the supplied sources; confirm with Mambu
Fit for one-time migration	Depends on route	Single full extract at cutover	Backup-based or full extract is usually the simpler starting point; validate completeness against your product list
Fit for parallel run	Depends on route	Continuous change capture while both cores run	Streaming API or Mambu Extract suits incremental sync; confirm how deletes and corrections are represented

One-time migration or parallel run: which route fits?

A single cutover freezes Mambu at an agreed point, extracts a complete data set and loads it into Apache Fineract in one window. The main question is whether you need a consistent, point-in-time copy of the whole database. A database backup is the natural reference snapshot here, because it captures the database as a unit rather than as a stream of changes you must reassemble. The Streaming API still has a role for large volumes, since its batch reads let you pull events in pages and resume after a failure, but you must confirm that the events you consume add up to the full state you need for clients, accounts, loan schedules and transactions.

Reference snapshot: Take a database backup at the freeze point and keep it as the authoritative copy for reconciliation, even if you load from another extract.
Resumable reads: Streaming batches with committed cursors let an interrupted load continue from the last committed position instead of restarting.
Shared subscriptions: Several loader workers can share one subscription to speed up a large load, but confirm how partitioned events are ordered for dependent records.
Freeze discipline: Stop or restrict writes in Mambu before the final pull so the snapshot and the event stream describe the same state.
Fineract load order: Load products and configuration before clients, then accounts and schedules, then transactions.

Before committing to a route, confirm with Mambu how backups are scheduled, retained and downloaded for your tenant size.",

What Mambu does not export, and the workarounds

The four documented routes move banking records, but configuration, custom logic, audit history and attachments may sit outside them. Verify each gap with Mambu before you plan the cutover, and settle what is provided in writing. Your contract and exit terms decide what Mambu must return.

Product and configuration definitions

Loan and savings product settings, fee rules, interest logic and accounting mappings are the parts of the platform that define how balances behave. Data extracts usually return the resulting account records rather than the rules that produced them. Ask Mambu which configuration artifacts it will export, in what format, and whether they cover every product version still in use. Plan to rebuild these products in Fineract using your own product catalogue as the specification, then reconcile balances against the source.

Custom logic and extensions

Any custom scripts, hooks, integrations or calculations you built on Mambu's extension points will not travel with a data export. These often hold repayment or fee behaviour that no one has written down. Inventory every custom component with its owner and business purpose before extraction starts. Each one needs a replacement design in Fineract or in your integration layer, and the business rule behind it should be signed off by the product owner.

Audit history and change logs

Records of who changed a product, limit or account, and when, are operational evidence that auditors and supervisors ask for. Confirm with Mambu whether audit trails are included in the database backup, the Streaming API topics or only in the platform's own interface. If they are not exportable, archive the logs you can access and agree a retention plan for the source tenant before the contract ends.

Document attachments and KYC files

Scanned identity documents, loan agreements and other uploads may be stored as separate objects rather than as rows in the database. Check whether the chosen route returns the binaries or only references to them. Where attachments are missing, request a bulk file export from the vendor or pull them through the API by record ID, then store them in your own object storage with checksums so you can verify completeness.

Data outside the chosen route

Each route returns a defined subset. Mambu Extract and the Streaming API serve integration and analytics use, and a database backup is a whole-environment copy that may be hard to load into a different schema. Compare the field list of your chosen route against your Fineract data model and list every entity without a match. Ask Mambu in writing which entities it does not return and what it will provide on request.

Vendor contract and exit terms

Your Mambu contract and exit terms decide what the vendor must provide, in what format, within what period and at what cost. Read the data return, termination assistance and deletion clauses with counsel before you set a migration date. Request a written statement of the full data set you will receive, the delivery format and the deletion timeline for your tenant, and keep it with your exit plan.

What is the sequence for a complete export with verification?

The sequence moves Mambu data into a verified, reconciled state that a Fineract test tenant can be measured against, with each check recorded and signed off by the people who own the data.

Freeze the scope and data dictionary
The migration lead and the product owner agree which entities are in scope (clients, groups, loan and savings accounts, schedules, transactions, and GL-relevant postings), which branches and products are included, and how each Mambu field maps to its Fineract counterpart. Finance and risk sign the data dictionary and a cutoff date for the extract. The output is a versioned document that every later check refers to. Without a frozen scope, record counts in later steps cannot be reconciled, because the source keeps changing.
Take a full database backup
Before any extract runs, the platform team downloads a database backup through Mambu's API, which Mambu documents as available at any time. This backup is the fixed reference point if an extract fails or a question arises later about what the source looked like. The team records the backup timestamp, file checksum and the operator who took it, and stores the file in restricted storage. The check that closes this step is a verified checksum and a successful restore test in a separate environment, if the institution's procedures allow it. Confirm with Mambu how backup retention and download limits apply to your contract.
Set up Mambu Extract or Streaming subscriptions for deltas
The data engineering team configures Mambu Extract for near real-time synchronization to cloud object storage, or creates Streaming API subscriptions to the topics that carry the changes after the cutoff. Streaming reads batches of events and commits cursors, so a client resumes from its last committed position, and several clients can share one subscription. The team confirms that cursor commits advance only after files or events are written to the target store. The output is a delta feed that covers the period between the backup and the cutoff with no gaps, which the team proves by comparing event counts per topic against the source.
Extract the reference data
The team extracts reference data such as branches, users, currencies, loan and savings product definitions, fee and interest settings, and holiday calendars. These records change the meaning of transactions, so they are exported as a complete set with versions, not sampled. The data engineer stores each file with a row count and hash, and the product owner confirms that each product definition matches the configuration that produced the historical balances. The check that closes this step is a signed product catalog that Fineract's configuration will be built from.
Reconcile counts and balances against Mambu reports
Finance operations compares record counts for clients, accounts and transactions, and totals for outstanding principal, deposit balances and accrued interest, between the extracted files and reports generated in Mambu as of the cutoff date. Any difference is logged with a root cause, such as timezone boundaries, rounding, or a transaction posted after the cutoff. This step proves that the extract is complete and that no value changed in transit. The reconciliation controller signs the report, and differences above the tolerance agreed in step one must be resolved before the next step begins.
Load the data into a Fineract test tenant
The engineering team creates a separate Fineract tenant on a non-production PostgreSQL database, which Fineract recommends as its database, and loads products first, then clients, accounts and transactions. Liquibase migrations run on the write instance, so the team confirms the schema is current before loading. Load errors are grouped by type and fixed in the mapping rather than patched by hand in the database. The output is a load log with rejected records listed and explained. Because the official Docker images are not production-ready, the test tenant should run on infrastructure that matches the intended production design, not on a shortcut.
Sign off with a reconciliation run in Fineract
Finance operations reruns the reconciliation from step five against the Fineract test tenant, comparing counts, balances, schedules and accounting totals with the signed Mambu figures. Matching values show that the loaded data reflects the source, and any remaining gap is traced to a mapping rule or a documented exception. The business owner, the finance controller and the head of technology sign a go or no-go record that names the backup, delta feed, reference data and tenant versions used. This signed record is the evidence that the export is complete, and it is the input that the cutover plan depends on.

What to plan before the Mambu contract ends

Export mechanics are only half of an exit. The decisions below are the ones that sit in the contract and the cutover calendar, and they determine whether your extraction tooling has enough time, access and clear rights to finish the job. Settle them before the extraction work starts, not during it.

Confirm export rights and formats

Before you design any extraction, check in writing what the Mambu contract allows you to export, how often, and in which formats. Ask whether database backups, API extracts and Mambu Extract output are all covered by your subscription or only some of them. Record the answer in the contract or an agreed amendment, because the extraction scripts you write will depend on it. Ask counsel to confirm the wording.

Schedule a full backup and parallel run

Plan at least one complete database backup taken close to cutover, and one or more parallel run windows where Mambu and Apache Fineract process the same portfolio data. Mambu documents that users can take database backups at any time, so the timing is in your hands. Agree the window length with the team that will reconcile balances, schedules and postings, and keep Mambu live until the reconciliation signs off.

Agree retention and deletion terms

Ask the vendor how long it keeps your data after termination, where copies sit (including backups and sub-processor locations), and how deletion is evidenced. Your regulator and your record retention policy may require you to keep some banking records for a set period, which can conflict with a short vendor retention window. Put the deletion commitment and the certificate or confirmation format in the exit terms.

Plan the read access window

Decide how long you need read access to Mambu after the cutover date, and ask for it in writing. Auditors, dispute handling and reconciliation of late postings often need historical records for months after the last live transaction. Confirm whether read-only users, API keys and reporting remain active after the termination date, and whether that access carries a fee or a time limit.

Confirm ownership of extracted data

Confirm in the contract that your institution owns the data you extract, including client records, account histories, schedules and configuration exports. Check whether the vendor claims any rights to derived or aggregated data, and whether it can use anonymized data for product development. Ownership wording controls what you can carry into Fineract and what you can share with a new service provider or regulator.

How much effort, time and internal capacity does a data export need?

What drives the effort of a Mambu data export the most?

The biggest drivers are data volume, product complexity, the number of tenants and legal entities, and how deep the reconciliation must go. A portfolio with many clients, long loan schedules, custom fields and several deposit and lending products takes more extraction, mapping and checking than a small book with standard products. Each additional entity or environment adds another set of extracts and another reconciliation pass. Mambu does not publish a sizing formula in the material used for this page, so ask Mambu and your own data team to size the export against your actual record counts and product list before you agree a plan.

Can a bank run the Mambu data export without outside help?

Yes, a bank with Mambu administrators and experienced data engineers can run the extraction itself, since Mambu documents its own export routes. The harder part is usually the mapping and reconciliation into Apache Fineract's product model, which needs banking domain knowledge as well as data skills. Many teams run the extraction in-house and bring in outside help for the mapping, testing and cutover. Decide early which part you will own, and write that split into the scope before work starts.

What does the export work need from our team?

Plan for three groups of people. Data owners in lending, deposits and finance must confirm which records, balances and schedules are authoritative. Someone with Mambu administrator access must configure and run the extracts, and confirm which permissions and environments they can use. A Fineract-experienced engineer must design the target data model, load routines and checks, because Fineract is headless, multi-tenant and expects a PostgreSQL database. Confirm the availability of each person with your own management before the project starts, since these roles often sit in different departments.

Does running a parallel period change the export work?

Yes, a parallel run usually means repeated extraction rather than one final pull. Routes that stream changes, such as Mambu Extract for near real-time synchronization or the Streaming API, let you keep the target current while both systems operate. A one-time migration can rely on a single extract and a cutover window. In a parallel run you also need reconciliation after each cycle, a clear rule for which system holds the authoritative record on each day, and a way to replay or resume loads if a batch fails.

Are database backups enough if we skip the streaming routes?

Backups can support a one-time migration, but they are a weaker basis for a parallel run. Mambu states that users can take database backups at any time, so a backup can serve as a full snapshot for a cutover rehearsal. A snapshot does not give you ongoing change capture, however, so you would need to repeat full loads and reconcile each time. Confirm with Mambu the format, restore procedure and the size of the backup you can download, and test the restore process before you rely on it.

What should a quote for the export include?

A quote should list each deliverable in writing: the extraction method chosen, the list of entities, products and record types in scope, the mapping specification, the load and reconciliation runs, the cutover rehearsal and the handover documents. It should also state who provides Mambu access, who owns the test environment, and what happens if reconciliation finds gaps. Ask for the assumptions behind any time estimate, the number of rehearsal cycles included, and whether ongoing support or a retainer is separate. DeployOpen works on fixed scope agreed in writing, and it does not publish a price list, so the written scope is what the quote follows from.

How do we confirm the export limits with Mambu?

Ask Mambu directly and get the answers in writing. Confirm which extraction routes your subscription and environment include, the rate and volume limits on the Streaming API, the format and size of database backups, the frequency of Mambu Extract synchronization, and any restrictions on the Stitch integration. Also confirm how long data remains available after your contract ends. Mambu's data management overview and Streaming API documentation are the starting points, but your contract and account team have the final say for your environment.

What changes for your team after the data leaves Mambu

Once the extracted data lands in your environment, your team owns the Fineract instance end to end: the application deployment, the PostgreSQL database, backups, security patching and the reconciliation that proves the ledger matches the source. Fineract is a headless application with REST APIs and no built-in user interface, and its README warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Plan for that gap before cutover. The official Docker images are not production-ready, so the production build, hardening and configuration are work your team or an implementation partner must carry.

Upgrades become a recurring operating task rather than a vendor event. The Fineract README states that official releases are created quarterly, at the end of each quarter, and that end-of-life releases are archived. Each release needs a test cycle against your tenant configuration, your integrations and your reconciliation scripts. The Fineract documentation also notes that Liquibase database migrations run only on write instances, and on Kubernetes they can be run separately with the liquibase-only Spring profile. Confirm with your platform team who schedules this work, which environments it passes through, and how a failed migration is rolled back.

Backups and reconciliation are the controls auditors and supervisors will ask about first. Mambu states that its users can take database backups at any time, so confirm that your own backup schedule, restore tests and retention policy for PostgreSQL meet your recovery objectives before you retire the Mambu copy. For reconciliation, agree in writing which extract is the reference, how often balances, schedules and client records are compared, and who signs off on exceptions. Keep those reconciliation outputs as evidence. DeployOpen can prepare the controls and evidence for a compliance assessment, but the assessment itself is performed by an independent auditor.

How DeployOpen scopes and delivers an exit and data export

DeployOpen plans and delivers the Mambu data export as a fixed-scope engagement inside your own infrastructure, so the extract, the staging area and the evidence stay under your control. We agree the scope, deliverables and timeline in writing before work starts.

How we scope

Inventory which banking data sets you need (clients, accounts, loan schedules, transactions) and which extraction method each one uses.
Decide whether the export is a one-time migration or a parallel run, since each path needs different extraction and reconciliation work.
Record the written scope, deliverables and timeline before any extraction begins, and confirm the retainer option for ongoing support.

How we build

Configure the chosen extraction path, such as Mambu Extract, the Streaming API, database backups or the Stitch integration, in your tenant.
Set up a controlled staging area where extracted data is stored, access-restricted and checksummed before it is loaded anywhere.
Test the export end to end on a copy, comparing record counts and balances against Mambu before any production run.

How we hand over

Document each extraction job, its schedule, cursor or backup handling, and the owners responsible for it.
Provide reconciliation reports and an evidence pack showing what was exported, when, and how it was verified.
Hand over runbooks and access records so your team can repeat or audit the export without DeployOpen involvement.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team needs it.
Re-run reconciliation checks when Mambu or the target platform changes during a parallel run.
Ask us to confirm in writing what remains your responsibility, including regulatory notifications and sign-off on the migrated data.