When Your ERP Is Too Big for Your Business

When Your ERP Is Too Big for Your Business

I work with mid-sized distributors and manufacturers. Most of my clients come to me because they’ve hit the ceiling on older systems. DOS-based software. Legacy platforms that served them well for years but can’t keep up anymore. I’ve helped companies move off systems like ACCPAC Plus, Dac Easy, and Business Vision onto modern platforms like Spire or Adagio.

But there’s another group I keep hearing about. Companies stuck on the other end of the spectrum.

They made a big ERP investment a few years back. Enterprise-grade software. The kind of system you see in case studies and trade show booths. On paper, it should be running the whole business.

But when you look at how things actually work day to day, the answer is almost always the same: spreadsheets.

Inventory tracking in Excel. Pricing overrides in a shared file someone built years ago. Commission calculations that live outside the system because “it was easier.” A report called something like “REAL margins” that someone updates manually every week because the ERP version never quite matched reality.

The system isn’t broken. It’s just not being used. Not the way it was sold, anyway.

I haven’t worked with many of these companies yet. But I know this pattern is real. I see it in industry forums, in user reviews, in the questions people ask when they’re quietly wondering if they made the wrong choice. And I know I can help.

That’s what I want to talk about today.

Signs the fit isn’t right

So what does “too big” actually look like in practice? It’s rarely obvious. The system works. Invoices go out. Orders get processed. But underneath, there are signs that the fit isn’t right.

Simple changes become projects.
You want to add a field. Tweak a report. Change how a workflow triggers. In a right-sized system, that’s a Tuesday afternoon. In an oversized ERP, it’s a ticket to IT or a consultant, and it takes weeks. One user on a review site described waiting months for basic changes, only to be told it would require “custom development” at additional cost.

You’re paying for modules nobody opens.
Look at your invoice. Count the modules. Now ask your team which ones they actually use. I’ve seen companies paying for advanced forecasting, project management, multi-entity consolidation. Features that sounded great in the demo but never got configured. The invoice stays the same. The value doesn’t.

Reporting is powerful on paper.
The system has dashboards. It has saved searches. It has drill-down capabilities. But when month-end comes, someone still pulls the data into Excel. Why? Because it’s faster. Because the built-in reports don’t quite match how the business actually works. Because nobody wants to wait for a “saved search that takes minutes to load,” as one frustrated user put it.

The warehouse and customer service teams work around it.
They’re not trying to be difficult. They just need to get things done. So they track orders in a shared spreadsheet. They email updates instead of logging them. They keep a side system for the stuff that’s “just easier” outside the ERP. The system becomes a system of record that nobody fully trusts.

Everyone’s afraid of breaking something.
This is the quiet one. The system feels rigid. Complex. Like it was built for a company with a dedicated IT team and a full-time administrator. People don’t experiment. They don’t customize. They just work around it. Because touching anything feels risky.

None of this means the system is bad. These are powerful platforms. But power without fit creates friction. And friction shows up in spreadsheets, workarounds, and teams that quietly stop trusting the system they’re paying for.

How companies end up here

Nobody sets out to buy the wrong system. These decisions make sense at the time. It’s only later, when the dust settles, that the mismatch becomes clear.

Buying for a future that never arrived.
The company was growing fast. New locations were on the horizon. Maybe a second warehouse, maybe expansion into new markets. The system was chosen to handle all of that. But the growth slowed, or shifted direction, or just took longer than expected. Now the company is paying for infrastructure built for a version of itself that doesn’t exist yet.

Following someone else’s template.
A parent company said “we use System X everywhere.” A PE firm required it as part of the acquisition. A trusted advisor recommended it because it worked well for a much larger client. The system got chosen based on someone else’s needs, not the actual complexity of the business.

Getting sold on demos and dashboards.
The sales presentation was impressive. Real-time visibility. Powerful analytics. Seamless workflows. But demos show what’s possible, not what’s practical. The day-to-day reality of how the warehouse actually operates, how customer service handles exceptions, how the finance team closes the books… that’s harder to see in a 90-minute demo.

Underestimating what it takes to run a big system well.
Large ERPs aren’t just software. They’re ecosystems. They need administrators, ongoing configuration, someone who understands the logic well enough to troubleshoot when things break. Mid-sized companies often don’t have that internal capacity. So the system gets implemented, the consultants leave, and the team is left managing something they were never staffed to own.

Here’s the thing: large, complex ERPs aren’t automatically wrong. They’re built for companies that need that level of power and have the resources to manage it. The problem isn’t the software. It’s the fit. And when the fit is off, even a great system becomes a burden.

What “right-sized ERP” looks like in practice

So if oversized is the problem, what does right-sized actually look like?

It’s not about finding the smallest system. It’s about finding the one that fits how your business actually runs today, with room to grow into tomorrow.

The system doesn’t fight you on everyday tasks.
Your team can navigate it without fear. Basic operations don’t require workarounds or side systems. The people using it daily feel like they’re working with the software, not around it.

Inventory, orders, and financials live in one place.
Not scattered across three platforms and five spreadsheets. When someone asks “what’s our margin on this order?” or “how much of this SKU is in the warehouse?”, the answer is in the system. Not in a file someone updates manually every Monday.

Reporting works the way your business works.
This is where the right setup matters. A right-sized system gives you options: built-in reports for the basics, custom reports for the stuff that’s specific to your operation, and tools that connect your ERP data to Excel or dashboards without hours of monthly formatting.

I set clients up with reporting that actually fits. Sometimes that’s custom Crystal Reports inside the ERP. Sometimes it’s Breeze GL, an add-on that pulls accounting data directly into Excel. You design the report once, and after that, printing next month’s version is just a matter of changing the date. Same idea with Power BI dashboards. Slicers, filters, the ability to look at data however you want, whenever you want.

The goal isn’t to make you dependent on a consultant for every month-end. It’s to build the reporting foundation right from the start, so the system gives you what you need without constant manual effort. And when something changes, like a new product line or a shift in how you want to see the numbers, that’s when you call me.

The system can grow with you.
A right-sized ERP handles where you are now and where you’re realistically headed in the next five to ten years. It doesn’t feel like it was built for a 500-person enterprise. But it also won’t hit a ceiling the moment you add a second location or a new product line.

This is the space I work in. Tools that sit in that middle ground: more control than entry-level software, less complexity than the big enterprise names. Platforms like Spire, where a mid-sized distributor or manufacturer can run their whole operation, with reporting set up to actually serve the business, not just check a box.

Right-sized doesn’t mean less capable. It means capability that matches reality, with room to evolve when you need it.

How we help clients figure out if their ERP is oversize or just mis-configured

Not every frustration means you need a new system. Sometimes the problem is the software. Sometimes it’s the setup. Part of my job is helping companies figure out which one they’re dealing with.

When I talk to a prospect in this situation, I’m not starting with “here’s what you should buy.” I’m starting with questions.

How many locations, and who’s actually in the system every day?
Not headcount on the org chart. Real users. The people logging in, entering orders, checking inventory, running reports. That tells me whether the system’s complexity matches the operation’s actual size.

How much of the business is still running in spreadsheets or side systems?
If the ERP is supposed to handle inventory but the warehouse manager keeps a separate Excel file “just to be safe,” that’s a sign. Either the system isn’t set up right, or it’s not the right fit. Both are worth understanding.

Which reports do you rely on, and how hard are they to get?
If month-end means exporting data and rebuilding reports manually every time, that’s friction. But is it because the system can’t do it, or because nobody ever configured it properly? Sometimes the reporting tools are there. They just need to be set up.

Are you using a small fraction of what you’re paying for?
Modules you’ve never opened. Features that sounded great in the demo but never got implemented. If half the invoice is for stuff you don’t touch, that’s worth examining. It might mean you’re on the wrong system. Or it might mean there’s value sitting untapped.

Are you paying enterprise fees for a mid-market operation?
This one catches people off guard. A company doing $5M or $15M in revenue shouldn’t be paying six figures a year in software assurance or maintenance fees. But it happens. Companies sign up for a big-name system, and the annual cost to keep it running, supported, and updated is wildly out of proportion to the business size. That’s not a configuration problem. That’s a fit problem. And it’s worth knowing what you’re actually spending compared to what right-sized alternatives would cost.

Here’s the honest answer I give sometimes: you might not need to switch. If the core system is sound and the pain is really about configuration, training, or reporting, fixing those things is faster and cheaper than starting over. I’d rather help someone get more out of what they have than sell them something new they don’t need.

But if the system truly doesn’t fit, if the complexity is baked in and the business has to bend itself around the software instead of the other way around, or if you’re paying enterprise prices for mid-market needs, then it’s worth looking at what else is out there.

The goal of that first conversation is to figure out which situation you’re in.

Where to start

If any of this sounds familiar, you’re not alone. And you’re not stuck.

Maybe you’re paying enterprise-level fees and still feel like your team is fighting the system. Maybe you’re wondering if the problem is the software or just how it was set up. Maybe you’ve been quietly Googling alternatives but aren’t sure where to start.

That’s exactly the kind of conversation I have with companies all the time.

We can spend 45 minutes walking through what you’re using and what you’re not. Looking at where the friction is. Figuring out whether you need a different system or a better way of using the one you have. Just an honest look at where things stand.

If you’re starting to explore options, I wrote about the questions worth asking before you commit to any ERP vendor]. It covers implementation timelines, true cost of ownership, and the things most salespeople won’t bring up. Worth a read before you start shopping.

When you’re ready to talk, reach out. I’d be glad to help you figure out what right-sized actually looks like for your business.

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you’re evaluating your options, we can book a free 15-minute call

7 Questions to Ask Before Choosing Your Next ERP

7 Questions to Ask Before Choosing Your Next ERP

When you’ve outgrown QuickBooks, every ERP vendor promises to be your perfect next step. But most of them aren’t actually built for mid-market companies like yours. Here’s how to tell if a system is truly right-sized for your business.

The Questions That Matter

After years of helping companies move from legacy systems to modern ERPs, I’ve learned which questions actually predict success. Not the ones vendors want you to ask. The ones that reveal whether you’ll still be happy with this choice three years from now.

What to Ask

“Can you show me how to add a custom field to an order?”
Custom fields and custom reports are part of what I do. But a simple field shouldn’t take weeks or cost a fortune.

“What happens when we need a report that doesn’t exist yet?”
Custom reports are part of any good implementation. They get scoped and quoted as part of the project. The question is whether the system makes that reasonable or whether every new report becomes a major expense.

“How many of your clients our size use all the modules we’re buying?”
Nobody admits they’re only using 30% of what they bought. But most are.

“What’s the real monthly cost including hosting, support, and the add-ons we’ll actually need?”
The quote is never the real number. Budget for 40% more. And if you’re getting a steep discount for years one and two, ask what the price looks like in year three. That’s the number you’ll be living with.

“Can my warehouse manager learn this in a week?”
If the answer involves “comprehensive training programs,” your people will be in Excel within a month.

“When something breaks at month-end, who do I call and how fast will they answer?”
Support matters more than features. Bad support ruins good software.

“Which of these features do you think we won’t use?”
An honest vendor will tell you. A salesperson will insist you need everything.

The Bottom Line

The right next step should feel like relief, not a bigger version of the problem you already have.

These questions have saved my clients from expensive mistakes. Use them.

Need help figuring out if your current system is right-sized, or what to look for next? Let’s talk. A 45-minute conversation can save you years of frustration.

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you’re evaluating your options, we can book a free 15-minute call

Red Flags Your System Is Costing You More Than You Think

Red Flags Your System Is Costing You More Than You Think

.A few months ago, I was working with a client and noticed something odd. Their AR person was out on leave, and the person filling in was creating invoices in Microsoft Word.

Not exporting from the system. Creating them from scratch. In Word.

She’d type up the invoice, email it to the customer, then manually key the details into the AR module afterward. When I asked why, she shrugged. “I wasn’t really trained on the invoicing side. This was easier.”

The system had a perfectly functional invoicing module. But she didn’t know it well enough to trust it, so she built her own process. Two steps instead of one. Double the effort. No one flagged it because the invoices still went out.

That’s the thing about systems that “still work.” Orders get processed. Invoices go out. Month-end happens eventually. Nobody’s in crisis.

But somewhere in the operation, a warehouse manager has a spreadsheet open next to the ERP. A CSR is calling the warehouse to answer a question a customer asked ten minutes ago. Finance is running a month-end close that takes nine days.

The system isn’t broken. It’s just not doing the job anymore.

This post isn’t about whether your software is technically functional. It’s about the hidden system costs. Whether it’s quietly costing you money, time, and people, and whether those costs have just become normal. I’ve talked about this before. It’s a pattern I keep seeing.

The Workaround Problem

The most common pattern we see: the system technically works because the people around it have figured out how to compensate for what it can’t do.

  • Finance opens QuickBooks plus ten to fifteen spreadsheets every morning just to have a usable picture of the business
  • The warehouse manager keeps a parallel inventory sheet because the system numbers can’t be trusted in real time
  • Customer service reps maintain their own tracking files because the ERP doesn’t show them what they need
  • Purchasing exports to Excel every morning to calculate reorder needs because the system’s forecasting isn’t reliable

The organizational tell is when the workarounds get names. “The Tuesday export.” “Karen’s spreadsheet.” “The master pricing file.” When informal processes become standard operating procedure with their own nicknames, the workaround is the system.

Here’s a story that still gets me.

I’ve worked with one client for decades. Took them from paper records to DOS accounting to their current system. Over the years, I trained a lot of their staff. But one director preferred to keep things close to the vest. She didn’t like to let on when she didn’t know something.

When she retired, she trained her replacement on what she knew. Which didn’t include the system’s financial reporting capabilities. He trained his replacement the same way. For nine years, quarterly financial reports were built by exporting data and manually creating spreadsheets. Ten to fifteen hours a quarter, minimum.

The cycle broke when a new director insisted I train her staff from scratch. During that training, I asked who handled the financial reports. Her second-in-command said the director did, manually, every quarter.

They didn’t even know to ask if the system could do it.

Turned out it could. The whole time. Nine years of manual work, not because the system couldn’t handle it, but because the knowledge never got passed down.

The question we ask when we first talk to a company: when a new employee asks “why do we do it this way,” what’s the honest answer?

What “Reports Take Too Long” Actually Means

A month-end close that takes five to ten days is common in distribution companies running legacy systems. Finance works late. “Close week” becomes a department-wide emergency. Data gets pulled from multiple places, exported to Excel, reconciled manually, and even after all that, the numbers aren’t fully trusted.

I’ve seen companies get this down to three or four days with the right systems. The gap between a spreadsheet-heavy manual process and a system where the data is clean and centralized can be that stark.

The same problem shows up in smaller ways every day. A CFO who can’t answer “what’s our margin by product line?” without a half-day of pulling. A warehouse manager who spends two hours every morning generating pick lists manually. That’s over five hundred hours a year on a single preventable task. An owner who gets the question “what’s in stock at the other location?” and has to make a phone call to find out.

When reporting is a project rather than a conversation, decisions either slow down or get made without the data.

The Roles That Notice First

Different people in a distribution company feel the limits of the system differently.

The warehouse manager usually notices first. The inventory discrepancies. The time spent on manual counts. The gap between what the system shows and what’s actually on the shelf. They stop trusting the numbers.

The controller or CFO notices it at month-end. They can pull accurate top-line numbers, but a margin breakdown by product line, a customer profitability report, an inventory valuation by location, those require a process, not a click.

The owner is often last. They see it when growth stalls, when headcount keeps increasing without a revenue bump, or when a customer complaint escalates past the ops team for the first time.

The one we don’t talk about enough: customer service. A CSR who can’t answer “when does my order ship?” without calling the warehouse is doing two jobs, one of which the system should do for them. High turnover in that role is often a systems symptom dressed up as a hiring problem. According to SHRM (Society for Human Resource Management), replacing a single employee typically costs between 50% to 200%  of their annual salary.

There’s another pattern I see, mostly with manufacturers. The accounting system handles the P&L, tracks customers, maybe even sales commissions. But the heavy lifting, inventory, production costs, profit by order, lives somewhere else. A separate inventory package. Spreadsheets. The order entry handles the sale. Payables tracks the supplier bills. Payroll tracks labor. But none of it connects at the order level.

Big picture, yes, everything makes it to the ledger eventually. Micro picture? That’s where the spreadsheets live. And that’s where the reconciling happens, quietly, in the background, by whoever drew the short straw.

What It’s Actually Costing

This is the section that tends to surprise people, because the current system feels free. It’s paid for. The staff knows it. No invoice arrives every month that says “cost of workarounds.”

But the costs are real. Here’s how we’d run the numbers for a typical client.

A distributor with $1M in inventory carrying 15 percent excess stock due to poor visibility has $150,000 in capital sitting idle, not generating returns, accumulating holding costs. For a $10M distributor, inventory errors alone, stockouts, overstock, emergency orders, and expedited shipping, can run $100,000 to $300,000 annually.

Manual workarounds have a payroll cost, too. Thirty minutes per person per day across a 15-person team is roughly 1,950 hours a year. At a loaded cost of $40 per hour, that’s $78,000 annually in labor performing tasks a modern system automates.

And then there are the harder-to-quantify costs: the customer you couldn’t promise accurate stock to because you didn’t trust the inventory numbers. The supplier quote you couldn’t pull without making them wait. The contract you hesitated to take because you weren’t sure the systems could handle the volume.

These hidden system costs don’t send an invoice. But they’re billing you anyway.

The Objection We Hear Most

The most common reason companies stay: “We’re not ready.”

There’s always a reason. Q4 is coming. A new hire is starting. It’ll be calmer next year.

It’s rarely calmer next year. Distribution is operationally intense by design. The companies that wait for a clean window are often still waiting, while the cost of the current system keeps compounding quietly.

The other common one: “It still works.” And that’s true in the narrowest sense. Orders get processed. Invoices go out. But “still works” and “working well” are different things. When the system works only because the people around it have built a workaround infrastructure to compensate for what it can’t do, the real question is: how long do you want to maintain that?

And then there’s the honest one: “We can’t spend the money right now.”

Cash flow is real. I have a client right now who knows their system needs to change, but they’re in a crunch. That’s not an excuse, it’s a constraint. I’m not here to tell anyone to spend money they don’t have. But if cash flow is the barrier, it’s worth exploring rent-to-own options. It’s slightly more expensive at the end of the day, but it lets you delay the large purchase until the cash is there.

Seasonality is real too. If your business has a quiet stretch, that’s a natural window for go-live. A good implementation plan can work around your calendar, not against it.

If several of these hidden system costs sound familiar, it might be worth a conversation.

Not a sales call. A practical look at what’s actually happening in your operation and whether a change makes sense. That’s what I do.

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you’re evaluating your options, we can book a free 15-minute call 

What a Good ERP Go-Live Day Actually Looks Like

What a Good ERP Go-Live Day Actually Looks Like

Most companies imagine  ERP go-live day as a stressful, all-hands scramble. Systems crashing. Panic in the conference room. Late nights and everyone bracing for impact.

It makes for a good story. It’s also a sign that something went wrong long before launch day.

A good ERP go-live day should feel calm. Not boring. But controlled. Yes, there’s always a little last-minute energy. It’s like moving day: no matter how prepared you are, you’re still packing a few boxes the morning the truck arrives. But the big decisions are made. The system is tested. You’re not solving problems. You’re executing a plan.

You check the boxes, run the first real transactions, confirm the numbers tie out, and go home at a reasonable hour.

If that sounds anticlimactic, good. That’s the goal.

The difference between a chaotic go-live and a calm one isn’t luck. It’s what happens in the weeks before anyone flips the switch.

 

What Has Already Happened Before ERP Go-Live

 By the time go-live day arrives, most of the real work is already done. That’s the point.

Here’s what should be complete before anyone enters a live transaction:

Test conversion completed.
Your data has already been moved into a test environment at least once. This is where you catch the surprises: duplicate records, missing fields, formatting issues. Better to find them here than in production.

Sandbox validated.
Someone has actually clicked through the system. Created a test order. Run a report. This isn’t a demo; it’s a dress rehearsal. And it needs to include the people who’ll use the system daily, not just leadership. I’ve seen go-lives where the owner and accountant tested everything thoroughly, but staff never touched it until day one. They were fine because leadership knew the product well enough to answer questions on the fly. But that’s not a plan. That’s luck.

Workflow questions resolved.
How will you handle returns? Who approves purchase orders? Where does this report live? These conversations are boring. They’re also the ones that stall a go-live when they happen too late.

 Custom forms finalized.
Invoices, packing slips, purchase orders. Anything client-facing should already match your branding and include the fields you need. You don’t want to discover a missing column the first time you send a real invoice.

User permissions configured.
Everyone has access to what they need and nothing they don’t. This sounds simple until you realize someone can’t post a payment and the owner is out of the office.

Training done in the real environment.
Not slides. Not a video from the software company. Hands-on time in the system they’ll actually use, with their actual data. By go-live, the basics shouldn’t feel new.

 If any of this sounds like a lot, it is. But it’s the kind of work that happens over weeks, in manageable pieces. Go-live day is just the moment all that preparation becomes official.

 

What Actually Happens on a Well-Run ERP Go-Live Day

Go-live day has a rhythm. If the preparation was done right, it feels methodical, not frantic.

Here’s what happens, step by step:

Final data backup.
One last snapshot of the old system before anything changes. If something goes sideways, this is your safety net.

Controlled cut-off from the legacy system.
The client finishes entering their last transactions in the old system. After this point, the old system is for lookup only. No new orders, no new invoices, no new payments. The books are closed.

Data conversion or import.
This is where the data moves. If there’s a conversion tool, I run the conversion. If not, we import from the spreadsheets the client has already cleaned up. Either way, the data lands in the live system.

Data integrity checks.
Now we verify. Did everything come through? Are there obvious errors, missing records, or duplicates? This is a quick scan before we get into the detailed comparisons.

Balance comparisons.
We run reports in both systems and compare:

  • Vendor balances (AP)
  • Customer balances (AR)
  • Inventory valuation
  • General ledger balances

Old system to new system. Line by line. If something doesn’t match, we stop and figure out why before moving forward.

 

What We Confirm Before Going Live

 Before we move to live transactions, three things must be true:

  1. Financial totals tie out.
    The core balances in the new system match what we expect from the old system. No unexplained differences. No “we’ll figure that out later.”
  2. Inventory makes sense.
    Counts and valuations are directionally right. Nothing is missing, duplicated, or valued at zero when it shouldn’t be.
  3. The system is ready for a real transaction.
    Not a test. A real order, a real invoice, a real payment. We’re confident the workflow will hold.

Only when all three are confirmed do we move to the next step.

 

The First Live Transaction

This is the moment everything has been building toward. And if you’ve done the work, it’s almost anticlimactic.

The balances tie. The data is verified. The old system is locked down. Now it’s time to see the new system do what it’s supposed to do.

Pick something real.
Not a test order with fake data. A real customer, a real invoice, a real workflow. This is where you find out if the system works the way everyone expects.

Walk it through end to end.
Enter the order. Check inventory allocation. Generate the invoice. Post it. Send it. Every step that will happen a hundred times next week should happen once, right now, with someone watching.

Confirm it lands correctly.
Does the invoice hit the right GL accounts? Does inventory decrement properly? Does the customer balance update? This isn’t about trusting the software. It’s about trusting your setup.

If the first transaction runs clean, you’re live. Not “sort of live” or “live but still figuring things out.” Actually live.

If something breaks, you catch it now, with one transaction to fix, not fifty.

This is why the preparation matters. A clean first transaction isn’t luck. It’s the result of everything that came before it.

 

What Does Not Happen on a Good ERP Go-Live

A good go-live is defined as much by what doesn’t happen as by what does.

On go-live day, you should not be:

Figuring out your chart of accounts structure.
That conversation happens weeks earlier. If you’re debating account numbers while trying to convert data, you’re not ready.

Debating workflow decisions.
Who approves what? How do returns work? Where do these transactions post? These questions are fine in discovery. On go-live day, they’re a red flag.

Designing forms from scratch.
Invoices, packing slips, purchase orders. If you’re building these on go-live day, you’re going to be sending ugly documents to real customers while you figure it out.

Teaching basic navigation.
Users should already know where to click. Go-live day is for answering “what do I do in this specific situation,” not “how do I create an invoice.”

Migrating 30 years of messy history at the last minute.
You don’t need every transaction from 2003. You need clean opening balances and enough history to operate. Deciding what to bring over is a planning conversation, not a go-live conversation.

If any of these are happening on go-live day, it’s a sign that something got skipped earlier. The day itself isn’t the problem. The preparation was.

 

Why ERP Go-Live Should Not Feel Dramatic

There’s a certain mythology around go-live. The all-nighter. The war room. The heroic scramble to fix something at the last minute.

That makes for a good story. It does not make for a good implementation.

ERP success is not about a dramatic launch. It’s about a stable transition.

When go-live is calm:

Teams adopt faster.
People learn better when they’re not stressed. A quiet go-live gives users space to get comfortable instead of just survive.

Fewer errors occur.
Rushed decisions lead to mistakes. When there’s no panic, people take the time to do things right the first time.

Confidence builds immediately.
The first few days set the tone. If those days feel controlled, users trust the system. If those days feel chaotic, they start looking for workarounds.

Support requests stay manageable.
A calm go-live means questions trickle in instead of flooding in. That gives you time to answer thoughtfully instead of just putting out fires.

This is why the phased approach matters. Every decision made earlier, every workflow tested in the sandbox, every form reviewed before go-live day, all of it exists to make the actual transition feel almost boring.

Boring is the goal. Boring means it worked.

 

Common ERP Go-Live Mistakes I’ve Seen

I’ve seen a lot of go-lives. The ones that struggle tend to share the same patterns.

Skipping sandbox testing.
“We’ll figure it out in production.” This sounds efficient until you’re fixing live data in front of real customers. The sandbox exists for a reason. Use it.

Underestimating cleanup time.
Data cleanup always takes longer than anyone expects. Old duplicates, inconsistent naming, customers who haven’t ordered in a decade. Cleaning this up is tedious work, and it can’t be rushed. Build more time into the schedule than you think you need.

Waiting to train until after launch.
The logic seems reasonable: why train people on a system that isn’t live yet? But users who see the system for the first time on go-live day are learning and working at the same time. That’s a recipe for mistakes and frustration. Training happens before go-live, not during.

Over-customizing to match the old system.
“Can we make it look like what we had before?” Sometimes, yes. But chasing the old system’s quirks often means fighting the new system’s strengths. The goal isn’t to replicate what you had. It’s to work the way the new system was designed to work.

None of these mistakes are fatal on their own. But stack a few together, and a go-live that should have been smooth turns into a scramble.

 

The Bigger Message

A good ERP go-live day is not the finish line. It’s the starting point.

The system is live. The data is clean. Transactions are flowing. But that doesn’t mean the work is done. It means the real work is beginning.

Post-go-live optimization.
The first few weeks will reveal things you couldn’t see before. Reports that need tweaking. Workflows that could be smoother. Small friction points that only show up when people are using the system every day. This is normal. Plan for it.

Gradual adoption of advanced features.
You don’t need to use everything on day one. Start with the core workflows. Get comfortable. Then layer in the more advanced capabilities when the team is ready. Trying to do too much too fast is how systems get abandoned.

Continuous refinement.
A good ERP isn’t something you set up once and forget. It evolves with your business. New products, new processes, new reporting needs. The companies that get the most value from their systems are the ones that keep refining them over time.

Go-live is a milestone, not a destination. The goal was never just to get the system running. The goal is disciplined operations, and that’s a practice, not an event.

Where to Start

If your current implementation plan relies on figuring things out during go-live, it’s not a plan.

A real plan means decisions are made before go-live day. Workflows are tested. Data is clean. Users know what to do. The day itself is just execution.

If that’s not where you are, there’s still time to fix it.

If you’re mid-project and something feels off, let’s talk. An implementation review can spot what’s been missed before it becomes a go-live day problem.

If you’re still in the planning stages, start with my Migration Readiness Checklist. It walks through what to expect and how to prepare before moving to a new system, from data cleanup to team preparation to cutover planning.

Either way, the goal is the same: a go-live day that feels boring. Because boring means it worked.

 

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you’re evaluating your options, we can book a free 15-minute call 

BusinessVision End of Life: What It Actually Means for Your Business

BusinessVision End of Life: What It Actually Means for Your Business

When software hits end of life, most people assume it’s a crisis. The system stops working. You have to switch immediately. It’s a forced decision.

That’s not how it actually plays out.

In my experience, the people running EOL software aren’t panicking. They’re stockpiling old computers. They’re relying on consultants who are semi-retired or dealing with health issues. They’re putting off the decision because the system still turns on every morning.

And that works. Until it doesn’t.

I’ve seen companies buy new software and sit on it for a year because this migration stalled. I’ve seen others downgrade to QuickBooks because the “right” solution felt too complex, even though their business had already outgrown QB. I’ve had a client insist on upgrading to a fancier package with a familiar name, only to hate it so much they asked for a refund and switched to what I’d originally recommended.

The real risk of end-of-life software isn’t a dramatic crash. It’s the slow accumulation of bad options, made quietly, under pressure, without a plan.

This post is for the people who think they’ve got it handled. Maybe you do. But let’s talk about what “end of life” actually means, what it costs, and what a realistic path forward looks like.

What “End of Life” Actually Means

End of life doesn’t mean the software stops working. It means the safety net around it starts to fray.

No more vendor support.
No bug fixes. No patches. No one to escalate to when something breaks. And no regulatory updates, which matters if your software touches payroll or tax compliance.

Compatibility risk increases.
About four years ago, a Windows 10 update (22H2) caused problems for any software using the Crystal Reports runtime. Softrak issued service packs for Adagio, but only for current versions. Clients who had resisted upgrading their software were suddenly forced to choose: upgrade now, or stay on an older version of Windows indefinitely.

That’s the pattern. When something breaks, the vendor fixes it for supported versions. If you’re behind, you’re on your own.

The talent pool is shrinking.
I know two DacEasy consultants. One has health issues. The other would rather be on the golf course. The consultants who were there from the beginning of these legacy products are getting older. Many are semi-retired. They’re still around, but not always available when you need them. I’ve picked up clients over the years whose original consultants became harder to reach.

This isn’t a crisis. But if your current support person retired tomorrow, do you know who you’d call next?

The Real Costs of Waiting

The system still runs. So what’s the problem?

The problem is everything you’re doing to keep it running.

Technical debt accumulates quietly.
Every workaround becomes part of the process. Every spreadsheet that duplicates what the system should do. Every manual step that someone has to remember. It all adds up, but it’s invisible because it’s “just how we do things.”

One client, after migrating from a DOS-based system to a Windows one, told me he couldn’t believe this software let him automate so much. 20 years, he’d worked the long way to make it work. You could hear him kicking himself. After the migration, they reduced a position in the accounting department. All that manual work, gone.

You lose leverage when you wait.
The longer you delay, the fewer options you have. Consultants get booked. Your internal champion leaves. A Windows update forces your hand. And suddenly you’re making a major decision under pressure instead of on your own timeline.

The “free” system isn’t free.
If you’re stockpiling old hardware, relying on a semi-retired consultant, or holding your breath every time Windows pushes an update, you’re paying for that system. Just not in software fees.

The question isn’t whether your current system still works. It’s whether the effort to keep it working is worth more than the cost to move forward.

What a Realistic Path Forward Looks Like

You don’t need to panic. But you do need to start before you’re forced to.

Give yourself 3–6 months.
That’s a realistic timeline for a migration once you’re committed. Enough time to evaluate options, clean your data, learn the new system, and go live without rushing. But give yourself more runway if you’re waiting for year-end or if you know your team has competing priorities. If you wait until your current system breaks or your consultant retires, you lose that flexibility.

Buy what fits, not what sounds impressive.
It’s tempting to go with the big name or the feature-packed option. And if your legacy software is owned by a larger company, you might assume their other products will be a natural fit. Easier migration, familiar territory.

But often, the only thing those products have in common is the company name. Sage owns BusinessVision and DacEasy, but Sage 50, Sage 100, and Sage 300 are nothing like them, or even like each other. The names are deceiving.

Most software isn’t better software. A system built for a company three times your size will cost more, take longer to implement, and frustrate your team with complexity they don’t need. The goal isn’t the most powerful system. It’s the right system for how you actually work.

Clean your data before it moves.
Software migrations fail for a lot of reasons, but the one I see most often is dirty data. Customers who went out of business a decade ago. Vendors you haven’t ordered from since 2016. Notes stuffed into fields where they don’t belong.

Legacy systems are forgiving. Tell you not anything anywhere. Modern systems aren’t. If you don’t clean it up before migration, your import fails, or worse, it succeeds and now you’ve got garbage in your new system.

The best time to clean your data was five years ago. The second best time is before your next migration.

Use a sandbox to learn without pressure.
I like to do a quick conversion into a sandbox environment: a copy of your data, not live. Your team can learn the new system on familiar information with no pressure. You figure out what forms need tweaking, what custom reports you need, and how the workflow actually feels. All before you go live.

Some clients like parallel running as a safety net, and that’s fine. But with a full conversion and a sandbox period for learning, it’s usually not necessary.

Why Waiting Too Long Gets Expensive

This is what catches a lot of people off when software suddenly stops working. It’s that your options quietly disappear.

Implementation partners book up.
The consultants who specialize in migrations from legacy systems aren’t sitting around waiting for the phone to ring. The good ones are booked months out. When a wave of companies all realize they need to move at the same time, capacity gets tight. Rushed timelines mean higher stress, more mistakes, and sometimes higher costs.

You end up saying yes to whatever fits your schedule.
When your timeline is short, you don’t pick the best option. You pick the first one that’s available. That’s how companies end up in systems that don’t fit, with partners who weren’t their first choice, paying for expedited work they could have avoided.

Timing is more flexible than you think. But not always.
You might assume year-end is the time to migrate. For some systems, that’s true. If you’re starting fresh with no historical data, a clean January 1 datover makes sense. But for systems like BusinessVision where the full history converts over, you have more flexibility. In those cases, year-end might actually be the worst time to go-live. Your finance team is already stretched, and you don’t need that much brain anyway. The right timing depends on how your data converts, not the calendar.

It just gets more complicated. The companies that move smoothly are the ones who started the conversation early, not the ones who waited until something broke.

Who Should Be Thinking About This Now

The BusinessVision users most at risk aren’t necessarily the most complex. They’re the ones where the business has shifted in ways the system was never designed to handle.

Ownership transitions.
Incoming ownership wants clean systems and clean data. A legacy platform makes due diligence harder and integration more expensive. If a sale or succession is on the horizon, the system question will come up whether you’re ready for it or not.

Key staff nearing retirement.
When the person who knows how to make BV work leaves, institutional knowledge goes with them. That’s the moment companies realize they’ve been running on tribal knowledge rather than a system. If your BV expert is counting down to retirement, your timeline just got shorter.

Export, manipulate, repeat.
There’s nothing wrong with using Excel. Some of the best reporting tools pull live data into Excel and let you build exactly what you need.  The red flag is when someone has to export data, manipulate it manually, and rebuild teh same report from scratch every month just to get a clear picture of the business.  That’s not reporting.  That’s a workaround.

The Bottom Line

Your software isn’t going to send you a calendar invite when it’s ready to fail.  It’s just going to stop working one day, or slowly become so painful that your team spends more time on workarounds than actual work.
You don’t have to move tomorrow.  But you do have to start thinking about it before the decision gets made for you.
Here’s where to start:

If you want to get organized before talking to anyone:
I put together a short guide with the questions you should work through before you talk to a consultant. Things like how many users you have, where your data stands, what your timeline looks like. It helps you walk into that first conversation prepared, not scrambling.

If you’re ready to talk through your options:
I’m happy to have a conversation about what you’re running, what’s working, and what might make sense going forward. No pressure, no pitch.

~Audrey Quick, Founder of AGS Enterprises Consulting LLC

Audrey has spent 35+ years helping businesses manage ERP implementations and accounting software transitions.  If you’re evaluating your options, we can book a free 15-minute call