NetSuite Solution Provider vs NetSuite Alliance Partner. Which is right for your business?

NetSuite Solution Provider vs NetSuite Alliance Partner - Which is right for your business? Discover the best business software support options for your businesses needs.

NetSuite Solution Provider vs NetSuite Alliance Partner. Which is right for your business?

Table of Contents

Somewhere in the process of buying NetSuite, most businesses encounter two terms that nobody defines. Solution Provider and Alliance Partner describe different commercial arrangements, and the difference determines who you contract with, who you renew with, and how easily you could change implementation partner later.

It is not a difficult distinction and it is rarely explained, largely because each firm tends to describe only the model it operates. This article sets out how the two differ, what each means in practice, and which is likely to suit different circumstances.

How Oracle sells NetSuite

NetSuite reaches customers through more than one route, and the routes have different commercial shapes.

Oracle sells directly, with its own sales team and its own contract, and the customer then either uses Oracle's professional services or engages a partner to implement.

Solution Providers resell the licence. The commercial relationship for the software sits with the partner rather than with Oracle, and the partner typically implements as well.

Alliance Partners implement for customers who license directly from Oracle. The software contract is with Oracle and the services contract is with the partner.

The practical consequence is that you are making two decisions rather than one, and the second matters considerably more than the first.

What a Solution Provider arrangement looks like

Under this model, one firm handles both the software and the implementation.

You sign a licence agreement with the partner rather than with Oracle. They handle provisioning, they invoice you for the subscription, and they typically manage renewals. The implementation contract sits with the same firm.

The appeal is simplicity. One relationship, one point of contact, one set of commercial terms, and one party accountable for everything from provisioning through to go live.

There can also be commercial flexibility, since a reseller has some latitude in how it packages software and services together, which occasionally produces a better overall arrangement than contracting separately.

The corresponding consideration is concentration. Both the software you depend on and the services that make it work come from one firm, which is efficient and reduces your options if the relationship deteriorates.

What an Alliance Partner arrangement looks like

Under this model the two contracts are separate.

Your licence agreement is with Oracle directly, so provisioning, subscription invoicing and renewals sit there. The implementation is contracted with the partner.

The appeal is separability. If you later decide to change implementation partner, or to bring capability in house, the software relationship is unaffected. You are not renegotiating your entire arrangement to change who does the services.

It also means the licence relationship is with the party that owns the product, which some businesses prefer for a platform they expect to run for a decade.

The corresponding consideration is that you manage two relationships rather than one, and where something is ambiguous you may find yourself between them.

What the designation itself signals

Beyond the commercial structure, the Alliance Partner designation carries requirements around certification, delivery capability and customer outcomes.

Certification means consultants have demonstrated knowledge against a defined standard rather than asserting experience. That is a floor rather than a guarantee of quality, and it is a meaningful floor.

A direct relationship with Oracle matters at specific moments, particularly when an issue needs escalating beyond standard support or a product question needs an authoritative answer.

And accountability to Oracle for how implementations land is a form of pressure that a general consultancy taking on NetSuite work does not carry.

Solution Providers are subject to their own requirements, and a firm holding either designation has met a standard. The differences between individual firms above that standard remain considerably larger than the differences between the models.

Which tends to suit which situation

Neither model is better in general, and a few patterns are reasonably consistent.

Businesses that value a single relationship and expect a long partnership frequently prefer the Solution Provider model, because the simplicity is real and the concentration is an acceptable trade.

Businesses that expect to build internal capability over time, or that want the option to change services provider without disturbing the software, tend to prefer contracting with Oracle directly.

Larger businesses with procurement functions that prefer to contract with the vendor of record generally end up licensing directly regardless of other considerations.

And businesses with an existing relationship they trust reasonably follow that relationship, which is a defensible basis provided the model is understood rather than assumed.

What actually matters more than the model

It is worth being direct about this, because the commercial structure attracts more attention than it deserves relative to its effect on the outcome.

The software is identical under either model. Your account will have the same capabilities configured by whoever configures it.

What determines whether the investment returns is how well the implementer understood your business before configuring anything, whether they were willing to disagree with you, whether they know Australian requirements properly, and whether they stay engaged after go live.

A poor implementation under either model produces a system people work around. An excellent one under either model produces a system people use. The commercial structure affects your flexibility later and has almost no bearing on that outcome.

Where the implementation decision actually turns

Since the partner rather than the model determines the outcome, it is worth naming what separates them.

Discovery depth is the clearest predictor. A partner who spends genuine time understanding how your business runs before configuring anything produces something that fits. One who compresses discovery to win on price produces something generic that people work around, and the saving is illusory because every hour not spent understanding is spent later reworking.

Process knowledge is the second. Everybody knows the software. The valuable ones have seen how many businesses solved the same problems and can tell you which of your practices are genuine requirements and which are habits inherited from the system you are replacing.

Willingness to disagree is the third and the most undervalued. When you ask for something that will cost you in maintenance or upgrade friction, you want to be told. A partner who agrees to everything is easy to work with and leaves you with an account nobody can safely change.

And continuity is the fourth, meaning whether the people who presented are the people who deliver, and whether anybody stays engaged after cutover.

Australian requirements under either model

Worth raising specifically, because it is where the largest exposures sit and where the commercial model is irrelevant.

Single Touch Payroll Phase 2 requires income disaggregated into components rather than reported as a single gross figure, with allowances by type and cessation reasons on termination.

Superannuation guarantee must be calculated on ordinary time earnings rather than gross pay, with the base defined correctly per payment type, and contributions received by the fund by the quarterly deadline rather than merely sent.

Modern award coverage depends on the industry and the work performed rather than on job titles, and it applies considerably more often than businesses assume.

A partner without Australian delivery experience will get some of that wrong regardless of what designation they hold, which is why the question of who configures payroll and tax is worth asking directly.

Questions worth asking regardless of model

  • Who specifically will work on our project, and are they the people in this meeting?
  • How many implementations have you delivered for businesses of our size in our industry?
  • What does your discovery phase involve, and what document do we receive from it?
  • Can we speak with two recent clients, including one where something went wrong?
  • When do you tell a client not to do something they have asked for?
  • Who configures Australian payroll and tax, and what is their background?
  • What happens in the first month after go live, and is it included?
  • If we engaged a different services partner in two years, what would change commercially?

That last question is where the model becomes concrete, and the answer tells you what you are actually committing to rather than what the designation implies.

The reference call

The most informative step available and the most frequently skipped.

Ask for two clients who went live in the last year, and specifically ask for one where something went wrong.

Every project has a difficulty. A partner who claims otherwise is either selecting references carefully or has not delivered many projects.

What you are listening for is behaviour at that moment. Whether they raised it early, whether they were straight about the cause, and whether they absorbed any of the cost where it was theirs to absorb.

That behaviour is what you are actually buying, since it determines your experience when your own project encounters its difficulty.

Renewals and what to watch

The commercial difference becomes most visible at renewal, which is worth thinking about before the first contract rather than at the second.

Under either model, understand the term, what happens at renewal, how pricing may change, and what the process is for adding or removing users and modules.

Where you license through a reseller, understand what happens if you wanted to move the licence relationship, since that is a conversation better had hypothetically than in the middle of a dispute.

And under either model, avoid licensing modules you have no configuration project for. Paying for capability nobody has implemented is the most common and most avoidable waste in a NetSuite investment, and it accumulates quietly across renewals.

Changing partner later

Businesses do change implementation partners, usually because the relationship stopped working rather than because of anything dramatic, and it is worth knowing what that involves.

Where you license directly, changing services partner is a services decision. The account, the data and the configuration are unaffected.

Where you license through a reseller, it depends on the arrangement. In many cases the licence can remain with the reseller while services move elsewhere, and establishing that in advance is considerably easier than establishing it during a separation.

In either case, what makes a change practical is documentation. An account with documented configuration and customisations can be picked up by a competent successor. One without it requires an archaeology exercise first, and that cost falls on you regardless of who caused it.

The thing that actually protects you

Following from that, the most useful protection is not the commercial model. It is insisting that whoever implements leaves you documented.

What was configured and why. What customisations exist, what they do and what depends on them. What integrations exist and how they behave. What decisions were made during design and what the reasoning was.

A partner comfortable providing that is confident in the value they add. One who resists it is relying on being difficult to replace, and that is a more meaningful warning than anything in the commercial structure.

It is also worth asking what happens to that documentation as the account changes, since documentation produced once at go live describes an account that no longer exists within two years.

Where the ongoing relationship fits

One consideration that spans both models and deserves deciding early.

Most businesses need ongoing capability after go live rather than occasional projects. Somebody to answer questions, build reports, keep configuration current, monitor scheduled processes and test the twice yearly releases.

Where that will not sit internally, it needs a provider, and a partner who already knows your account is considerably more efficient than one starting cold.

That makes the ongoing arrangement part of the partner decision rather than a subsequent one, and asking about it during selection tells you whether the firm thinks of the relationship as a project or as something continuing.

Our managed services approach covers how that arrangement works in practice.

Where to go from here

The commercial model is worth understanding and is not the decision that determines your outcome. Spend the evaluation effort on the implementation team rather than on the contracting structure.

Our piece on choosing a NetSuite Alliance Partner covers what to look for in a partner in more detail, and why implementations fail covers the failure modes worth guarding against.

Our approach to NetSuite implementation sets out how we run projects, and where the question is still whether NetSuite is right at all, advisory and strategy is the better starting point.

If you are working through a proposal and want a straight explanation of what you are being offered, get in touch.