Every Technology Vote Should Include an Exit Plan

A practical article for community bank and credit union leaders on why every material technology decision should include a realistic exit plan, fallback path, and early warning...

It is easy to approve a new technology purchase when the demo is clean, the business case is tidy, and everyone in the room is a little tired of the current mess.

That is usually the high point.

The harder question is what happens later, when the vendor slips, the implementation drags, the price goes up, the integration behaves like a toddler in a church service, or the strategy changes and you need out.

Most boards spend far more time on the upside case than the exit case. That is backwards.

An exit plan is not pessimism. It is governance.

And it matters more now because community financial institutions are carrying plenty of complexity already. FDIC data for the first quarter of 2026 showed the number of community banks declined to 3,852 while total assets at those institutions still increased by $26.9 billion, or 1.0 percent, in the quarter. The same report showed community bank pretax return on assets at 1.42 percent. NCUA's first quarter 2026 data showed federally insured credit unions declined to 4,250, while return on average assets improved to 83 basis points at an annual rate year to date. In other words, these institutions are still growing and performing while their technology environments get more interconnected. That makes bad dependencies more expensive.

I have seen this pattern from several angles. In banking roles, in cloud work, and now in AI governance conversations, the same mistake keeps showing up. Teams work hard to get to yes. Almost nobody works hard enough on the conditions that would require a no later.

The applause is all at go-live

Nobody throws a party for the contract clause that preserves data portability. Nobody high-fives the person who insisted on a manual fallback process. Nobody posts on LinkedIn about the privilege review that proved a new vendor could be turned off without freezing operations.

But those are the decisions that protect the institution when reality shows up.

I have sat in too many meetings where the product demo got an hour and the exit discussion got five minutes. People wanted to know about features, speed, roadmap, AI capability, and implementation support. Fair enough. Those things matter.

But some of the most important governance questions sound much less glamorous.

How long would it take us to unwind this? Who owns the reversal decision? What data would be difficult to extract? What customer, member, or operational process breaks if this vendor has a bad quarter? How much manual work would come flooding back into the institution if this tool disappeared on a Friday afternoon?

If the room cannot answer those questions, the vote is not ready. The institution may still move forward. But it should at least do so honestly.

Example one: vendor dependence usually grows quietly

During my banking years, I learned that vendor dependence rarely arrives with dramatic music. It builds one workflow at a time. A report here. An exception queue there. An integration somebody wrote three years ago that nobody wants to touch. Before long, what looked like a product decision has become an operating dependency.

That is why I never liked the phrase "we can always switch later" unless someone could explain what "later" actually means.

Switch to what? In what sequence? Using whose staff? With what customer disruption? At what legal and operational cost?

The problem is not just contract language. It is accumulated convenience. Once staff build habits around a system, once downstream reports depend on its data structure, and once auditors and examiners get used to its evidence trail, the switching cost is no longer a line item. It becomes institutional gravity.

The 2024 FDIC guide on third-party risk management for community banks makes this point in polite regulatory language. Concentration, subcontractors, operational resilience, and contingency planning are not side issues. They are part of the relationship from the start.

Boards do not need to negotiate the file format of every export. But they do need to know whether management has priced the cost of leaving, not just the cost of buying.

Example two: cloud projects taught me that migration is only half the question

My years around large cloud migrations made this even more obvious.

At AWS and in partner roles, I watched plenty of organizations become very sophisticated about getting workloads into the cloud. They built migration factories, dependency maps, cutover calendars, and executive dashboards. Some of that work was excellent.

But even strong teams sometimes treated the destination like the end of the governance conversation.

Once a workload moves, new dependencies show up fast. Identity patterns change. Logging shifts. Backup assumptions change. Networking decisions become architectural commitments. Cost controls become their own operating discipline. And once a business process wraps itself around those choices, reversing course gets harder.

That does not mean cloud is bad. It means technology decisions compound.

The institutions that handled this best documented ownership clearly, tested failure scenarios early, and stayed brutally honest about what had become hard to unwind. That lesson transfers directly to community banks and credit unions. A platform does not have to be wrong to become risky. It only has to become too central, too opaque, or too expensive to challenge.

Example three: AI pilots fail differently, but the governance lesson is the same

AI brings the same issue into faster motion.

Most AI pilots start small. A summarization workflow. Internal drafting help. Customer service support. Policy research. Maybe document classification. All reasonable.

The risk is not that the first use case is enormous. The risk is that the workflow spreads before anyone has defined the stop button.

What happens if output quality drops? What happens if staff start relying on the tool in a higher-risk process than originally approved? What happens if the vendor changes terms, retraining rights, retention settings, or model behavior? What happens if your people quietly build adjacent workarounds because the approved workflow is too slow?

That is why I keep telling executives that AI governance is not primarily about the model. It is about the operating boundary.

An AI use case should have a clear owner, a clear allowed purpose, a clear data boundary, a clear audit trail, and a clear way to shut it off without paralyzing the surrounding work.

If you cannot stop a pilot cleanly, it is not really a pilot. It is an undeclared dependency.

Six questions I would want answered before any board-level technology vote

Here are six questions I would want answered in plain English.

1. What dependency are we creating?

Not the product category. The dependency.

Are we becoming dependent on a vendor, an integration path, a pricing model, a small internal expert group, or a data structure that will be painful to replace later?

2. What would trigger a reversal or redesign?

Name the conditions now.

Cost overrun. Security event. Service instability. User adoption failure. Regulatory concern. Vendor acquisition. Poor model behavior. If nothing can trigger reconsideration, the institution is not governing. It is just hoping.

3. What is the operational fallback?

If the tool is unavailable next week, how does the work get done?

Not forever. Just long enough to protect customers, members, and staff while leadership makes an adult decision.

4. How portable is the data?

This question gets ignored constantly.

Can the institution extract what it needs in a usable format? Is historical activity preserved? Can another system consume it without a heroic cleanup project? If not, the exit cost is probably higher than management wants to admit.

5. Who owns the exit decision?

In a crisis, committees become fog machines.

Name the owner. Name the escalation path. Name who can say "we are done here" if the risk curve changes.

6. How will the board know the dependency is getting worse?

This is the reporting piece most institutions miss.

The board should not wait for a full-blown failure. It should see earlier signals: rising exception volume, growing manual workarounds, increasing vendor escalations, unresolved audit issues, concentration concerns, or customer friction linked to the tool.

Good governance keeps options alive

The practical goal here is not to avoid every dependency. Running a modern financial institution means depending on technology, vendors, partners, and platforms. The goal is to avoid sleepwalking into dependencies you cannot challenge.

It forces management to think about reversibility before enthusiasm does what enthusiasm always does. It makes the board ask whether the institution is buying a capability or surrendering flexibility. And it reminds everyone in the room that implementation success and strategic resilience are not the same thing.

The best technology decisions I have seen were not driven by fear. They were driven by clarity.

What are we solving? What are we depending on? What would make us change course? Could we actually do it if we had to?

Those are not anti-innovation questions.

They are how serious institutions stay innovative without getting trapped by their own momentum.

Discussion questions

1. Which technology in your institution would be hardest to unwind today, and does the board understand why? 2. Where is management assuming "we can always switch later" without a real operational plan? 3. What early warning signal would tell your board that a useful tool is becoming a dangerous dependency?

Sources

• FDIC, Quarterly Banking Profile, First Quarter 2026
• NCUA, Quarterly Credit Union Data Summary, 2026 Q1
• FDIC, Third-Party Risk Management: A Guide for Community Banks, May 2024
• FFIEC, Architecture, Infrastructure, and Operations Booklet, June 2021