How to Choose a NetSuite Consulting Partner

What is the difference between an implementation partner and a post-go-live partner?

An implementation partner runs the project that takes a company from no NetSuite to live on NetSuite. The work is project-based with a defined scope: configure modules, migrate data, set up roles and permissions, train users, and hand off a functioning system. Implementation projects run anywhere from a few months for a straightforward account to over a year for complex multi-subsidiary deployments. Oracle certifies implementation partners at different tiers (Solution Provider, Star, and above) based on delivery volume and customer satisfaction scores.

A post-go-live partner handles the work that comes after handoff: user questions, configuration changes, custom development, workflow maintenance, the twice-yearly release cycle, and the slow accumulation of improvements that make a live NetSuite account more useful over time. This work has no defined end date. It is a subscription-like relationship where institutional knowledge of the account compounds in value over months and years. The skills required are different from implementation: deep familiarity with the customization model, SuiteScript development capability, and the ability to diagnose problems in a system that is already live rather than building from scratch.

Most companies need an implementation partner to go live, then a different kind of partner for what comes after. See NetSuite post-go-live support for what that looks like in practice.

Which NetSuite certifications indicate actual technical capability?

Oracle offers several NetSuite certification tracks. The ones that indicate genuine technical depth for post-go-live work are:

Oracle NetSuite SuiteCloud Developer II: Validates SuiteScript 2.x development capability including client scripts, user event scripts, Scheduled scripts, and Map/Reduce scripts. A developer without this certification is not a verified NetSuite developer. Certification at the SuiteCloud Developer I level is the entry credential; SuiteCloud Developer II is the advanced track that covers complex script types.

Oracle NetSuite Administrator Professional: Validates platform configuration capability including roles and permissions, workflow automation, saved searches, report building, and period close procedures. This is the credential for the person who manages a live account day-to-day.

ERP Consultant and Financial User: Module-specific credentials that validate knowledge of specific functional areas. Less relevant for technical support work, more relevant for implementations in those modules.

Certifications are necessary but not sufficient. A partner can hold certifications without having worked on accounts similar to yours. Ask specifically about implementations or ongoing support engagements in your industry and your NetSuite module footprint. A certified developer who has never touched a manufacturing account will have a learning curve on your BOM logic and production workflows.

How should pricing models affect the decision?

Implementation partners typically price on time-and-materials or fixed-fee contracts. Either model is appropriate for project-based work with a defined scope. Fixed-fee provides cost certainty; time-and-materials provides flexibility when scope is uncertain or likely to change.

Post-go-live support has two main pricing models: retainer and time-and-materials. A retainer model, where you commit to a monthly hour block at a fixed rate, creates different incentives than time-and-materials. On a retainer, the partner has a financial interest in keeping your account clean and well-documented so requests resolve quickly. On time-and-materials, the partner bills by the hour regardless of how long a task takes. For a steady-state account with regular support needs, a retainer almost always produces better outcomes and lower total cost over time.

Watch for partners who quote aggressively low hourly rates but apply them to tasks that take significantly longer than they should. An experienced NetSuite developer resolves a script issue in one to two hours. An inexperienced developer on the same task may bill four to eight hours while producing a worse outcome. Effective hourly rate matters more than nominal rate.

What does a responsible release management process look like?

NetSuite releases updates twice a year, roughly in May and November. Each release changes something in every account. Some changes are behavioral, affecting how records save or how workflows execute. Some are interface changes that require user re-training. Some break existing customizations.

A partner who does not have a defined release management process is not actually managing your account; they are reacting to things after they break. A responsible process includes: reviewing the release notes specific to the modules in your account, identifying which changes affect active customizations or workflows, testing those customizations against the new release in Sandbox before it reaches Production, and communicating to your team what changed and what they need to do differently.

Ask any candidate partner: what was your release management process for the last NetSuite update? How do you identify which release notes are relevant to a specific client's account? What happened if something broke? If the answer is vague, the process does not exist.

What questions reveal whether a firm actually knows your account?

Before signing with any partner, ask these questions:

What customizations or integrations in our account type do you support most commonly? A partner who supports many companies in your industry will have seen your problems before. A generalist who supports a wide range of industries will have seen your account type rarely.

How do you approach sandbox testing for changes in a live account? Every change that affects financial records or active workflows should be tested in Sandbox before Production. A partner who deploys directly to Production is a significant risk.

What is your response time commitment for critical issues? For production-down scenarios, anything over four hours is too slow for most mid-market companies. Get the SLA in writing.

Who specifically will be doing the work on our account? Partners often sell on senior staff and deliver on junior staff. Identify the actual person doing the work and assess their capability directly.

How do you document the changes you make? Every customization that is not documented creates a dependency on the person who built it. A partner who does not document creates a situation where leaving them means losing institutional knowledge.

Have you read our customization list and asked us about our business processes? A partner who has not done this before proposing an engagement does not know what they are agreeing to support. They will discover the complexity after they start billing.

When does it make sense to switch partners?

The most common reason companies switch NetSuite consulting partners is accumulated frustration that was not specific enough to trigger a change. Tickets take longer than they should. Customizations break on releases without warning. The team stops asking for improvements because they expect them to take too long or cost too much. These are all signs that the support relationship is not working, but none of them individually prompts action.

The right time to evaluate is before the current situation becomes a crisis, not during one. Switching partners mid-incident is expensive. Switching after a relationship has broken down means the incoming partner inherits undocumented customizations and a team that is already frustrated.

For a detailed diagnostic on whether your current support relationship has structural problems, see 8 signs your NetSuite support isn't working.

What does a boutique post-go-live firm offer that a large partner does not?

Large NetSuite partners optimize for implementation volume. Their delivery model is built around running multiple simultaneous implementations with a tiered consultant structure. Post-go-live support for an already-live account is a different economic unit for them: smaller, less predictable, harder to staff efficiently. Some large partners handle post-go-live well; many do not, because their staffing model was designed for something else.

A boutique firm that specializes in post-go-live support for already-live accounts has a different structure: deeper knowledge of the platform's customization layer, faster context on specific account types, and a support model where the person doing the work is the person you talk to. The trade-off is scale. A boutique cannot run a large greenfield implementation. It can manage an existing account with more precision and lower overhead than a firm optimized for projects.

The correct choice depends on what you are actually buying. An implementation is a project. Post-go-live support is a relationship.