Eventually, every business owner gets the email. The vendor is changing. The pricing is going up, the product is being sunset, the company is being acquired, the contract is not being renewed. Whatever the reason, the system you've been running on is going away, and you have to switch.
The new option is usually fine. Sometimes it's an upgrade. The hard part is rarely the new system. The hard part is everything you built on top of the old one.
A laundromat owner ran into this last year. He was switching his payment system to a new vendor. The new system was a better fit, easier for staff, and the pricing made sense. There was one problem. His customers had prepaid cards. Real cards in real wallets, with real money on them. Some had a few dollars. Some had a hundred. The community trusted him to make those cards keep working. The new vendor had no way to import the balances.
He could have eaten the loss. Refund every customer, take the hit, move on. In a small community where the same families do laundry for years, that meant thousands of dollars and a stack of awkward conversations. He did not want to start his new system by taking money out of his customers' pockets.
He called me to figure out the bridge.
What "Switching Vendors" Actually Means
The new vendor sells a payment system. They don't sell migration. Most software vendors don't. Their job is the new product, not the cleanup of whatever was running before. That gap is one you have to either close yourself or pay someone else to close.
In this case the old vendor had stored card balances in a PostgreSQL database. The new vendor used a different system entirely. Two database engines, two schemas, two file formats. Nothing about them was designed to talk to each other.
The work was unglamorous. Pull a database dump from the old vendor. Parse the table that held the card data. Convert the balance values from the format the old system used to the format the new system needed. Import everything in a way that could be re-run safely if anything went wrong, because nothing this important should depend on getting it right the first time.
It is not exciting work to describe. It is the work that decides whether the new system launches with happy customers or with a hundred phone calls about missing money.
The Tool at the Counter
The migration was half the project. The other half was a tool the staff could actually use.
A customer walks up to the counter holding their old card. The staff scans the barcode. The screen shows the balance. If the customer wants their money back, the staff records the refund right there, and the system locks the card so it cannot be refunded twice. Every scan, every refund, logged with the timestamp and the operator who handled it.
It is a small interface. Two screens, really. But it had to work the way a real counter works. The input field auto-focuses so the scanner just works. The lookup triggers the moment the card number is long enough. No clicking around, no extra steps, because there is a customer waiting and a line behind them.
The technology under the hood does not matter to the staff or the customer. What matters is that the card scans, the balance shows, and the customer leaves whole.
What This Was, and What It Wasn't
There was no AI in this project. There did not need to be.
This was an integration problem. Two systems that did not speak to each other, a business that needed them to, and a community of customers whose trust depended on the bridge being built right. The toolbox for this kind of work is older and quieter than AI: database engineering, data validation, careful migration patterns, and an interface designed for the actual conditions on the counter.
A consultant walking in with an AI hammer would have either declined the project or pretended the hammer was the right tool. The right tool here was a script that ran once, a database that held the bridged data, and a tool the staff could use without training. That is the whole project.
When You Get the Email
The new system is rarely the hard part. The hard part is the data, the workflows, and the customer expectations your old system has been quietly carrying for you. Switching vendors is easy. Switching vendors without dropping any of that is the work.
If the email is sitting in your inbox right now, that is a conversation worth having before the migration date arrives. Sometimes the fix is small. Sometimes it is structural. Knowing which is the first step.