New software gets the money and the demo. The cutover gets a Saturday. That Saturday decides whether anyone is still using the system a month later.
By Justin Pennington, founder of Infraxio, Ponte Vedra. Originally published on penningtonj.com.
Here's a sentence I hear in almost every kickoff: "The data can come over on a weekend."
It's said casually, usually right after a clean demo, by someone who has already approved the budget for the new CRM, ERP, or hub. Nobody pushes back, because the move looks like a file transfer. Export, import, done.
Then Monday comes. Someone searches for a customer and gets three versions of the same company. A status field shows values that meant something different in the old tool. Accounts nobody has called in years sit right next to the ones from this week. The team decides the new system is broken, quietly reopens the spreadsheet they trust, and the project starts dying from there.
I run Infraxio out of Ponte Vedra, and most of what we deploy for operators around Jacksonville and St. Johns County replaces something older: a spreadsheet, an aging CRM, or a pile of tools that never agreed with each other. After enough of these, I've stopped treating the migration as a chore at the end. It's the actual project.
The import file is the easy part
Moving rows is mechanical. The hard part is the handful of decisions buried inside the move, and nobody puts those on the schedule.
Which history is worth carrying. Bring the open work, the customers someone will call this month, the prices that are still real, and the last clean record of any job someone might ask about. Years of closed items nobody opens should go to a searchable archive. If you migrate every old row, this week's customer gets buried, and the search function takes the blame.
Which records are the same thing. One customer under three spellings. A vendor from a contract that ended years ago. A contact who stopped answering long ago. A script can suggest matches, but only someone who knows the accounts can say which records are actually the same company.
What a field means now. In the old CRM, "status" was basically a mood. In the new system it's a step with a next action attached. On the spreadsheet, "customer" might have meant a site, the company that pays, or a person. Mapping fields is really an agreement about language. Skip it, and you copy the old disagreement into the new system, which is how reports start to lie.
The spreadsheet nobody bought. Every department has one. It isn't on the systems list because nobody purchased it, but it holds the exceptions, the prices people won't put in the CRM, and the notes that never had a field. If a department makes decisions from that sheet, the sheet is in scope. Leave it behind and you've migrated the decoration, not the business.
When the old system stops taking new work. Run old and new side by side only long enough to check the new records against the ones people trust. Then pick a date and make the old system read-only. Without an end date, people keep updating whichever system they like better, and the new one falls behind for good.
AI made the build shorter, not the decisions
Since we adopted AI, Infraxio deploys a full business hub in under three weeks. The same kind of deployment used to take four to six months.
That speedup is real, but it changes where the time goes. Configuration and a first pass at field mapping are now fast. Deciding which customers are real, which history a department still depends on, and which spreadsheet is the actual record didn't get any faster. Those are decisions about what the business is, and they're now a much larger share of the work.
An agent can draft the field map, flag likely duplicates, and stage the import. A person who uses that data every day still has to look at the draft and accept it. It's the same rule I use anywhere AI touches operations: the agent does a piece of the work, and a person reviews it before it counts.
Five things to do before the first import
- Move what people use weekly; archive the rest somewhere searchable. If a record isn't part of this month's work, it doesn't belong in the working system.
- Give each set of records one owner. Customers, open jobs, prices, contacts, carriers. When two records disagree, one named person decides which is real. A shared folder doesn't count as an owner.
- Run a dry-run import and let daily users reject it. Not the person who signed the contract, but the person who looks up customers, writes bids, schedules dock doors, or sends invoices. Ask whether they'd work from that sample tomorrow. That's user acceptance testing, done before the company depends on the data.
- Set the cutover date and make the old system read-only. Parallel running should be a short check with an end. After that date, the old system is for lookups only.
- Write down what you chose not to move, and why. Someone will ask in six months, and the reason should still be there.
Fund the move like you fund the software
The pattern is the same whether it's a client hub, a growth system, a bid workflow, or a dock schedule. The software is the half you can demo. The migration is the set of calls about the business itself: which customers are current, which history still matters, what a field means, which spreadsheet has been running a department, and the day the old way stops taking new work.
A clean import of bad data is still bad data, and on day one the new system is the one that looks broken. Give the move a real budget, an owner for every set of records, and a date on the calendar.
Justin Pennington is the founder of Infraxio, a product studio in Ponte Vedra, Florida, that builds IFX Hub, Growth7, IFX Bid, and DockOps. More essays at penningtonj.com. This piece is adapted from The Migration Is the Project.
