Why a merger core migration is different from a normal core project
Apache Fineract can serve as the target core or as the consolidation core when an institution acquires or merges with another lender and must run one set of loan and savings books. The work, however, is dominated by product mapping, balance reconciliation, a controlled parallel run and a cutover that auditors can trace. The platform is rarely the hard part. A merger forces two sets of contracts, product rules, accounting treatments and customer records into one system on a timetable set by the deal, not by the project plan. The timing pressure is real and it is governed by rules. SEC staff allow management to exclude a newly acquired business from its assessment of internal control over financial reporting, but not beyond one year from the acquisition date and not from more than one annual report, and the excluded business and its significance must be disclosed. That window is the clock. If the acquired core is still running after it closes, the acquired controls will be assessed, and the migration has to leave evidence that the controls over balances, interest and fees were working on both sides before the switch. Confirm with your external auditor and counsel how the exclusion applies to your filings and what your disclosure obligations are.
Short answer on platforms: Fineract fits when the target institution wants an open, self-hosted, API-driven core that it controls, and when the team can staff product configuration, accounting setup and migration tooling. It does not fit as a shortcut around the hard work. Confirm with any implementation partner which Fineract versions they have migrated customers onto, how they map products that exist on only one side, and how they will prove that every account balance in the legacy core arrived in Fineract, with its schedule and general ledger entry, before the legacy system is retired.
Which requirements shape a merger migration
This table maps each requirement that commonly applies during a core banking merger to what it means for the migration build. Read each row as a design question you must answer before product mapping and cutover planning begin. The main takeaway is that most of these rules affect evidence, access and timing, not only the software.
| Requirement | What it means for the migration build | Evidence to prepare |
|---|---|---|
| SEC ICFR exclusion for acquired businesses | An acquired institution's books can sit outside your internal control assessment for a limited window, but only for one year and one annual report. The migration must finish, or your controls over the migrated balances must be running, inside that window. | Acquisition date, planned migration date, written disclosure of the excluded business and its significance |
| SEC IT general control areas | Migrated loan and savings balances that feed financial reporting need controls over program changes, computer operations and access to programs and data. Migration scripts, configuration changes and batch jobs fall within those areas. | Change records for product configuration, access reviews for migration accounts, job scheduling logs |
| SEC Item 1.05 and third-party cyber oversight | If the migration involves a material cybersecurity incident, disclosure can be due within four business days of materiality determination. Partners and hosting providers handling the data must be part of how you oversee cyber risk. | Incident escalation path that reaches legal and disclosure owners, third-party oversight records for the migration team |
| FTC Safeguards Rule controls | Customer data moved between cores must be encrypted in transit and at rest. Anyone accessing the target or source systems needs multi-factor authentication, and changes need documented change management. User activity must be logged. | Encryption settings for migration pipelines, MFA enforcement reports, change approvals, activity logs for migration users |
| Penetration testing and vulnerability assessments | Without effective continuous monitoring, testing of the systems involved must occur at least every six months. Plan a test of the merged environment before go-live, since it is new infrastructure during the transition. | Dated test reports, remediation tracking, scope statement covering both legacy and target cores |
| SEC 17a-4(b) record retention | If broker-dealer records such as bills, bank statements or business communications are in the migrated data, they must stay retrievable for the required period. Decide which history moves and which archive stays accessible. | Retention schedule by record type, retrieval test from the archive, sign-off from records owners |
| GDPR Article 28(3)(a) and Chapter V transfers | When a non-EEA acquirer's staff can view EU customer or KYC data during migration, that remote access is a transfer needing a transfer tool. Processing must follow your documented instructions. | Access map for acquirer staff by country, transfer mechanism on file, processor instructions for the migration vendor |
| DORA Article 28(3) register | The acquired institution's ICT arrangements, including any vendor core or hosting, must be recorded in your register of information. The migration plan should update it at each stage, including new contracts. | Updated register entries for legacy and target providers, consolidated and sub-consolidated view |
| DORA Article 28(8) exit and transition plans | If the legacy core supports a critical or important function, a tested exit strategy and transition plan are expected. The migration itself is the exit, so rehearse it, including rollback. | Documented transition plan, trial migration results, rollback test records |
| NIS2 change notification | If your organization falls within NIS2 scope, changes to registered details such as IP ranges, sector or service countries must be notified without delay and within two weeks. Mergers often change these, so add notification to the cutover checklist. | Current entity and IP range record, notification log, owner for competent authority contact |
Which open-source platforms fit a merger core scenario
A merger core scenario usually needs one target core for the loan and savings books, plus a few supporting tools for the rest of the combined entity. The cards below separate the core platform from its front end and from the non-core systems that may still be needed, so each choice can be tested on its own.
Apache Fineract as target core
Apache Fineract is a headless core banking platform licensed under Apache-2.0, with REST APIs, client and KYC data, loan and savings portfolios, real-time integrated accounting and configurable products. It fits a merger where the surviving entity wants one target core for loan and savings books. The fit stops at the edges: Fineract does not cover every deposit, card or regulatory reporting need out of the box. Check product mapping against your acquired book before committing, and confirm how multi-tenant setup will separate the two legal entities during the transition. PostgreSQL is the recommended database.
Mifos X as front end
Fineract does not ship its own user interface, so staff and customers need a front end. Mifos X is the web application the Fineract README points to in its Kubernetes example. Confirm whether Mifos X covers the screens, roles and workflows your operations teams need for the acquired products, or whether a separate channel build is required. A front end choice made early affects training, parallel-run screens and how much of the acquired workflow must be rebuilt.
Kill Bill for retained subscription products
Kill Bill is a subscription billing and payments platform licensed under Apache-2.0. It is relevant only if the combined entity keeps recurring, subscription-style fee products that sit outside the loan and savings core, such as a membership or service plan. Do not add it for lending or deposit balances. If it is needed, confirm how its invoices post to the general ledger in Fineract and who owns the reconciliation between the two systems.
Apache OFBiz for non-core ERP
Apache OFBiz, licensed under Apache-2.0, includes components for ERP, CRM, ecommerce, supply chain and manufacturing resource planning. It is not a core banking system and should not hold loan or deposit balances. Consider it only where the combined entity needs general business ERP that the acquirer lacks. Confirm the scope against the rest of the finance stack, and make sure the general ledger feed from Fineract remains the single source for lending and savings postings.
How product mapping and balance reconciliation decide the schedule
Every acquired product must either map to a Fineract product or be retired through a documented decision. Start with an inventory of the acquired core's loan and savings products, then compare each one against the Fineract product definition the institution plans to run. Where the acquired product has a rate structure, fee schedule, amortization method, grace period or penalty rule that Fineract cannot reproduce as configured, the team must either build the rule into the product configuration, accept a documented change for affected customers with the required notices, or close the product to new business and run it off. Each of those choices needs a named owner from credit risk, product and legal, and each affects the migration schedule because a product that cannot be mapped cannot be loaded.
Mapping is only proven when the migrated accounts reproduce the source balances. For every migrated loan and savings account, the team should compare principal, accrued interest, fees, arrears and next due amounts between the source core and Fineract, using a trial migration on a copy of the data. Interest and schedule rules need to be checked on sample accounts from each product, including accounts with irregular payments, early repayments, rate resets and partial write-offs, because these are where a rule mismatch first appears. The opening balances must also tie to the general ledger of the surviving institution, with each account population reconciled to its control total. Reconciliation reports that show account-level and ledger-level differences, with every difference explained and approved, are the evidence that the migration is complete.
A failed tie-out stops cutover. If the final trial migration leaves unexplained differences in balances, schedules or ledger totals, the go-live date should move rather than the tolerance widen without a documented approval from finance and risk. Agree the reconciliation thresholds, the sign-off roles and the rollback trigger before the first trial, so the decision is not made under pressure at cutover. Confirm with the implementation partner how reconciliation reports are produced, who can read the Fineract data behind them, and whether the reports are retained as audit evidence. Ask each partner to show a reconciliation run from a previous migration, with the exceptions log and how each exception was closed.
Consolidating two cores or moving one book into Fineract
This is the narrower project. The acquirer already runs Fineract in production, so the platform, hosting and control framework exist. The work is to add the acquired clients, loans and savings accounts as a new tenant or as a controlled load into an existing tenant, then map the acquired products onto products the acquirer already runs or on new ones it approves. Fineract identifies each tenant through the Fineract-Platform-TenantId header and reads tenant connections from a tenants database, so the tenant design, and whether acquired data sits in its own database, should be decided before any data is loaded.
- Tenant design: Decide whether the acquired book gets its own tenant, which keeps its data, configuration and reporting separate, or shares a tenant with existing business, which simplifies reporting but mixes controls.
- Data ownership: Name who owns the acquired records after closing, who approves product mappings, and who signs off opening balances against the general ledger.
- Changed controls: Change requests, privileged database access and batch job scheduling may now cover an additional population of accounts that the acquirer's auditors have not yet tested.
- Disclosure and testing: Staff assessments may exclude a newly acquired business from internal control scope for a limited period, but the exclusion and its significance must be disclosed. Plan tests for the acquired book before that period ends.
- Vendor and data location: If the acquired institution's data is in another jurisdiction, confirm where the data is stored and who can access it remotely.
Confirm with your auditors whether the acquired book will be in scope for the next annual assessment and which tests they will expect to see before the exclusion period ends.
Consolidation is the larger project. Two cores, possibly from different vendors or from different Fineract versions, are replaced by one new Fineract deployment with a single product catalog, one general ledger structure and one set of operating controls. The platform choice is only the start: product rationalization, customer de-duplication and accounting harmonization usually take more effort than the technical load. Because the new deployment is built from scratch, its tenant layout, instance types and database setup can be designed for both books at once, including write, batch and read instances and the Liquibase migration behavior that runs only on write instances.
- Tenant and instance design: Decide tenant boundaries, then size write, batch and read instances for the combined volume. The documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load.
- Database: PostgreSQL is the recommended database. MariaDB and MySQL are deprecated under FSIP-9, so do not design the merged core around them.
- Controls from day one: Because the new deployment is a new system, its IT general controls, including change management, access and batch controls, need to be designed and tested before go-live, not inherited from the legacy cores.
- Regulatory notices: Where the institutions operate in the EU, check the ICT third-party register and exit plan requirements that apply to a new critical deployment, and whether any supervisory notification is required.
- Cost drivers: Costs include configuration, integration, testing, parallel running and decommissioning of the old cores. Ask any implementation partner for a written breakdown of each.
Confirm the target release with the Fineract project's current guidance and agree a version upgrade path before the first production load.
Before choosing between the two approaches, the institution should compare the size and complexity of each book, the number of products in each core and how far the acquired institution's data can be trusted. A small, well-documented acquired book can often be moved into an existing tenant with limited change. A large book with several legacy product families, custom accounting rules and unreconciled history usually justifies a new deployment, because it gives the team a clean place to define the controls the combined institution will operate.
- Book size and product count: Count the products and accounts in each book, and identify those with non-standard terms.
- Data quality: Measure how many records fail a basic reconciliation to the general ledger.
- Regulatory footprint: Note which regulators and data protection rules apply to each book, including where the data is held.
- Timing: Decide whether the decision must support a fixed closing date or can follow a staged plan.
- Exit options: Confirm that the chosen design keeps the institution able to move data out again if needed.
Ask the implementation partner to write down the assumptions behind the recommendation, so the decision can be revisited if the acquired data proves worse than expected.
Rollout phases and the output of each
The sequence moves a merged loan and savings book from the acquired core into Fineract in stages, with a written output at each gate so that scope, balances, variances and the cutover decision can be traced later. Timing depends on scope and is set in the written proposal.
Scope and regulatory mapping
Your compliance, risk and finance leads, with DeployOpen's architects, list every product, channel, ledger and data flow in both institutions and map each to the rules that apply, such as ICT third-party risk registers under DORA, records retention, and data transfer limits where non-EEA staff may see EU data. The output is an agreed register and a written decision on what is included in the migration, what is excluded, and why. The step closes when the sponsor signs the register.
Product and accounting mapping
Business product owners and the finance team define how each acquired loan and savings product maps to a Fineract product, including interest, fee, schedule and delinquency rules, and how each balance posts to the general ledger. DeployOpen configures the mapping rules and documents every gap where the target product cannot reproduce the source behavior. The output is an approved mapping workbook, with sign-off from both product and finance owners, that becomes the reference for all later reconciliations.
Environment build and security baseline
DeployOpen builds the Fineract environments in your own cloud accounts, data centers or private network, including separate read, write and batch instances, database hardening, encryption in transit and at rest, multi-factor authentication for administrative access, and logging of user activity. Each control is tested against your baseline and the results are retained. The output is hardened deployment evidence, including configuration records, access reviews and test results, that the step is complete and the environment is fit for trial data.
Trial migrations with reconciliation reports
The team loads extracts from the acquired core into the test environment several times, each run using the mapping workbook. After each trial, reconciliation reports compare client counts, account counts, principal, interest, fees and deposit balances, and general ledger totals against the source. Every break is logged with a root cause and a fix or an approved exception. The output is a set of trial reconciliation reports showing that remaining differences are explained and accepted by the business owners.
Parallel run with variance log
Where your risk appetite calls for it, both cores run side by side for an agreed period on the same business days, with operations staff processing a sample of transactions in both and the daily batch outputs compared. Each difference, whether a rounding issue, a schedule mismatch or a missed fee, is recorded in a variance log with an owner, a severity and a closure date. The output is a variance log showing every difference and its status, which is the main evidence for the cutover decision.
Cutover and rollback with signed go or no-go record
The cutover runbook sets out the freeze, final extract, load, reconciliation, channel switch and general ledger opening balances in order, with named owners and a tested rollback path back to the source core. Before the cutover window, accountable executives review the trial reconciliations, the variance log and the rollback test, then sign a go or no-go record. The output is that signed record, with the decision criteria stated in advance, and a rollback plan that has been rehearsed.
Post-cutover monitoring and legacy decommissioning
After go-live, operations and finance monitor batch completion, reconciliation to the general ledger, customer complaints and open exceptions for an agreed stabilization period. Only when the business accepts stable results is the acquired core switched off, and its data is archived under your retention schedule so that records can be produced for auditors or regulators. The output is a closure report, a monitoring history, and a retained archive of the legacy records with an index.
Integration points and deployment pattern for a merger core
How should read, write and batch instances be split for a Fineract core during a merger?
Run one write instance, one batch instance and one or more read instances, each set by environment variables. The Fineract documentation recommends this split for high load, with read instances pointed at database read replicas. During a merger this matters because the write path keeps balances correct while migrated portfolios load, and reporting queries for the integration team and finance do not compete with posting. Confirm with the vendor how the instance types are configured in your chosen release, and test load on the combined portfolio size before cutover, since the expected volume comes from your own data, not from a default.
Where should Liquibase database migrations run in a Fineract deployment?
Liquibase migrations run only on write instances, so the schema changes once and in order. On Kubernetes you can run them separately using the liquibase-only Spring profile, which keeps schema upgrades out of the normal startup path of every pod. For a merger, this separation lets the team apply a migration in a controlled window, verify it against a trial copy of the acquired data, and roll forward or back without restarting the read and batch tiers. Ask your implementation partner to show the job order in the change record and how a failed migration is detected before any batch job runs against the changed schema.
Why is PostgreSQL the recommended database for Apache Fineract?
The Fineract README states that PostgreSQL is the recommended database, and that MariaDB and MySQL are deprecated under proposal FSIP-9. The official Docker image ships only the PostgreSQL JDBC driver, so choosing another engine means building and supporting a non-standard image. For a merger, standardizing on PostgreSQL reduces the number of database skills needed to run both the surviving core and any retained source data. Confirm the supported PostgreSQL version and replication setup with the project documentation and your database team before you size the read replicas.
How do channels, the general ledger and reporting connect to a merged core?
Fineract is headless, with REST APIs and no user interface of its own, so every channel must call the same APIs. The usual integration points are the mobile and web channels, the general ledger through the accounting module, and regulatory and management reporting. Map each feed to a named owner and a documented contract before migration starts. Real-time integrated accounting in Fineract reduces some manual journal work, but the opening balances still have to agree with the acquired general ledger. Ask the partner to list every interface, its direction, its frequency and the reconciliation check that proves it is complete.
How should staff access to a merged core be controlled with identity and MFA?
Staff access to the core should go through your central identity provider, with multi-factor authentication for every person who can reach an information system. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to implement MFA for any individual accessing any information system, so the requirement applies during the merger too, including to staff from the acquired institution. Map roles to the duties in each product and branch, remove access from the acquired staff who no longer need it, and review privileged database and API accounts separately. Confirm with the partner how Fineract tenant administration and database access are federated, because the platform's own account model may need extra controls.
What administrative activity must a merged core log, and how long should it be kept?
Log all administrative actions, including tenant configuration, product and rule changes, batch job runs, schema migrations, and direct database access, with the user, time and before-and-after values. The FTC Safeguards Rule requires covered institutions to log the activity of authorized users, and change management procedures apply to the same actions. Send these logs to storage the acquired and surviving teams cannot quietly alter, and keep them for the retention period your regulator and legal team set. Retention periods vary by regime, so confirm them for your jurisdiction. If the institution is a broker-dealer, SEC Rule 17a-4(b) sets a minimum preservation period for certain business records, which your team should check against the data in scope.
Can our own team run the Fineract integration and deployment after a merger?
Your team can run it, but the Fineract project itself warns that a production deployment can be complex, costly and time-consuming, and that it does not provide a comprehensive production deployment guide. Plan for a skilled team to own instance sizing, migrations, integrations, monitoring and upgrades, since quarterly releases arrive on a fixed cadence and each one needs testing. Many institutions pay a vendor for deployment and maintenance, which the project also notes. DeployOpen can plan, implement, integrate, harden and document a self-hosted deployment under a written, fixed scope, and offer ongoing support as a retainer. Compare that scope with what your team can staff and maintain.
What drives the cost of the integration and deployment work for a merger core?
Cost follows the number of interfaces, the number of tenants and products to configure, the sizing of the instance tiers and replicas, and the testing needed before cutover. Fineract itself has no license fee, so the spend is for infrastructure, configuration, integration build, security work, testing and ongoing support. Costs recur for infrastructure, licenses for surrounding tools, and support, while integration and migration tooling are largely one-time. Ask any partner for a written quote that lists each interface, each instance tier, the migration runs, the testing phases and the handover, with the assumptions behind each line.
Evidence auditors and regulators will ask for
This table lists the records a merger migration should produce, which system generates each one, and what an assessor will look for. DeployOpen prepares this evidence as part of the implementation, but independent auditors assess it, and no audit report or certification is issued by DeployOpen.
| Evidence item | Component that produces it | What an assessor checks |
|---|---|---|
| Migration plan and product mapping approvals | Ticketing, signed approval records and the Fineract product configuration export | Every legacy product maps to a named Fineract product, with accounting rules approved by finance and risk owners |
| Trial migration and reconciliation reports | Fineract, PostgreSQL queries and migration scripts | Client counts, loan and savings balances and schedules match the source core, with exceptions explained and cleared |
| Parallel run variance logs | PostgreSQL reporting queries, logging stack and reconciliation workbooks | Daily differences between cores are logged, owned, trended and closed before cutover is approved |
| Cutover approval and rollback test record | Ticketing, change records and runbooks executed in a rehearsal environment | A tested rollback path exists, with approvals from named owners and timestamps for each cutover step |
| Change management tickets for configuration and code | Ticketing system linked to version control and Fineract release records | Each product or code change has a request, a reviewer, a test result and a deployment record |
| Access reviews and activity logs | Identity platform, PostgreSQL audit logging and the logging stack | Migration staff and administrators hold only the access they need, and privileged activity is logged and reviewed |
| Encryption and MFA configuration evidence | Identity platform, TLS configuration, database settings and infrastructure configuration | Data in transit and at rest is encrypted and MFA covers every individual accessing the migrated systems |
| Vulnerability assessment and penetration test reports on the cutover environment | Security testing reports and scanner outputs for the cutover environment | Findings are classified, remediated or accepted with a documented owner, and results are retained before cutover |
| DORA register entries and exit plan references | Third-party register maintained by the institution, with links to the exit and transition plan | The ICT arrangement is recorded, the source core vendor exit is documented and the transition plan is tested |
Questions to ask an implementation partner before a merger migration
Start by asking which Apache Fineract migrations the partner has completed into production, and what those migrations looked like: how many source cores were retired, whether loans and savings moved in one cutover or by product, and how long the parallel period ran. Ask for references you can call, and ask them to describe one migration they would not repeat. Then ask how they map the acquired institution's products to Fineract product definitions, including interest accrual, fee and penalty rules, and day-count conventions, and who signs off each mapping. Ask how they build the general ledger opening balances from the acquired core's closing position, and which accounting entries they post to reconcile the two sides before go-live.
Next, ask how the partner runs parallel reconciliation. You want to know which reports they produce each cycle, how they match loan and savings balances, schedules and transactions between the source core and Fineract, and how breaks are logged, assigned and cleared. Ask how they set up tenants for the acquired book, including whether it sits in a separate tenant from the acquirer's clients, how the Fineract-Platform-TenantId header is used by channels during transition, and how tenant connections are recorded in the tenants database. Ask how rollback works: what the trigger conditions are, how long the source core stays available, and how transactions posted in Fineract after cutover are carried back if the decision is reversed.
Finally, ask how the partner keeps Fineract current during a live project. Fineract publishes official releases quarterly, so ask how they decide which release the migration targets, how they test upgrades against migrated data, and who owns the change calendar when a release lands mid-project. Ask for the evidence they will hand over for internal control over financial reporting and for DORA, such as the register entries for ICT services, the exit and transition plan for the source and target systems, and test records for restoration. Confirm in writing whether DeployOpen or another party would be the evidence owner, because DeployOpen prepares controls and evidence but auditors issue any assurance.
What do merger core migrations cost and how long do they take?
Does Apache Fineract have a license fee for a merger migration?
Fineract is licensed under the Apache License 2.0, so the software itself carries no license fee. The cost sits elsewhere. The project's README warns that a production deployment can be complex, costly and time-consuming, and that it does not provide a comprehensive production deployment guide. Your budget therefore has to cover product configuration, data mapping, integrations, infrastructure, testing, regulatory reporting and ongoing support. Some organizations also pay a vendor for deployment and maintenance, which is a services cost rather than a licence cost.
What drives the effort of a core migration after a merger?
Effort rises with five factors. The first is the number of loan and savings products that must be mapped to Fineract configuration, since each product carries its own schedules, fees and accounting rules. The second is data quality in the acquired core, including duplicate clients, missing KYC documents and inconsistent schedules. The third is the accounting rules, particularly how interest accruals and fee income post to the general ledger. The fourth is the number of integrations, such as payments, card, channel and reporting feeds. The fifth is regulatory scope, because the jurisdictions and obligations that apply to the combined entity determine evidence, retention and testing requirements.
Which costs are one-time and which recur after cutover?
One-time costs include discovery and product mapping, data extraction and cleansing, trial migrations, parallel-run testing, cutover support and the first round of integration and front-end build. Recurring costs include hosting and database operations, backup and restoration testing, monitoring, security testing, applying Fineract releases, which the project publishes quarterly, and the support retainer for the platform. Fineract's quarterly release cadence means upgrades are a standing line item, not a one-off project. Ask any partner to separate the two groups in the quote so you can compare recurring obligations across options.
What must our bank provide during a core migration?
The institution supplies the decisions and access that no implementation partner can make on its behalf. Product owners must confirm how each acquired loan and savings product maps to a target product. Accounting staff must sign off opening balances and the general ledger mapping. The project needs read access to the acquired core and its data, a named owner for data quality issues, and test environments. Finally, business users must set aside time for reconciliation review and parallel-run comparison. Agree these commitments in writing, because delays in sign-off are a common source of schedule slippage.
Can our internal team run a merger core migration without a partner?
An internal team can run a migration if it has staff who already operate Fineract or a comparable core in production, deep knowledge of both legacy cores, and capacity for parallel running and cutover at the same time as the merger's other workstreams. The key gaps are usually production deployment practice, tested rollback procedures and independent reconciliation. Assess these skills honestly before deciding. Many organizations choose a partner for the deployment, migration tooling and testing, and keep product, accounting and risk decisions in-house.
How is a fixed-scope quote formed for a migration?
DeployOpen does not publish a price list. Most engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. The scope should list the source and target cores, the products and accounts in each migration wave, the integrations to rebuild, the reconciliation and reporting outputs, the number of trial migrations and parallel-run cycles, and the cutover and rollback plan. Any change to these items changes the quote, so define them carefully at the start.
Why is no migration duration quoted, and what should we request?
No duration is quoted on this page because the time needed depends on the number of products, the quality of the acquired data, the accounting rules, the integrations and the regulatory scope described above. A duration given without that information would not be reliable. Instead, ask the proposal to state the phases, the entry and exit criteria for each phase, the number of trial migrations and parallel-run cycles, the client dependencies with their dates, and the assumptions behind the schedule. Ask how the partner will report progress and what would trigger a change request.
What should a merger migration proposal include about schedule and risk?
A useful proposal sets out the migration waves, the parallel-run period, the go or no-go criteria for cutover, and the rollback path if reconciliation fails. It should also name the client dependencies, such as product sign-off and data access, and state what happens if they slip. Ask how the partner will handle the acquired core's own change freeze and decommissioning obligations. Clear entry and exit criteria for each phase make it possible to compare proposals on substance rather than on a single headline figure.
How DeployOpen scopes and delivers a merger core migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where a merged institution's core will run. For a merger migration, that means DeployOpen works in the environment the combined bank controls, with the acquirer's change management and access rules applied from the start. Before scoping, ask the partner to confirm which environments it will touch and who holds privileged access to each one, because the target's systems and the acquirer's systems may sit under different administrators.
Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. For a migration, the written scope should name each portfolio and product in the migration waves, the product mapping sign-off, the reconciliation reports that must balance before cutover, the parallel-run period and the rollback criteria. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask your external auditor, and any regulator-facing reviewer, to confirm which migration evidence they will accept before the scope is signed.
DeployOpen also runs security testing of applications, APIs and infrastructure, which is worth scheduling against the migrated environment before go-live, and offers ongoing retainers for support, upgrades and continuous testing after cutover. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the quote to separate one-time migration work, testing, and recurring retainer effort, and to state which items depend on the reconciliation outcome. Because the cost of a merger migration is driven by the number of product variants and the volume of exceptions found in trial migrations, a scope that lists those counts explicitly gives you a quote you can compare.
