Keep the change contained.
Replacing a core banking system can bring much more than the core into scope. Applications that support everyday banking may depend on its interfaces, authentication and behaviour. Requiring those applications to change adds development work, vendor dependencies and releases to coordinate.
The institution wanted its collections and recovery, telephone-banking and loan-origination applications to work with the new core without being rewritten. It also wanted to avoid application-specific modifications to the replacement core.
The applications' endpoints were redirected to Avato, which adapted requests, responses and authentication. Their existing code and interfaces were retained.
Use the original core as a working reference.
Testing exposed differences that documentation could not fully explain: non-standard message structures, unexpected requests, and authentication or session behaviour that differed from the new core's expectations.
At authorized communication endpoints, Avato made messages visible before and after transformation. Configurable masking protected confidential values in diagnostic records. When a test produced an unexpected result, the team could run the same scenario through Avato against the original core to establish the behaviour the application expected.
The team could then adjust the adaptation in Avato and retest, instead of changing a functioning application to resolve the mismatch.
Make integration changes visible and testable.
Once the initial platform was in place, individual application integrations were completed in days to weeks. These were integration milestones within the broader banking conversion, not the duration of the conversion itself.
During collaborative testing, business specialists could run a scenario, review a discrepancy and retest after a transformation was adjusted and redeployed. Some correction cycles took approximately one minute.
Request-and-response records also helped isolate issues in the replacement core. As go-live approached, automated regression tests compared message fields across business scenarios and datasets, enabling the institution to detect unexpected changes and reject vendor releases that broke validated behaviour.
The design was reviewed with the core-banking vendor's technical architects and passed the institution's internal security, architecture and performance checks.
Demonstrate reliability in production.
In its first production year, Avato processed more than 400 million messages with no production defects, lost messages or outages reported to Avato.
These figures describe the platform's historical operation in this implementation, not the availability of the entire banking environment.
Build on the architecture for the next change.
Subsequent work added member alerts and integrated insurance calculations into banking workflows that had previously relied on disconnected, manual steps.
For member alerts, accepted messages were committed to durable storage before acknowledgement. If a destination was temporarily unavailable, the messages were retained and delivery was retried when it recovered.
A later contact-centre modernization reused established interfaces, transformations and orchestration. The new environment coexisted with the existing one during transition, and production cutover involved only a brief interruption to member services.
The same separation that protected applications during core replacement now supported changes to surrounding services. Each initiative built on established integration assets rather than becoming an entirely new integration project.
Change the system that needs to change. Preserve the capabilities that still work. Leave a foundation that makes subsequent change easier.