Their Old Software Worked Fine. That Was the Problem.

Here's a sentence we hear more than you'd expect: "Honestly, the old system works fine."

It usually comes with a shrug, right before the same person explains why they can't grow, can't hire fast enough, or can't tell which customers are about to drift away. "Works fine" and "works for where we're trying to go" turn out to be two very different things.

We worked with a custom apparel and decoration shop that had been in business for more than a decade. Embroidery was the bulk of their sales. Over the years they'd added screen printing, then a handful of newer decoration methods. By any normal measure, they were doing well. Busy season was genuinely busy.

And they ran almost all of it on a piece of software one of their own people had built years earlier.

That homegrown tool was the quiet hero of the whole operation. It tracked work orders, due dates, job priority, shipping details. The team knew it cold. They could fly through it without thinking. So when they first called us, the ask sounded simple: help us move onto a real production platform so we can scale.

What they thought they were buying was new software. The real project was something else entirely.

The problem wasn't the tool. It was everything stuck inside it.

Once we got in and looked around, the pattern was clear, and it's one we see constantly.

The old system worked. But it had quietly become a vault. Years of order history were in there, and nobody could actually query it. Want to know which customers reorder every spring, or how long a certain job really takes to run versus what you quoted? Good luck. The data existed. It just wasn't reachable in any form you could use to make a decision.

It got worse the closer we looked. A lot of what kept the shop running wasn't written down anywhere at all. It lived in people's heads. The exact setup for a repeat customer's logo, the thread colors, the machine settings, the little "we always do it this way for them" details. One person knew. If that person was out, or a newer operator ran the job, the work could come out just a little different, and in a business built on repeat orders, "a little different" is how you lose a client.

Then there were the vendor catalogs. Millions of rows across different suppliers, each formatted its own way, half of them missing sizes or color options or clean part numbers. The information the shop needed to quote accurately was technically available and practically unusable.

So here's the honest diagnosis we gave them. You don't have a software problem. You have a data problem wearing a software costume. Buying a shinier platform and dumping all of this into it would just move the mess to a nicer address.

What we actually did

The glamorous part of this project was the smallest part. Most of the work was unglamorous on purpose.

First, we freed the data and cleaned it. We pulled the vendor catalogs apart, deduplicated them, and cut them down from hundreds of thousands of rows to the couple hundred products the shop actually sells. Not everything. The stuff that matters. We brought the order history across so no customer's past showed up blank on day one.

Second, we planned the switch so nothing dropped. This is the part people underestimate. You can't just flip a running business onto new software on a Monday. So we did it in phases. Open orders stayed in the old system until they shipped. New orders went into the new platform. For a stretch, both ran side by side, on purpose, until the old one was down to a handful of jobs and then nothing.

Third, only after all of that, we turned on the useful automation. Follow-ups that fire around the time a customer is actually likely to reorder. Review requests that don't pester someone who already left one. Simple segmentation so a camp, a booster club, and a company store don't all get the same generic blast. This is the stuff that reads like magic in a sales demo. It only works because the boring part came first.

The part we were careful about

If there's a theme to how we run these projects, it's this: the technology is rarely the risky part. The people are where it goes wrong or right.

A few things we did deliberately, and would do again:

• We staffed the transition like it was hard, because it was. The team had done their jobs for years without thinking. Now every small task felt slow and foreign. They were stressed, and honestly, they had a right to be. So we didn't hand them a login and wish them luck. We were on call daily through the rough stretch, answering the small questions, reminding everyone that slower-for-now is normal during a changeover.
• We imported what mattered, not everything. Dumping a full vendor catalog into a clean system feels productive. It isn't. It buries the hundred things you use under the hundred thousand you don't. Less, but correct, beats complete and useless every time.
• We cleaned the list before we mailed it. When they went to send a seasonal campaign, a test of the existing contact list surfaced hundreds of dead email addresses. That's not a failure. That's the system doing its job, showing us the mess before it embarrassed anyone. So list cleanup came first, campaigns second.
• We said no to the big build, for now. There was an appetite to construct a full custom customer platform on top of everything. We pushed it to later. Not because it's a bad idea, but because a team mid-changeover can only absorb so much. Overbuilding ahead of what people can actually use is just a prettier way to fail, which is often why an AI pilot works in the demo and then changes nothing in the real work.

Notice what AI did and didn't do here. It read the mess. Millions of messy rows, years of locked-up history, a contact list nobody trusted, and it surfaced the few things that actually mattered. What it didn't do was replace a single person on that floor. The operators still run the jobs. The owner still makes the calls. We just stopped making them fight their own tools to do it.

The lesson you can take to your own business

You probably have a version of this somewhere. A spreadsheet everyone's afraid to touch that already holds the answer you keep guessing at. A tool one person understands. A pile of data you know holds answers you can't get to.

When "the old system works fine" is quietly capping your growth, two things are usually true.

First, the real risk in upgrading isn't the new technology. It's the switch, and the switch is a people problem before it's a technical one. Plan it around the humans doing the work. Let old work finish where it lives. Staff the messy middle. Expect slower before faster.

Second, before you go shopping for a smarter tool, ask a harder question. Is my problem really the tool, or is it that my own information is trapped and dirty? Because AI is genuinely good at reading a mess and pulling out what matters. It is useless on data it can't reach or can't trust. Clean, reachable data isn't the boring prerequisite to the exciting AI project. It is most of the project.

Get that right and the fancy automation almost installs itself. Skip it, and you'll have spent real money to automate a mess, which, as we've said before, just helps you make the same mistakes faster.

If your business is running on a system that "works fine" but you can't get your own data out of it, or you're staring down a switch and dreading what it'll do to your team, that's exactly the kind of knot we help untangle at Humanity AI. We tend to start with the unglamorous part, because that's usually where the real problem is hiding.