You're Not Alone

You went live six months ago. Or maybe two years ago. Or five. The implementation is officially "done"—the project closed, the final invoices were paid, the implementation partner moved on to other clients. But nobody's happy.

Users complain constantly about how hard the system is to use. Reports don't work reliably—or worse, they produce different numbers on different days. Finance still relies on spreadsheets for anything important because they don't trust the system. The ERP that was supposed to transform your operations has become another problem to manage.

If this sounds familiar, you're not alone. Research consistently suggests that 50-70% of ERP implementations fail to meet their original objectives. That's not a NetSuite problem—it's an ERP implementation problem. But knowing it's common doesn't make your situation any less frustrating.

The question isn't whether your implementation struggled. It's why it struggled, and more importantly, what to do about it now.

The Usual Causes

Requirements Were Wrong

The most common cause of implementation failure is that the solution built doesn't match what the business actually needed.

During implementation, you described your requirements as best you could. The partner documented them and built what you described. But there's often a gap between what people ask for and what they actually need. Users describe their current process, not their ideal process. They mention the transactions they process every day but forget about the quarterly exception. They know what they want to see on reports but not what data is needed to produce those reports.

The partner builds what was specified. Go-live happens. And then reality hits: the system works as designed, but it wasn't designed for how work actually gets done.

This isn't necessarily anyone's fault. Requirements gathering is genuinely difficult. Users don't know what they need until they don't have it. Business processes look different on paper than in practice. Edge cases and exceptions are invisible until they occur. But understanding the cause points toward the solution: the requirements need to be revisited and the system adjusted to match reality.

Data Migration Was Botched

Data migration is often treated as a technical task to be squeezed in at the end of the project. What data do you have? Where does it need to go? Write some scripts, load it up, done.

But bad data migrated is still bad data. If your old system had duplicate customers, inconsistent vendor records, and transactions that didn't quite tie out, all of that came into NetSuite. The new system didn't create data problems—it inherited them.

Common migration failures:

• Incomplete history: Historical transactions didn't migrate cleanly, so you can't see what happened before go-live

• Incorrect mappings: Data went into wrong fields or wrong record types, creating systematic errors

• Missing records: Customers, vendors, or items that existed in the old system but didn't make it to NetSuite

• Duplicate entries: The same customer or vendor exists multiple times with slight variations

• Orphaned transactions: Invoices without customers, orders without items, entries that don't tie out

Data migration often gets rushed at project end when budgets are exhausted and timelines are blown. The foundation gets cracked from day one, and everything built on it is unstable.

Training Was Insufficient

A few hours of training during go-live week. Users sitting through webinars while simultaneously trying to do their jobs. Training materials that explain which buttons to click but not why or when. Then go-live happens, and everyone is expected to be productive immediately.

Users learned enough to survive but not enough to be efficient. They figured out one way to accomplish their tasks—usually not the best way—and stuck with it. They don't know about keyboard shortcuts, saved searches, favorites, or bulk actions. They don't know what they don't know.

Bad habits became standard practice. The AP clerk who takes 15 clicks to enter a bill because nobody showed her the better way. The sales rep who exports everything to Excel because he doesn't know how to build saved searches. The controller who maintains a spreadsheet tracking system outside NetSuite because she doesn't trust the data and doesn't know how to fix it.

And when the trained people leave—as they inevitably do—their knowledge leaves with them. The next generation learns from people who didn't know the right way either. Institutional capability degrades over time instead of improving.

Custom Development Was Poor Quality

Scripts that work but nobody understands. Workflows that were built three administrators ago with no documentation. Custom records that exist but nobody knows why. Saved searches that reference fields nobody remembers creating.

Poor customization isn't the same as customization. The problem isn't that custom code exists—it's that it was built without documentation, without testing, without consideration for maintenance.

Symptoms of poor-quality customization:

• Scripts that break with no clear error message

• Workflows that fire inconsistently

• Performance problems that nobody can diagnose

• Changes that break unrelated things

• Nobody knows what's safe to modify or remove

Poor customization isn't just technical debt—it's a trap. You can't improve the system because you don't understand what you have. You can't remove things because you're not sure what depends on them. Every change is a risk.

The Partner Disappeared

Go-live happened. The final invoice was paid. The partner said "call us if you need anything" and then became mysteriously unavailable. Questions went unanswered. Issues lingered unresolved. You were left to figure out problems alone.

Implementation partners are optimized for go-live. Their success metrics, their staffing, their economics are all oriented toward getting projects launched. Post go-live support is often an afterthought—understaffed, under-resourced, and under-prioritized compared to the next new implementation.

This isn't necessarily malicious. Partners have to win and deliver new work. The people who know your implementation get assigned to other projects. Support becomes a matter of whoever's available looking at your system fresh each time, without context or history.

The result: you're on your own with a system you don't fully understand, built by people who are no longer available to explain it.

Change Management Was Neglected

Nobody prepared users for the change. Nobody addressed their concerns. Nobody explained why the new system was better. Nobody acknowledged that change is hard. Users were told to use the new system and left to struggle.

User resistance isn't irrational—it's the predictable response to change imposed without support. The person who spent ten years mastering the old system is now a beginner again. The workarounds they developed don't work anymore. The efficiency they'd built has to be rebuilt from scratch.

Without change management, even a well-implemented system can fail adoption. Users route around it. They find ways to avoid it. They develop workarounds that defeat the purpose of having an integrated system. The investment in technology is wasted because the human side wasn't addressed.

The Path Forward

You have two fundamental choices: live with a broken system or fix it.

Living with it means permanent inefficiency. Perpetual workarounds. Ongoing frustration. A constant tax on productivity and morale. The problems you have today will be the problems you have next year and the year after that.

Fixing it requires investment—time, money, attention. But it's a finite investment that ends the ongoing tax. The effort required depends on how broken things are, but almost everything can be fixed with the right approach.

Assess What You Have

Before fixing anything, understand the current state. What actually exists? What works? What doesn't? What do you have that you don't even know about?

A proper assessment examines:

• Configuration: How is the system set up? What custom fields, forms, records exist?

• Customizations: What scripts, workflows, and integrations are deployed? What do they do?

• Data quality: Is the data accurate? Complete? Consistent?

• Usage: How are people actually using the system? What workarounds exist?

• Performance: What's slow? What causes errors?

• Gaps: What's missing? What doesn't work?

Assessment often reveals that the system is more capable than users realize, that problems trace to a few root causes, and that the path forward is clearer than it seemed.

Prioritize by Impact

You can't fix everything at once. Resources are limited, and change management capacity is limited. Trying to fix too much at once creates chaos.

Prioritize based on impact:

• Pain severity: How much does this problem hurt?

• Frequency: How often does this issue occur?

• User count: How many people are affected?

• Downstream effects: What other problems does this cause?

• Fix difficulty: How hard is this to address?

Quick wins build momentum and credibility. They show users that improvement is possible and coming. Start with visible problems that can be fixed quickly, then tackle larger structural issues.

Rebuild What's Broken

Sometimes the right answer is replacing poor-quality customizations with solutions built properly—documented, tested, maintainable, performant.

Good customization replaces bad customization. The goal isn't removing customization; it's having the right customization built the right way. Well-built custom solutions can transform a broken system into one that genuinely helps.

Key principles for rebuilding:

• Document everything: What does it do? Why? How does it work?

• Test thoroughly: Before deploying to production, verify it works

• Consider maintenance: Who will support this? How will it be updated?

• Think about performance: Will this scale as data grows?

Invest in Training

If the original training was insufficient, provide better training now. Role-specific, hands-on, ongoing training that helps users become genuinely capable.

Effective remedial training:

• Starts with current state: What do users know? What don't they know?

• Focuses on real tasks: Not features but workflows—how to actually do the job

• Includes practice: Not just demonstration but hands-on work

• Provides resources: Documentation, reference guides, where to get help

• Continues over time: Follow-up sessions, office hours, advanced training

Training investment pays back in productivity. Users who know the system well work faster and make fewer errors.

Address Root Causes

Don't just fix symptoms. If the same issue keeps recurring, dig deeper to find and address root causes.

Examples:

• If data quality problems keep appearing, fix the entry points that allow bad data

• If the same questions keep coming, document the answers where users can find them

• If processes are confused, standardize and document them

• If reports don't tie, fix the underlying data issues rather than adjusting reports

Each root cause fixed is an entire category of problems prevented going forward.

Starting Over vs. Fixing

Sometimes the implementation is so far gone that starting over seems attractive. Burn it down, start fresh, do it right this time.

Usually, remediation is more cost-effective than replacement:

• You've already paid for the software license

• Data is already migrated, even if imperfectly

• Users have some familiarity with the system

• Historical transactions exist and would need to be preserved anyway

• Starting over risks repeating the same mistakes

Building on an imperfect foundation is typically cheaper than demolition—as long as you actually fix the foundation's weaknesses rather than building more on top of an unstable base.

The exceptions where starting over might make sense:

• Fundamental architecture is wrong for your business

• Data is so corrupted that cleaning would take longer than re-implementing

• The system was never appropriate for your requirements

  
  

Choosing the Right Fix-It Partner

If outside help is needed, choose carefully. The partner who did the original implementation might not be the right partner to fix it. They might bring fresh eyes and understanding of the history—or they might repeat the same mistakes with the same blind spots.

Look for:

• Honest assessment: They tell you what's actually wrong, not what you want to hear

• Documentation discipline: They build solutions that can be maintained by others

• Business understanding: They understand your operations, not just NetSuite technically

• Ongoing commitment: They'll support what they build, not disappear after deployment

• Appropriate expertise: They have skills in the specific areas where you need help

  
  

Bottom Line

A failed implementation isn't a permanent condition. Systems can be fixed. Processes can be improved. Users can be trained. Customizations can be rebuilt. The investment required is real but finite.

The cost of not fixing it is ongoing and permanent. Every month you operate with a broken system, you pay a tax—in inefficiency, in errors, in frustrated users, in decisions made with bad data. That tax compounds over time.

The question isn't whether your implementation can be saved—almost all can. The question is whether you'll make the investment to save it, or continue paying the failure tax forever.