A practitioner’s note on what happens after the core conversion ends
Pick up any credit union trade publication from the last five years and search for “core conversion.” You’ll find plenty of articles with checklists for picking a vendor, cleaning your data before migration, or communicating the change to members. You’ll also find first-person accounts of go-live week, full of late nights and adrenaline, and the eventual relief when the new system stays up through the first month-end close. Then the articles taper off.
What happens 12, 18, 24 months after go-live is surprisingly hard to find. There are understandable reasons it goes unwritten. Vendors have little incentive to dwell on the work that remains after go-live, since it complicates a clean implementation story. Implementers have usually moved on to the next account. The credit unions that lived through it are often too depleted to write it up and are worried that saying “we’re still cleaning up” will read like an admission of failure to a board that signed the check.
We have a rich literature on how to survive a core conversion and comparatively little on what to do after you’ve survived it. That’s worth fixing, because survival isn’t the win. The win is what you do with the new system in the 24 months after the implementers leave.
The pattern I keep seeing
I do fractional CIO work, mostly for institutions in higher education and the broader nonprofit-adjacent space, but the pattern transfers cleanly to credit unions and CUSOs. Here is what it looks like.
An institution goes live. The first 90 days are about keeping the system up—the tickets that came in on day one get triaged, the worst configuration errors get patched, and the staff who couldn’t find the new screens get retrained. By month four or five, the system is stable. People stop complaining as loudly. Leadership exhales. The project team disbands. The implementation partner offboards. Everyone moves on to the next priority. And then somewhere around month eight, three things start to surface, all at once.
The first is that the business processes never actually changed. The new system can do things the old one couldn’t, but staff figured out how to make it behave like the old one because that was faster during the conversion. The promised efficiency gains never materialize because nobody has the bandwidth or authority to redesign the underlying processes now that the project is over.
The second is integration debt. During the conversion, the implementation partner stood up just enough integrations to get to go-live. The harder ones—the ones that touched member-facing channels, the reporting layer, the third-party fintech relationships—got point-to-point patches or manual workarounds. Those workarounds are still running 18 months later, costing real money and quietly degrading data quality.
The third is the reporting and analytics layer. The new core has a different data model. The reports nobody got around to rebuilding are now critically out of date, the executive dashboards everyone relied on are subtly wrong, and the analytics conversations the credit union wanted to have about member behavior are happening on a foundation no one quite trusts. None of this shows up on a project status report because the project is closed.
The missing role
We treat the post-implementation period as the absence of a project, when it’s actually a different kind of project. It doesn’t have a defined scope, a defined end date, or a vendor-funded program manager keeping it on the rails. But the work is real and ongoing. The accountability for it is not.
The role that’s missing is governance leadership. Not more implementation hours. Not more vendor support tickets. It’s someone with the authority to say “this business process still needs to be redesigned,” “this integration needs to be properly built,” “this reporting layer needs to be reconstructed,” and then to make those things happen when the rest of leadership has moved on.
In larger institutions, that role gets filled by the CIO or the COO. In mid-sized credit unions and the CUSOs that serve them, that role often doesn’t exist at all—or it exists in name only, attached to someone who is also responsible for running the day-to-day technology environment and has no slack for governance work on top of operations.
What CUSOs could do
The cooperative model is, in theory, perfectly positioned to address this. CUSOs exist precisely to consolidate capabilities their member credit unions can’t justify individually. Post-implementation governance leadership is one of those capabilities. It’s expensive to staff full-time at a single mid-sized credit union, but it’s well within the reach of a shared service across a CUSO membership. It’s worth writing about.
