Financial institutions run payments, accounts, transactions, and compliance reporting on applications, many built on legacy technology. Modernizing them means changing systems that have to keep running while they are changed. A recent guide to financial services application modernization by Manish Kumawat, CEO of Fulminous Software, published on Finextra’s community blog, sets out six modernization approaches and a seven-step process. The page states that Finextra publishes external-author content without editing, and the guide includes advice on selecting modernization providers, so treat it as vendor-published. This article uses its framework, concentrates on the parts that affect operational resilience, and ends with a recommendation.
The six approaches
| Approach | What it does | Benefit named in the source | Limitation named in the source |
|---|---|---|---|
| Rehost | Moves the application to new infrastructure with minimal change. | Quick; limited application change; lower initial effort. | Does not fix architectural or code-level problems. |
| Replatform | Moves to a newer platform, for example a managed database, with limited changes. | More benefit than rehosting without a rewrite. | Change to the application itself is limited. |
| Refactor | Changes internal structure while preserving core functionality. | Easier to maintain, test, scale, and modify. Keeps valuable business logic. | Not stated in the source. |
| Re-architect | Substantial architecture change: modular design, APIs, event-driven systems, cloud-native infrastructure. | Significant long-term benefit. | Requires more planning and technical expertise. |
| Rebuild | Develops a new application while retaining requirements and knowledge from the old one. | Suits platforms that are extremely difficult to maintain. | Business logic can be lost in the transition. |
| Replace | Adopts a commercial or newly developed solution. | Suits cases where maintaining the current application costs more or carries more risk. | Not stated in the source. |
The source gives no cost figures, timelines, or outcome data for any approach. It lists the factors that drive cost, such as application size, integrations, and data migration, and recommends an assessment before setting a budget. Costs are unknown from this source.
Where resilience enters
The article does not frame resilience as a theme of its own. Several items it lists bear directly on it:
- Downtime: financial services often operate continuously, so migration strategies should minimize interruption and include rollback or recovery procedures.
- Hidden business logic: important rules may exist in old code, database procedures, or integrations without documentation. The author calls this one of the biggest risks.
- Undocumented dependencies: batch jobs, databases, and third-party systems that make the work harder than first expected.
- Payments: modernization should protect transaction integrity and availability, and can be done incrementally instead of replacing the whole platform at once.
- Testing: the list includes regression testing, data validation, and disaster recovery testing.
- Compliance: modernization should not weaken existing controls during migration. The source names auditability, logging, monitoring, business continuity, and change management.
- After deployment: monitor transaction failures, error rates, and system availability.
Each item is a way for a change project to reduce the availability or integrity of a running service. That is our reading, not the author’s. It suggests resilience requirements belong in the project as acceptance criteria, not as a testing activity at the end.
In the regulated environments we deliver in, the surrounding controls already exist: change advisory boards, segregation of duties, security and audit review, formal acceptance, business continuity, and documentation retention. Program delivery also already produces the artifacts that can carry these requirements: dependency lists, risk, issue, and change logs, acceptance criteria, and a handover to operations.
Suggested resilience acceptance criteria
The source names the areas but gives no thresholds. The criteria below are our suggestions and should be adjusted to the application:
- The business-rule inventory is signed off by the business owner before code changes begin.
- The dependency list, including batch jobs and third-party feeds, is checked against production activity, not only documentation.
- Rollback has been tested before cutover, with a named owner and a defined decision point.
- Data migration is validated by reconciling record counts and balances between source and target.
- A recovery test has been completed in an environment representative of production, with the recovery time recorded.
- Monitoring for transaction failures and error rates is live before go-live, with named responders.
Risks
- Treating rehosting as modernization. The source states that a rehosted application may still behave like a legacy application.
- Losing business logic in a rebuild.
- Replacing a payment platform in one step. The source recommends incremental modernization.
- Weakening compliance controls during migration.
- Relying on a vendor-published framework that provides no outcome data.
Recommendation
Default to incremental modernization of the business-critical components. Keep the legacy application running behind an API layer until each component is proven, which matches the phased sequence the source describes. The other options apply in narrower cases:
- Rehost only when the immediate goal is leaving specific infrastructure and the team accepts that the architecture stays as it is.
- Rebuild or replace only after the business-rule inventory is complete and signed off.
The process, in order:
- Assess and document the current application: architecture, dependencies, integrations, security controls, and business-critical functions.
- Identify the business-critical components and prioritize them.
- Select an approach for each component, not one approach for the whole portfolio.
- Write the roadmap, including what stays unchanged, the data migration plan, and rollback plans for each phase.
- Write the resilience acceptance criteria before development starts.
- Modernize one component at a time and prove each before moving on.
- Test for functionality, integration, security, performance, regression, data, and disaster recovery.
- Monitor after deployment and keep a named owner for the results.
The simplest approach is to change one component at a time and prove each one before moving to the next.
Sources
- Kumawat, Manish. “Financial Services Application Modernization: A Guide to Modernizing Legacy Fintech Systems.” Finextra Research community blog, September 1, 2026. finextra.com