The Migration That Was Never Going to Be Simple

For Brad White, migrations are a normal part of running VARC Solutions. But “normal” doesn’t mean easy.

Moving a business from QuickBooks Desktop to QuickBooks Online can be far more complicated than simply transferring information from one system to another. The two platforms work differently, and businesses often want to bring years—even decades—of historical data along with them.

The problem is that the data itself may not be clean.

A company might have years of poorly maintained books, unreconciled accounts, inconsistent coding, duplicate accounts, or other problems hiding inside its historical records. Moving that data into a new system doesn’t magically fix those problems. It can make them much more visible.

Brad’s team doesn’t hide that reality from clients. They explain what can go wrong and recommend the approach they believe will work best.

But sometimes the client wants what the client wants.

When Everyone Wants the History

In one particularly complicated project, the client wasn’t simply moving from QuickBooks Desktop to QuickBooks Online. They were also planning to implement a new CRM system as part of the process.

The projects were technically separate steps, but they were closely connected—and therefore created significantly more risk.

Brad’s team worked with a designated primary contact who helped map out the project, determine what would and wouldn’t be migrated, and discuss the risks.

There was just one problem.

The rest of the organization wasn’t necessarily hearing the same information.

The data being migrated was messy, and Brad’s team had warned the primary contact that importing it would create problems. But other members of the company weren’t part of those conversations. When they eventually encountered the messy data themselves, they assumed the migration team had caused the problem.

Suddenly, the experts who had warned everyone about the risk were being blamed for the consequences of that very risk.

The Telephone Game Is a Business Risk

Morgan points out that this is essentially the business version of the children’s game of telephone.

One person receives a complicated explanation. They pass it to another person. The details get simplified. The warnings disappear. Eventually, someone who never heard the original explanation is left wondering why nobody told them what was going to happen.

And sometimes, the information doesn’t get passed along accidentally.

Brad has encountered situations where internal teams didn’t want to spend money on training, so someone told the vendor that training wasn’t necessary. Later, when people struggled with the new system, it was easier to blame the vendor than admit that the organization had chosen not to pay for the help it needed.

That’s a particularly dangerous form of miscommunication because the person being blamed may have done exactly what they were asked to do.

Get the Right People in the Room

One of the biggest lessons Brad took from these experiences is that the “primary contact” isn’t necessarily the only person who matters.

If the owner is going to be furious when a project takes longer or costs more than expected, the owner needs to understand the risks.

If the CFO is going to have to work with the financial data afterward, the CFO needs to understand what is changing.

If the CPA is going to rely on those books at tax time, the CPA may need to be part of the conversation too.

Brad’s team has learned to ask a simple question: Who are the people who will be most upset if this goes wrong?

Those are the people who need to be involved before the project begins.

It’s not just about communicating more. It’s about communicating with the right people.

Sometimes the Best Client Service Is Saying No

Perhaps the most important lesson is also the hardest one for a service provider to follow.

When you’re the expert, it’s tempting to take the client’s money and do what they’ve asked—even when you’ve already told them that what they’re asking for is a bad idea.

But Brad has learned that there are situations where the right answer is simply no.

If a client insists on moving forward against your professional recommendation, you have to ask yourself whether taking the project is actually serving either party.

Because when the predictable disaster happens, the client may not remember that you warned them.

They may simply remember that you were the person who did the work.

Brad says his company has learned through experience that sometimes the better choice is to walk away rather than knowingly enter a project that is already headed in the wrong direction.

And Then There Are Chargebacks

The migration story wasn’t Brad’s only reminder of how vulnerable small businesses can be.

Later in the conversation, he discusses another particularly painful reality of client work: chargebacks.

Getting paid by credit card is wonderfully convenient for a small business. But if a client disputes the charge later, the money can be pulled directly from the company’s account while the business is given a limited window to prove that the transaction was legitimate.

That means the work may have been completed, the client may have been happy, and months may have passed—only for the business to suddenly have to reconstruct the entire relationship through documentation.

For a small company, that’s not just annoying. It’s expensive.

The lesson is the same one running through the entire episode: document everything.

Get agreements in writing. Clearly define what the client is purchasing. Make sure expectations are documented. And when the work is completed, get confirmation that the client approved it.

As Brad puts it, the more clearly you’ve documented what happened, the better positioned you are when someone later tries to tell a different version of the story.

The Perfect Storm Is Usually Made of Small Problems

The most frightening thing about Brad’s story isn’t that one enormous mistake happened.

It’s that there were so many smaller problems.

The data wasn’t clean.

The systems were different.

The migration was risky.

The CRM implementation added another layer of complexity.

The warnings weren’t communicated to everyone.

People who weren’t part of the original conversations blamed the vendor.

Training decisions weren’t necessarily communicated honestly.

And eventually, the people involved had to deal with the consequences of decisions that had been made much earlier.

That’s what makes a client horror story like this so useful.

Most disasters don’t begin with someone deliberately making a terrible decision. They begin with someone thinking, “It’ll probably be fine.”

And then another person does the same thing.

And another.

Until all the holes line up.

The result is what Brad describes as a perfect storm—and by the time everyone realizes what’s happening, it’s much harder to fix than it would have been to prevent it in the first place.