By Donald D. Hook — Former CTO & CIO, Full On Consulting | July 2026 | 7 min read
Over the weekend, the bank we use for our corporate account was acquired and cut over to the acquiring bank's systems. By the time I opened the app, I was looking at a stranger's account. What follows is a customer's-eye view of a go-live that went wrong — and a reminder that the most expensive failures are almost never about the technology.
What I Saw
The cutover wrapped over the weekend. The next day, out on the road, I pulled up the mobile app to see how it had gone. At first glance, everything looked fine. Then I opened my profile — and it wasn't mine. A different name. A different customer's information, staring back at me.
The questions came fast, and they are the same questions any customer would ask: Can they see my account? Is my money safe? Will my statements go to them? What, exactly, just happened here?
I tried to correct it myself. The profile wouldn't let me edit anything. So I called support — and waited on hold for two hours. When I finally reached a representative, she pulled up my account and confirmed what I was afraid of: she was seeing the other person's information too. Then she tried to help me update my profile and couldn't navigate the new app herself. Several holds later — "let me check with my manager" — the other customer's data simply disappeared from the screen. I still do not know what was done behind the scenes. I was told everything was fine. We will see. I am monitoring the account closely.
The Red Flags
I do this for a living, and I counted the warning signs before I hung up. None of them are exotic. Every one of them is preventable.
1. Testing was inadequate
One customer's data appearing under another is not a subtle edge case you reasonably miss. It is the kind of defect that end-to-end testing exists to catch. Reaching production means the system was validated on optimism, not evidence.
2. The data migration was broken
A contact is tied to an account by a key — basic database structure. For one customer's profile to surface under another, the extract-and-load step mismapped the relationship between accounts and their contacts. Migration reconciliation is designed precisely to find this before anyone logs in.
3. Support was not ready
A major cutover weekend with two-hour hold times, and representatives who could not navigate the new application, means support was neither trained nor staffed for go-live. The busiest, highest-anxiety moment in the customer relationship was met with the least readiness.
4. There was no communication
Not a word to customers about known issues — before, during, or after. Silence during a crisis is itself a decision, and it is the wrong one. A short, honest note ("we are aware of display issues and your funds are secure") would have defused most of the fear.
5. The playbook failed
Any organization that does serious M&A develops a conversion playbook — a repeatable template that exists to ensure consistency and accuracy and to save time on the next deal. Either this playbook was wrong, or it was not followed. Both are leadership failures, not technical ones.
It Rolls Uphill
Here is the part most people never see. A failure like this does not stay in the IT department. It climbs.
Did the CIO review the go-live plan? Was the CIO given honest information about testing coverage and the team's actual readiness — or a comfortable green status that concealed the risk? Because the moment a customer sees someone else's data, it is no longer an IT problem. It is the CEO's reputation, live, in the customer's hand. The CIO's credibility and the CEO's standing with customers are both damaged in the same instant — and trust, once shaken, is expensive to rebuild.
The Pattern Behind Every Rescue
The most expensive failures I have ever been called in to fix were not caused by hard technology. They were caused by go-live decisions made on optimistic information — a date that had to be hit, a status that had to stay green, and no independent voice in the room asking whether the organization was actually ready. The technology usually works. The governance is what breaks.
The Questions to Ask Before Go-Live
If you are a CEO or CIO facing a cutover — a merger integration, a core system replacement, an ERP or platform go-live — these are the questions that separate a smooth launch from a headline:
- Testing: Was full end-to-end and data-migration testing completed, and what did the results actually show — not "is it done," but "show me the evidence"?
- Rehearsals: Were at least two or three full cutover dress rehearsals run against production-like data, timed and documented?
- Go/No-Go: Are the go/no-go criteria written down, and does a named decision-maker have the authority — and the courage — to delay?
- Support: Is the support organization trained on the new system and over-staffed for cutover-weekend volume?
- Communication: Is there a customer communication plan for known issues, ready to send the moment something slips?
- Independent verification: Did an outside party with no stake in the date confirm readiness — or are you relying solely on the team that is incentivized to go live?
That last question is the one that matters most. The team doing the work is rarely the team best positioned to tell you it is not ready. The date should serve readiness — never the other way around.
Facing a Cutover You Can't Afford to Get Wrong?
Full On Consulting provides independent go-live readiness reviews, M&A IT due diligence, and program recovery — led by a former CTO and CIO who has run these programs and been called in to rescue them. We give you the honest read the delivery team can't.
Program Health CheckTalk to UsRelated Reading
M&A IT Due Diligence
How to de-risk the technology side of a merger or acquisition before it becomes a headline.
Read →Project Recovery
When a program is already off track, we step in and operate the turnaround.
Read →ERP Failure: CEO Warning Signs
The early signals of a program heading for a very public failure.
Read →How to Build a Successful Program
The governance discipline that keeps a go-live from becoming a crisis.
Read →What a Real IT Project Leader Looks Like
How to spot the leaders who own delivery — and the ones who report green until it's red.
Read →Program Health Check
An independent read on whether your program is really as healthy as the dashboard says.
Read →Frequently Asked Questions
Why do system cutovers fail after a merger or acquisition?
Most M&A system cutovers fail for non-technical reasons: insufficient end-to-end testing before go-live, data migration that was validated on optimism rather than evidence, support teams that were neither trained nor staffed for the volume of a cutover weekend, and no proactive communication to customers about known issues. The technology is rarely the root cause. The root cause is a go-live decision made on incomplete or optimistic information, without independent verification that the organization was actually ready.
How can exposing one customer's data to another happen in a cutover?
Cross-account data exposure almost always traces to a data migration error — records extracted from the legacy system and loaded into the new one with broken or mismapped relationships between accounts and their associated contacts or profiles. In a well-structured database, a contact is tied to an account by a key, so this is not a subtle edge case; it is the kind of defect that thorough migration testing and reconciliation are specifically designed to catch. When it reaches production, it signals that the migration was not adequately validated before go-live.
What questions should a CEO or CIO ask before a go-live?
Before any major go-live, leadership should confirm: Was full end-to-end and data-migration testing completed, and what were the results? Were multiple cutover dress rehearsals run against production-like data? What are the documented go/no-go criteria, and who has authority to say no? Is the support organization trained and staffed for cutover-weekend volume? Is there a customer communication plan for known issues? And critically — did an independent party verify readiness, or is leadership relying only on the status reported by the team doing the work?
Who is accountable when a go-live goes wrong?
Accountability rolls uphill. The CIO owns the go-live decision and is responsible for ensuring they received honest information about testing and readiness rather than an optimistic green status. But the moment customers are affected — seeing another person's data, unable to access accounts, unable to reach support — it stops being an IT problem and becomes a reputational event for the CEO and the entire organization. A botched cutover damages the CIO's credibility and the CEO's standing with customers simultaneously.
How do you prevent a cutover failure?
Prevention comes from disciplined go-live governance: complete and evidenced testing (including data migration reconciliation), a minimum of two to three full cutover dress rehearsals, explicit go/no-go criteria with a named decision-maker empowered to delay, a support organization trained and over-staffed for the cutover window, a customer communication plan for known issues, and — most importantly — independent verification of readiness. An outside party with no stake in hitting the date will surface the risks the delivery team is incentivized to minimize. The date should serve readiness, not the other way around.