Sage Just Sunsetted BusinessVision: What You Need to Know (And Do) Before December 2026

Sage Just Sunsetted BusinessVision: What You Need to Know (And Do) Before December 2026

Sage has officially announced the BusinessVision end of life date: December 31, 2026. If you’re still running BV, you probably already knew the writing was on the wall. The software hasn’t had a meaningful update in over six years. Payroll tables get refreshed, sure. But actual features? Nothing. Now it’s official.

That deadline sounds like plenty of time. It’s not.

Now Sage has made it official. End of life: December 31, 2026.

That sounds like plenty of time. It’s not.

BusinessVision End of Life: Why 10 Months Isn’t as Long as You Think

Here’s what I’ve seen happen with end-of-life announcements:

  • Companies wait until month 11 to start looking
  • Then discover their data is messier than they thought
  • Then scramble to find a consultant who isn’t already booked
  • Then go live in January with half-trained staff and crossed fingers

You don’t want to be that company.

The real risk isn’t the deadline. It’s everything you don’t know about your own data until you try to move it.

The Data Questions You Need to Answer Now

Before you can migrate anywhere, you need to take an honest look at what you’re working with:

How clean is your customer list? Most companies have years of duplicate entries, outdated contacts, and customers who haven’t ordered since 2015. Do you want to pay to migrate all of that, or clean it up first?

How many inactive warehouses or locations are cluttering your setup? Legacy systems accumulate outdated baggage. Warehouses that closed five years ago. Departments that no longer exist. All of it adds complexity to a migration.

How much history do you actually need? You might have 15 years of transaction history. Do you need all of it in your new system, or can some of it live in an archive? The answer affects your timeline and cost.

What’s documented and what’s tribal knowledge? If the person who set up your BV system retired three years ago, there may be customizations and workarounds that nobody fully understands anymore.

These are questions you want to answer now, while you have options. Not in November, when you’re desperate.

What a Realistic Migration Timeline Looks Like

If you’re thinking “I’ll deal with this in the fall,” here’s what you’re actually signing up for:

Months 1-2: Discovery and cleanup. Assessing your current data, identifying what needs to be cleaned, archived, or restructured. This takes longer than anyone expects.

Months 2-3: System setup and configuration. Building out your new system to match your business processes. Chart of accounts, inventory locations, user permissions, integrations.

Month 4: Data migration and testing. Moving your data over, running parallel processes, catching the inevitable surprises.

Month 5: Training and go-live. Getting your team comfortable before you flip the switch.

Don’t forget your custom reports. Most BusinessVision users have reports that were built specifically for their business. Custom financial statements, inventory reports, sales analyses. Some of those needs may be covered by Spire’s built-in reporting. Others will need to be rebuilt to work with Spire’s data structure. Figuring out which is which, and getting those custom reports written before go-live, is a critical step that often gets overlooked until the last minute.

That’s five months if everything goes smoothly. And nothing ever goes completely smoothly.

If you want to be live on a new system before December 31, 2026, you should be starting conversations now, not in September.

Why Spire Is Worth a Look

I’ve migrated BusinessVision clients to Spire, and there’s a reason it’s a natural fit: Spire has roots in BusinessVision. The logic feels familiar. The learning curve is shorter than jumping to something completely different.

Spire has outlined their perspective on why BV users are making the switch, and it’s worth a read.

But here’s what I’ll add from the implementation side:

  • The transition is smoother than most. Your team isn’t learning a completely foreign system.
  • Modern features become available. Emailing invoices directly, EFT remittances, integrations with shipping and e-commerce platforms. Things that feel like luxuries on BV are standard on Spire.
  • You’re not alone. There are consultants (like me) who have done this migration before and know where the landmines are.

The Bottom Line on BusinessVision End of Life

Whatever path you choose, start the conversation now.

10 months goes fast when you’re also running a business. And the companies that start early get the best consultants, the smoothest timelines, and the least stressful go-lives.

The ones who wait? They get whatever’s left.

 

What Does ERP Implementation Really Cost? A Realistic Breakdown

What Does ERP Implementation Really Cost? A Realistic Breakdown

“How much is this going to cost?”

It’s the first question everyone asks about ERP implementation. And honestly? It’s the question most consultants dodge.

I’m not going to give you a price list. I can’t. ERP implementation cost depends entirely on your business. But I can tell you exactly how to think about it so you’re not blindsided.

The Rule of Thumb

When estimating ERP implementation costs for Spire Systems,  expect to budget 1 to 1.5 times your software cost for implementation services.

So if your software investment is $15,000, plan for $15,000 to $22,500 in implementation. If it’s $25,000, budget $25,000 to $37,500.

That’s a range, not a guarantee. Here’s what moves the needle.

The Factors That Drive ERP Implementation Cost

Data conversion complexity. This is the big one. I’ve had conversions take 2 hours. I’ve had others take 3 days. The difference? How clean the data is, how much history you’re bringing over, and whether there’s an existing conversion path from your old system.

Here’s my advice: don’t pay movers to haul your trash from the old house to the new one. Clean up your data before migration. Purge inactive customers, obsolete inventory, ancient open orders. You’ll pay less, and you’ll start fresh instead of importing 10 years of mess.

Form customization. Nobody wants their invoices to scream “I use the same software as everyone else.” But there’s a spectrum here. Must-haves like adding fields or removing ones you don’t need are reasonable. Spending hours matching the exact shading of your old invoices from 2008? Probably not worth it.

Training approach. Some clients want me to train their team on every module. Others prefer to explore the software, watch Spire’s YouTube videos, and call me when they get stuck. Both work. One costs more upfront, the other costs more over time. Your call.

Number of users. A single-user system costs less than a 15-user system. Pretty straightforward.

Hosting choice. You can install Spire on your own network or host it in Spire’s cloud. Cloud hosting means monthly fees but no server maintenance. On-premise means more control but you’re managing the infrastructure. Different cost structures, same software.

The Ongoing Costs People Forget

Software isn’t a one-time purchase. Plan for:

Software Assurance. This is your annual maintenance. It keeps you current on updates and new features. Industry standard, calculated as a percentage of current software pricing. So as Spire’s prices increase over time, your annual SA will too. It’s based on what your modules and user count would cost today, not what you originally paid. Spire’s SA is 20% of MSRP, which is the norm for the industry.

Tech support. Spire offers direct email support for an annual fee. Some clients love having that safety net. Others prefer to call me. Either way, budget something for when things go sideways.

How Long Does This Take?

Typical Spire implementations run 4 to 12 weeks from kickoff to go-live. The range depends on the same factors that drive cost: data complexity, how much customization you need, and how quickly your team can engage in training.

I’ll write more about timeline and what makes go-lives smooth (or rocky) in a future post.

The Cost Nobody Budgets For

Here’s what never shows up in a consultant’s quote: your team’s time.

Your staff still has to do their regular jobs while learning a new system. That’s training sessions, testing in the sandbox, building new habits, asking questions, making mistakes, and fixing them.

Some companies carve out dedicated time for implementation. Others expect their team to squeeze it in between everything else. The second group always has a rougher go-live.

You don’t pay me for that time. But it’s real, and it costs you something – either in overtime, in slower implementation, or in a team that’s not ready when the switch flips.

Budget for it. Even if it’s just blocking calendars and setting expectations.

A Note for Companies on Bigger Systems

Not everyone reading this is outgrowing QuickBooks. Some of you are on NetSuite, SAP Business One, or another enterprise system and wondering if you’re paying for more than you need.

If your annual maintenance and support fees feel out of proportion to what you’re actually using, you’re not alone. I work with companies who were sold a system built for a much larger operation. They’re paying enterprise prices for features they’ve never touched.

Right-sizing to Spire won’t make sense for everyone. But if you’re spending $30,000 or more a year on maintenance for software that’s overkill for your operation, it’s worth a conversation. Sometimes the best move isn’t upgrading. It’s simplifying.

So What’s the Real Number?

I can’t tell you. Not because I’m hiding anything, but because I genuinely don’t know until I understand:

  • What system are you coming from?
  • How clean is your data?
  • How many users need access?
  • What modules do you actually need?
  • How much hand-holding does your team want?

Two companies with the same revenue can have wildly different implementation costs based on these factors.

The Bottom Line

Whether you’re outgrowing QuickBooks or overpaying for an enterprise system you never fully needed, here’s how to think about budgeting:

For new implementations: Take your expected software cost. Multiply by 2 to 2.5 for your year-one total (software + implementation). Add 20-25% of software cost annually for ongoing maintenance and support.

For right-sizing: Compare what you’re paying now in annual maintenance and support against what a simpler system would cost to implement and maintain. Sometimes the migration pays for itself in two years.

That’s not a quote for ERP implementation cost. That’s a framework for planning.

When you’re ready to talk specifics, I’ll ask a lot of questions. The answers determine whether this is a $15,000 project or a $40,000 one.

And you deserve to know that before we start.

 

The First Recall is Not the Time to Learn You Need Lot Tracking

The First Recall is Not the Time to Learn You Need Lot Tracking

The Moment Everything Changes

It’s 4:00 PM on a Friday. You’re thinking about the weekend. Then your phone rings.

A supplier just flagged a contaminated batch. By Monday morning, you need a list of every customer who received product from Lot #882.

The FDA maintains a running list of pet food recalls and advisories, and the pattern is clear: companies that can’t trace fast enough face the worst outcomes.

Your first move? Opening three different Excel files. One’s on the shared drive. One’s on someone’s desktop. And one… you’re pretty sure exists, but you’ll need to call the warehouse manager to find it. He’s already left for the day.

In fact, this is the moment most companies discover their lot tracking is broken.

Recalls aren’t just logistical headaches. They create financial, reputational, and regulatory cascades that move fast and leave almost no room for error. Industry estimates put the average direct cost of a food recall at $10 million. And that’s just the direct costs — retrieval, disposal, notifications. It doesn’t include the lawsuits, the lost accounts, or the brand damage that lingers for years.

When traceability is weak, those costs climb even higher. Why? Because you end up recalling more product than necessary. You can’t isolate the problem, so you pull everything that might be affected. That’s expensive. And it’s avoidable.

If your first instinct during a recall is to start hunting through spreadsheets, you’ve already lost the critical early window of control.

What Regulators Actually Expect (And How Fast)

The rules have changed.

FSMA 204  (the FDA’s Food Traceability Final Rule ) requires companies to provide electronic, sortable traceability data within 24 hours of a request. That’s not a soft deadline. That’s not “get back to us when you can.” That’s 24 hours. Including weekends. If FDA calls at 5:00 PM Friday, you have until 5:00 PM Saturday.

Now, FSMA 204 specifically targets high-risk foods. But the expectation it sets ripples outward. Auditors, insurers, and major retailers are already using it as a benchmark for evaluating all food distributors. If you’re distributing pet food, you’re tracking ingredients from multiple suppliers, batches produced on different dates, and products shipped to retailers, vets, and direct-to-consumer channels. The complexity adds up fast.

The burden of proof is on you. When someone asks for traceability data, they expect verifiable, timestamped records that are immediately retrievable. Not “give us a few days to pull it together.” Not “we know where it is, we just need to find it.”

Good intentions don’t satisfy an auditor. Only verifiable, timestamped data does.

Why Spreadsheets Fail Under Recall Pressure

Spreadsheets are familiar. They’re flexible. Everyone knows how to use them.

They’re also fragile under stress.

Studies of operational spreadsheets consistently find that over 90% contain errors. Not complicated spreadsheets built by amateurs. Regular, everyday business spreadsheets. The kind your team uses right now.

In normal operations, a small error might not matter much. But during a recall, a single incorrect lot reference can mean over-recalling safe product or missing affected customers entirely. Both are expensive. One is dangerous.

Manual data entry. Someone types “Lot 882” instead of “Lot 822.” Nobody catches it. Six months later, that typo determines whether a customer gets notified or not.

Multiple versions. The warehouse has one file. Accounting has another. Sales exported their own copy three weeks ago and added some columns. Which one is the truth? Nobody’s entirely sure.

The linking problem. Connecting supplier lots to internal batches to outbound shipments requires hopping between files, cross-referencing dates, and hoping someone kept good notes. Under time pressure, this falls apart fast.

Spreadsheets are fine for storing data. They’re catastrophic for retrieving the right data under pressure.

 

The Hidden Risk of “We Can Figure It Out If It Happens”

I get it. Recalls feel rare. Theoretical. Something that happens to other companies.

So the plan becomes: “If it happens, we’ll figure it out.”

What matters isn’t likelihood. It’s impact.

A recall doesn’t just test your systems. It tests your leadership, your brand trust, and your operational maturity, all at once, under a deadline, with regulators and customers watching.

And if your traceability depends on one person who knows where the files are and how the process works? You don’t have a system. You have a single point of failure.

I’ve seen this pattern over and over. The warehouse manager who’s been there 15 years and “just knows” where everything is; the office manager who built the spreadsheet system and is the only one who understands the formulas; the IT person who retired two years ago and took all the workarounds with them.

These aren’t bad employees. They’re good employees in a bad structure. And when they’re on vacation, or sick, or gone, the whole thing stops.

For food distributors, this risk compounds quickly. You’re not just tracking finished goods. You’re tracking ingredients from multiple suppliers, production batches across different dates, and shipments going to retailers, foodservice, and maybe direct-to-consumer. Every handoff is a place where traceability can break. The question isn’t whether you’ll ever face a recall. It’s whether you’ll be ready when you do.

What Proper Lot Tracking Actually Looks Like

Effective lot tracking isn’t about better spreadsheets. It’s not about more reports or extra columns or color-coded tabs.

It’s about how work happens every day.

When lot tracking is built into your system properly, traceability isn’t a separate task. It’s just how things work.

Every receive is tied to a lot. When product comes in, you capture the lot number as part of receiving. Not written on a sticky note. Not added to a spreadsheet later. It’s in the system before the product hits the shelf.

Every pick is tied to a lot. When an order ships, the system knows exactly which lots went out the door. Not “probably from that pallet we got last week.” Exactly which lots.

Every transaction is linked.  Supplier lot → internal batch → customer shipment. You can query the unbroken chain. When someone asks “who got Lot 882?” the answer takes minutes, not days.

The difference shows up during a mock recall. Industry best practice is completing a traceability exercise, identifying all affected customers and products, in 2-4 hours. Major retailers like Chewy expect even faster. If your mock recall takes three days of digging through files and calling the warehouse, that’s not a drill. That’s a warning.

The goal isn’t recording information after the fact. It’s systems that enforce traceability as work gets done.

Why This Is a System Decision, Not a Process Fix

You can’t train your way out of structural gaps.

I’ve seen companies try. They create checklists. They add steps. They tell the warehouse team to “be more careful” about writing down lot numbers. They hold meetings about the importance of data accuracy.

And for a few weeks, it works. Then someone gets busy. A step gets skipped. The checklist gets ignored because there’s a truck waiting. And you’re right back where you started.

The problem is rarely the software itself. It’s the workflows built around it. I dig into this more in Stop Blaming the System: The Messy Truth About Bad Workflows.

It’s not the people either. It’s that manual systems depend on perfect human behavior, every time, under pressure. That’s not realistic. Well-designed systems act as gatekeepers. If the lot number is missing, the receive can’t be completed. If the pick isn’t tied to a lot, the shipment can’t go out. The system doesn’t allow the gap to exist in the first place.

This is the difference between “we have a process” and “we have a system.”

Processes depend on people remembering. Systems enforce the rules automatically.

The manual approach scales by adding people: more checkers, more oversight, more meetings about why things fell through the cracks.

Automation scales by adding consistency. The hundredth transaction is tracked exactly like the first.

When a recall hits, you don’t want to be hoping everyone followed the process. You want to know the system made it impossible not to.

The Cost of Waiting Is Usually Invisible Until It Isn’t

Of course, delaying traceability improvements often feels reasonable. The system works. Nobody’s complained lately. There are bigger fires to fight.

But then something shifts, and suddenly the cost becomes very visible.

Retailer audits.  Major retailers and chains like Chewy, Petco, and large grocery buyers increasingly audit supplier traceability before signing or renewing contracts. Excel-based processes raise red flags. That doesn’t mean an automatic rejection, but it does mean harder conversations, more scrutiny, and sometimes lost opportunities you never even hear about.

Insurance Scrutiny.  Product recall and liability insurers factor traceability controls into their assessments. Weak documentation can mean higher premiums or, in some cases, difficulty getting coverage at all.

The question you can’t answer fast enough. There are few harder moments than telling a regulator or a major customer that the data exists, you just need more time to find it. That’s not a confidence-building statement.

The costs of waiting don’t show up on a balance sheet. They show up in the account you didn’t win, the audit that went sideways, and the scramble that could have been avoided.

A Better Time to Learn This Lesson

The best time to evaluate your traceability readiness is when:

  • No recall is active.
  • No deadline is ticking.
  • No one is watching.

Run a mock recall. Pick a random ingredient lot from three to six months ago. See how long it takes to trace it forward to finished products and outward to customers. Document where you got stuck, what took longest, and what required a phone call instead of a report.

If you can do it in under four hours with confidence in the data, then you’re in good shape. If it takes days, or depends on one person who “knows where everything is,” that’s your answer.

The worst time to learn your lot tracking is broken is during your first real recall.

But What About the Cost of Upgrading?

Fair question.

Implementing proper lot tracking typically costs $15,000 to $30,000 in year one, depending on the complexity of your operation and how much cleanup is needed.

That feels substantial until you compare it to the alternatives:

The average food recall costs $10 million or more in direct expenses alone.

Over-recalling even one week’s worth of product because you couldn’t isolate the affected lots can exceed your entire implementation cost.

Retailer and insurance requirements increasingly treat traceability as table stakes, not a nice-to-have.

The real question isn’t whether you can afford to upgrade. It’s whether you can afford the risk of not upgrading.

Let’s Talk About Your Recall Readiness

Are you compliant on paper, or actually ready to respond within 24 hours?

If you’re not sure, let’s walk through your current workflows and see where manual processes might be creating hidden risk. No pressure, no pitch. Just an honest look at where you stand.

 

36 Years of ERP: What Hasn’t Changed (And What I Never Saw Coming)

36 Years of ERP: What Hasn’t Changed (And What I Never Saw Coming)

March 21, 1989. That’s when it started.

My first client was a small company running everything on paper. Actual ledger books. Handwritten entries. The kind of bookkeeping that required good penmanship and a sharp pencil.

We were moving them to BPI.  A DOS-based accounting system from ACCPAC. No mouse. No Windows. Just a blinking cursor and a lot of keystrokes.

The office manager was a one-person operation. She handled the books, answered the phones, dealt with vendors, kept the whole place running. And now she had to learn an entirely new way of doing her job.  While still doing her job.

After our training sessions, she’d meditate. Not as a wellness trend. Because she was overwhelmed.

I don’t blame her. She was learning something completely foreign while her bosses wouldn’t even pick up the phone during our sessions. Every interruption meant backtracking. Every phone call meant losing her train of thought.

So I said something.

I pointed out that every interruption extended the training … and extended my invoice. Suddenly, the bosses found time to answer their own phones.

That was my first lesson in ERP consulting: the software is the easy part. The people are the hard part.

What’s Changed: Everything

Back then, there was no way to import data from paper ledgers. Clients typed in every customer, every vendor, every open invoice.  One by one. From handwritten records. Into a system they barely understood.

Now? We have migration tools. We export from the legacy system, clean up the data, and import it into the new one. What used to take weeks of manual entry now takes days of careful mapping and validation.

The technology has changed beyond recognition:

  • DOS → Windows → Cloud. I’ve migrated clients through every era.
  • Fax orders → EDI → E-commerce integrations. I’ve watched order entry go from paper to fully automated.
  • Stand-alone PCs → Networked servers → Hosted systems. I’ve helped clients stop worrying about their server closet.
  • Manual reports → Real-time dashboards. I’ve seen CFOs go from waiting days for financials to pulling them up on their phones.

I’ve moved clients off systems you’ve probably never heard of … DacEasy, BPI, Peachtree DOS, ACCPAC DOS … and onto modern platforms that would’ve seemed like science fiction in 1989.

What Hasn’t Changed: GIGO

Garbage In, Garbage Out.

It was true in 1989. It’s true today.

You can have the best software on the market. The slickest interface. The most powerful reporting engine. But if your data is messy, incomplete, or outdated, your new system will be just as useless as the old one.

Before every migration, I tell clients the same thing: we need to clean house first.

  • Customers who haven’t ordered in five years? Archive them.
  • Vendors you haven’t used since 2018? Don’t bring them over.
  • Items with descriptions like “MISC PRODUCT DO NOT USE”? Delete them.
  • Open invoices from a decade ago that will never be collected? Write them off.

The new system isn’t a fresh start if you’re dragging all your old messes into it.

This is the conversation nobody wants to have. Cleaning data is tedious. It forces decisions that have been deferred for years. But it’s the difference between a system that works and a system that everyone hates.

What I Never Saw Coming

In 1989, I couldn’t have predicted:

  • That I’d still be doing this 36 years later. And still learning.
  • That some clients would stay with me for decades. I have clients I’ve migrated through three, four, even five systems over the years.
  • That the human challenges would stay exactly the same. People still resist change. Still fear new systems. Still need someone to advocate for them during training.
  • That “the cloud” would mean something other than weather.

But here’s what surprises me most: companies are still running on systems that should’ve been retired years ago.

I just finished a migration from DacEasy. A system that hasn’t been updated in over a decade. The company was holding it together with workarounds and prayers, terrified that one Windows update would bring everything down.

They didn’t know what they were missing. They thought manually emailing invoices one at a time was just how it worked.

It’s not.

What 36 Years Taught Me

  1. The software is never the whole story. Training, buy-in, clean data, and realistic expectations matter more than features.
  2. Advocate for the person doing the work. That office manager in 1989 taught me that. If leadership doesn’t protect training time, the implementation will struggle.
  3. Don’t automate a broken process. If your workflow is a mess on paper, it’ll be a mess in software. Fix the process first.
  4. “Good enough” has a shelf life. Every system that’s “working fine” today will eventually hit a wall. The question is whether you’ll migrate on your timeline or the system’s.
  5. Trust is everything. Clients don’t stay for 30 years because of software. They stay because they trust you to tell them the truth…  even when it’s not what they want to hear.

The Work Hasn’t Changed

The tools are better. The interfaces are prettier. The integrations are more powerful.

But the core work is the same as it was on March 21, 1989:

  • Understand how the business actually runs, not how the org chart says it should.
  • Clean up the data before it poisons the new system.
  • Train the people, not just the software.
  • Be the person who answers the hard questions honestly.

If you’re running a system that’s held together with workarounds, or you’re drowning in spreadsheets because your software can’t keep up, that’s the work I do.

I’ve been doing it for 36 years. And I’m not done yet.

 

How to Talk to Your Team About Software changes Without the Eye Rolls

How to Talk to Your Team About Software changes Without the Eye Rolls

I once got a call from a client whose warehouse manager pulled them aside and said, “If we’re switching systems, I’m out.” This was their best person. Someone who’d been there 15 years. Someone who knew every SKU, every quirk of the operation, every workaround that kept things running.

They hadn’t even picked the software yet.

Here’s what I’ve learned after years of helping companies through ERP implementations: the technology is actually the easy part. It’s the people part that makes or breaks it.

The Real Problem Nobody Wants to Say Out Loud

Your team isn’t being difficult. They’re scared.

Scared they’ll look stupid learning something new. Scared their hard-won expertise won’t matter anymore. Scared about whether their job still exists in six months. Scared that management is going to make their lives harder and call it progress.

And honestly? They’ve probably earned that fear. Because how many times have they been told “this will make things easier,” only to spend the next three months cleaning up the mess?

Start the Conversation Before You Mention Software

I tell every client the same thing: don’t lead with the solution. Lead with the problem.

Sit down with your team and ask: what’s driving you crazy right now? What takes way longer than it should? What keeps you here late? What makes you want to throw your keyboard across the room?

Let them tell you what’s broken. Let them complain. Write it all down.

Because here’s what happens: when you eventually say, “I think we need better software,” they’ll remember that you asked first. That you listened. That you’re trying to solve their problems, not create new ones.

Make Them Part of the Decision

You know what kills buy-in faster than anything? When people find out you already signed the contract, they just have to deal with it.

I’ve seen this work best when key users are involved in demos from the start. Let your warehouse lead ask the hard questions about receiving workflows. Let your customer service person poke holes in the order entry process. Let your inventory manager grill the vendor about lot tracking.

Two things happen when you do this: First, you catch problems before you’re locked in. Second, your team starts to feel ownership. It stops being “management’s new system” and starts being “our new system.”

Say the Scary Stuff Out Loud

Don’t dance around it. Your team is already thinking about the hard questions. In my experience, addressing them directly builds trust faster than anything else.

“Will my job go away?” Be honest. If roles are changing, say so. If you’re eliminating manual data entry but need those people doing quality control instead, tell them that. If someone’s job really is at risk, they deserve to know sooner rather than later.

“I’m terrible with computers.” I hear this all the time, and it’s legitimate. Acknowledge that learning new systems is hard. Talk about training. Talk about support. Talk about expecting a messy few months, and that’s okay.

“We’re going to lose everything we’ve built.” This is where I remind people that data migration is part of the process. And more importantly, their knowledge of how things actually work is precisely what you need to set up the new system right.

Turn Skeptics Into Champions

Every team has early adopters and skeptics. You need both.

Your early adopters will figure out the workarounds and help everyone else. I always tell clients to empower these people. Give them extra training. Let them be the heroes.

Your skeptics will find every problem before it becomes a disaster. Listen to them. When they say “but what about when we have to do X,” that’s not resistance, that’s expertise. Write it down. Make sure the new system can handle it.

What to Actually Say

I’ve watched a lot of these conversations go sideways. Here’s what I’ve seen work better:

Instead of: “This new system is going to be so much better.” Try: “I know change is hard. This is going to be messy for a while. But here’s why I think it’s worth it.”

Instead of: “You’ll love it once you get used to it.” Try: “I need your help making sure this actually works for how we operate. You know this business better than any software vendor does.”

Instead of: “We have to do this, corporate decided.” Try: “Here’s what’s breaking. Here’s what we’re trying to fix. What am I missing?”

The Truth About Implementation

The best software in the world fails if your people aren’t on board.

I’ve seen implementations with perfect technical execution fall apart because nobody thought about the people side. And I’ve seen messy, imperfect rollouts succeed because the team was invested from day one.

Implementation success isn’t about hitting your go-live date. It’s about whether your team is still there six months later, actually using the system, and not secretly running everything through spreadsheets when you’re not looking.

Technology doesn’t run your business. People do. Treat them like it.