Your acquisition closed. Who can explain the systems you bought?

On Tuesday 8 September 2026, the day after Labor Day, Comerica Bank became Fifth Third Bank. Some 300 branches and 600,000 accounts changed over in one night. FOX 2 Detroit reported crowded lobbies, long waits on the phone and online, and customers who could not reach all of their accounts, some told to try again the next day. One customer spent her whole day driving to a branch¹.

The bank said it had spent months preparing customers and picked the day after the holiday so it could bring in extra staff. Its regional president told customers their money “didn’t go anywhere” and was safe, and that debit cards kept working¹.

The report does not say why customers were locked out, and this post does not guess. What it shows is the pressure a conversion puts on a company: everything the acquired systems did has to be reproduced somewhere else by a fixed date, in front of customers.

What does a cutover ask for that a deal never did?

A deal asks about assets, contracts and headcount. A cutover asks questions like these:

• Why does this account type get this fee waived?
• Why does this product pay interest on the 1st and not the 15th?
• What happens to a customer who is in the old system’s special case?

The acquired code answers the first half of each: what happens. It does not say why, and in an acquisition the people who knew often have a new employer, a new boss or a vesting date approaching.

When do you find out you don’t know?

Usually at the worst time. The integration plan lists systems and dates. The rules inside the systems are discovered while the migration runs, one customer complaint at a time. By then you are choosing between copying a rule you do not understand and dropping one you cannot explain.

What do teams do instead?

They try to ask earlier. A few habits that help:

1. List the rules before the plan. Know which rules sit in the systems you intend to merge, migrate or retire.
2. Rank by what the integration touches. Fees, rates, eligibility and limits come first.
3. Ask the people who built them while they are still there, a few questions a day, not a week of meetings in their final fortnight.
4. Record who owns each rule after the move. The old owner’s answer, name and date go with it.

AppThentic is built for this. It reads the acquired systems and lists every business rule with its status, so you can see what is understood and what is not. Each owner gets a few questions a day, scheduled ahead of their transition date. Each rule is then handed to someone on your team, with the original owner’s approved answer attached. After they have gone, your team asks Organization Memory, not a former employee. Rules you drop are recorded with who decided to drop them. See After an acquisition.

What is the test?

Pick one acquired product. Ask who on your team can explain, without opening the code, why it charges what it charges. If the answer is a name that appears on the other company’s payroll, start asking now.

Does preparation fix it?

Preparation helps customers, staff and calendars. It does not by itself recover knowledge that sits in someone’s head. A bank can staff its branches for months and still find that a single account type behaves in a way nobody on the new team can explain. The cheaper time to find that out is before the cutover date, while the person who knows is still reachable.

Sources