Ensure a successful NetSuite implementation with an Alliance Partner by your side. Get expert guidance, support, and customisation services. Learn More!
Very few NetSuite implementations fail loudly. There is rarely a moment where the project is cancelled and everyone agrees it did not work. What happens instead is quieter and considerably more expensive. The system goes live, people find it harder than the old one, workarounds appear, a parallel spreadsheet becomes the real source of truth, and eighteen months later the business is paying for software it uses at a fraction of its capability.
That outcome is common enough to be worth planning against, and the thing that most reliably prevents it is not the software, the budget or the timeline. It is who you implement with. This article sets out why implementations go wrong, what an Alliance Partner actually brings, and how to tell a good one from a merely available one.
It helps to be specific, because businesses in this position often do not recognise it as failure.
The finance team still closes the month in a spreadsheet because the reports in NetSuite do not tie out. Nobody has investigated why, they simply stopped using them.
Half the modules you are licensed for were never configured. Someone made a decision during the project to defer them, and deferring turned into never.
Users have built their own process outside the system. Orders taken by email, approvals given verbally, stock counted on paper and entered later.
Every change request goes to an external consultant at an hourly rate, because nobody internally understands the configuration well enough to touch it.
And the reporting that justified the investment in the first place, the reason someone signed off a six figure project, has never materialised.
None of that shows up as a failed project on a status report. All of it shows up on the profit and loss.
The causes are consistent, and almost none of them are technical.
The single most common root cause. The partner did not spend enough time understanding how the business actually runs before configuring the system to support it. What gets built matches a generic model of a business in your industry rather than yours, and the mismatch surfaces during user acceptance testing when it is expensive to correct.
NetSuite touches finance, sales, operations, warehousing and payroll. Where the project is owned by IT and the departments are consulted occasionally, the resulting configuration reflects what IT understood rather than what those departments need.
Implementations need someone from the business with authority to make decisions, and enough time to make them properly. Where that person is doing it in the gaps between their real job, decisions get deferred, and deferred decisions become defaults nobody chose.
Almost every project underestimates this. Existing data is messier than anyone expects, historical records need decisions about how far back to bring, and the mapping between old and new structures is rarely clean. Migration problems discovered late compress everything downstream.
A two hour session a week before go live, covering everything, delivered to people already stretched. Retention from that is close to zero, and the support burden after go live reflects it.
Businesses often ask for the new system to replicate the old one, including its inefficiencies. A partner who says yes to all of it produces something expensive to maintain that preserves problems the project was supposed to solve.
The weeks after go live are when adoption is decided. Where the partner disengages at cutover, users hit their first real problems with nobody to help, and the workarounds that define the next three years get invented in that fortnight.
Oracle NetSuite works through a partner channel, and Alliance Partner is a designation given to firms that implement NetSuite and meet Oracle's requirements around certification, delivery capability and customer outcomes.
The designation matters for a few practical reasons. Certified consultants have demonstrated knowledge against a defined standard rather than simply claiming experience. The partner has a direct relationship with Oracle, which matters when an issue needs escalating beyond standard support. And the partner is accountable to Oracle for how implementations land, which is a form of pressure a general IT consultancy does not have.
It is not a guarantee of a good outcome, and treating it as one is a mistake. It is a floor rather than a ceiling, and the difference between partners above that floor is considerable.
Product knowledge is the entry requirement, not the differentiator. Anyone implementing NetSuite knows the software. The things that separate outcomes sit elsewhere.
Process knowledge is first. A partner who has implemented for businesses like yours knows which decisions matter and which do not, where the standard configuration usually needs adjusting, and which requests turn out to be unnecessary once someone has seen the alternative. That knowledge shortens discovery and improves what comes out of it.
The willingness to disagree is second, and it is the one most businesses undervalue. A partner who agrees to everything is easy to work with and produces a worse system. When you ask for something that will cost you later, you want to be told.
Local knowledge is third, and for Australian businesses it is not optional. Single Touch Payroll Phase 2 reporting, superannuation guarantee obligations and their payment timing, GST and BAS treatment, modern award interpretation, Fair Work record keeping requirements. A partner implementing from offshore with no Australian delivery experience will get some of this wrong, and payroll and tax are the two areas where getting it wrong has consequences beyond inconvenience.
If you take one thing from this, make it this. The quality of discovery predicts the quality of the outcome more reliably than any other factor.
Good discovery means the partner sits with the people who do the work, not only the people who manage them. It means watching a real order go from enquiry to cash, a real purchase go from requisition to payment, a real month end close. It means asking why things are done the way they are, and distinguishing between requirements that matter and habits that have accumulated.
It produces a documented understanding of your processes that you can read and correct before anyone configures anything. If the partner cannot show you that document, discovery did not happen properly.
Partners who compress discovery to win on price are common, and the saving is illusory. Every hour not spent understanding the business is spent later reworking something built on a wrong assumption, at a worse point in the project.
The instinct is to treat migration as a technical task near the end. It is neither technical nor near the end.
The decisions are business decisions. How much transactional history do you actually need in the new system, given you will retain the old one in read only form? Which customer records are genuinely active? Which items are still sold? What do you do with the duplicates, the incomplete addresses, the accounts nobody has touched in four years?
Those decisions take longer than the technical loading does, and they cannot be made by the partner. Starting them early, and treating the migration as an opportunity to clean rather than to copy, is one of the few genuinely free improvements available in an implementation.
Adoption is the outcome that matters, and adoption is a people problem wearing a technology costume.
Training works better in short sessions close to go live, role specific rather than generic, using your own data and your own processes rather than a demonstration account. People remember what they did, not what they watched.
Identifying a few people in each team who learn it early and become the person others ask makes a substantial difference. Most questions after go live are small, and a colleague two desks away answers them faster than any support channel.
And documentation written for your configuration, not the generic help, is what makes the capability survive staff turnover. Ongoing NetSuite training after go live is worth budgeting for rather than treating as a project line item that ends at cutover.
The reference call is the most useful of these and the most frequently skipped. Ask specifically about what went wrong, because something always does, and how the partner behaved when it did tells you more than a clean success story.
A few signals justify caution.
A quote produced without meaningful discovery is a quote for a project nobody has scoped. The number will change.
A proposal with no assumptions listed means the partner has not thought about what could vary, or has thought about it and prefers you not to.
Senior people in the sales meeting who disappear afterwards is common enough to ask about directly.
Agreement with every request, including the ones you were not confident about yourself, suggests the partner is optimising for winning the work rather than for the outcome.
And a timeline noticeably shorter than everyone else's is usually achieved by removing discovery, testing or training, all of which you will pay for afterwards.
Plenty of businesses reading this are past the point of choosing a partner. The position is recoverable more often than it feels.
The first step is an honest assessment of the current state. What is configured, what is customised, what is actually used, where the workarounds are and what they exist to compensate for. That assessment is uncomfortable and it is the only sound basis for deciding what to do next.
Frequently the answer is less dramatic than expected. Some things need reconfiguring, some customisations should be removed, some reporting needs building, and some of it is a training gap rather than a system gap. Rebuilding from scratch is rarely the right call and is usually the first thing people consider.
This is the territory implementation rescue covers, and taking it on early is considerably cheaper than living with the situation for another two years.
NetSuite is a significant commitment, and the licence is only part of it. The implementation, the internal time, the disruption and the ongoing capability to run it all belong in the same calculation.
Set against that, the difference in fee between a partner who does discovery properly and one who does not is small. The difference in outcome is not. A system people use, that produces numbers finance trusts, that adapts as the business changes, returns its cost repeatedly. One that people work around is a permanent drag on the same business.
The decision that determines which of those you get is made before the project starts.
If you are evaluating NetSuite or about to select a partner, our NetSuite implementation approach sets out how we run projects and what we expect from both sides. Where the decision is still upstream of that, and the question is whether NetSuite is the right platform at all, advisory and strategy is the more useful starting point.
For the ongoing capability question, which is the one businesses most often defer and most often regret deferring, managed services covers how that support works after go live.
If you would rather talk it through than read about it, get in touch.
