Your core is almost certainly doing its job. The harder question is whether the infrastructure around it still is. Tom Vermette of OpenETX and Joseph Kasal of NexusTek spend 47 minutes on the change request that sits for six weeks, the nightly batch that quietly crept from 2am to 5am, and the recovery plan that reads well and has never been run end to end.
Tom Vermette.png)
Joseph KasalNo slideware and no product tour. Tom and Joseph work through the problem the way it actually shows up inside a bank, then take it apart.
Nobody decides to let the infrastructure fall behind. It accumulates: a system, a workaround, an integration. Five years later the constraint is not any one thing you can point at, which is exactly why it never makes the project list.
Refresh cycles are coming due across much of the market at the same time. Examiners ask harder questions about resilience and third party risk than they did three years ago. And hiring infrastructure people got materially harder, so absorbing the problem with headcount is less available than it used to be.
You move on your own timeline, reach your own data without filing a request, and get to say yes to things. The honest cost: you take on a relationship you have to actively manage. Tom and Joseph say so out loud rather than selling a version with no trade-off.
Recovery is usually assembled rather than designed: a backup product, a replication tool, a runbook, and manual steps that live partly in one person's head. Every piece works. What has never been exercised is all of it together, in order, under pressure.
Discovery first, because that phase matters more than anything after it. Then a phased migration rather than one weekend, and a fail-back plan worked out in as much detail as the migration plan. As Joseph puts it, the risk is almost never in the move.
“You’re in it every day. If it’s two minutes later this week, and two minutes later, you don’t really feel that.”Tom Vermette, OpenETX
“If there’s a Lego on the floor, we want to make sure both NexusTek and OpenETX know exactly who is responsible for picking up that particular Lego.”Joseph Kasal, NexusTek
“Look at the timing of a DR test like a big ice cube. Every time you do it, that ice cube should get smaller.”Tom Vermette, OpenETX
Tom’s last test had batch jobs running again about ten minutes after failover. Joseph is straight about the spread: a client with a more complex approval chain takes eight hours, and he opens the answer with “your mileage will vary.” What both of them rule out is the old number. As Joseph puts it, nobody is talking about 24 to 48 hours any more.
These came from the audience, and they are the uncomfortable ones. Tom and Joseph answer them directly.
How is this different from a hosted core provider, which is what a lot of us were trying to get away from?
We refreshed our servers 18 months ago. Is there a real reason to have this conversation now?
Where is the line between what our team should own and what belongs with a partner?
What does a well run transition actually look like, and where does the risk really sit?
What do examiners want to see when infrastructure sits with a third party?
Two questions you can use Monday morning to pressure-test your own environment.
One runs what happens on top of the platform. The other runs the platform underneath it. They do not agree about everything, which is the point.
Works with banks, credit unions, and fintechs on what happens above the infrastructure line: the operating model, the change process, and the decisions a team keeps for itself.
Spends his days under the hood of these environments. Brings the view from inside the platform: what degrades first, what recovery actually takes, and where a transition goes wrong when it goes wrong.
If you run or support a core banking platform and your team is smaller than the surface area you are responsible for, this session was written for you.
Especially if someone has asked recently how long it would take to come back up, and you could answer the first half of that question but not the second.