To switch NetSuite partners safely, secure control of your account before you announce the change: confirm your own staff hold Administrator access, collect source code and integration credentials, and list everything that runs under the outgoing partner's user records. Then agree a short overlap, transfer open work with evidence, and give the new partner a defined first outcome instead of a vague "take over support".
Most US companies that change partners do it after months of slow tickets or a stalled project. The frustration is real, and it pushes people to move fast. Moving fast is fine. Moving before you control the account is how a partner change turns into an outage.
Start with access. At least two of your own employees should hold the Administrator role, with two-factor authentication enrolled on devices the company controls. Check that the account's notification emails and Oracle NetSuite contacts point to your people, and that you know who signs your license renewal.
If your licenses were purchased through the partner, ask the partner and Oracle NetSuite how renewal and the partner relationship change. Do this before the renewal window, because the commercial side of a switch can take longer than the technical side.
This step prevents most outages. Scripts, scheduled jobs, workflows and integrations often run as, or are owned by, an employee record belonging to a partner consultant. Disable that record and things stop.
Run saved searches for scripts and deployments by owner, workflows by owner, and access tokens and integration records by user. Check saved searches and reports that other processes depend on. List every item with its owner and what it does. Plan to reassign each one to a company-owned user before the partner's access is removed.
Ask for the full source of every customization: SuiteScripts, SuiteCloud project files, workflows exported or documented, and any middleware configuration. Account copies of scripts exist in the File Cabinet, but the partner's repository may hold newer or unreleased versions. You want the repository.
Ask for integration credentials and endpoint details to be handed over through a secure channel, then rotate them once the new partner is in place. Collect design documents, test evidence and open defect lists. Our post on NetSuite support handover documentation that people can use sets out what good documentation contains.
Once access and ownership are under control, give notice in writing, as your contract requires. Be factual. List what you need from them during the transition: the repository, documentation, credentials, open defects and a named contact for the overlap. Ask them to confirm each item with a date.
Most partners handle this professionally, and a calm tone makes it easier. Keep a record of what was requested and received. If something is missing at the end of the overlap, you will know exactly what to chase, and your new partner will know which parts of the account are undocumented.
Tell your own users too. They need to know where to raise tickets from a given date and who to call on a month-end evening.
Use the same discipline you would for a new implementation. Ask how they would assess an inherited account, who would do it and what they would deliver at the end. Request a sample assessment report. The questions in NetSuite partner questions to ask before signing the SOW apply here as well, especially those about named people and acceptance.
Be wary of a new partner who recommends a rebuild before seeing the account. Sometimes a rebuild is right. It should come out of an assessment rather than a sales call.
A hypothetical Ohio distributor runs NetSuite with an EDI integration, a custom pricing script and a 3PL connection. Support response has slipped and a pricing defect has been open for ten weeks. The details below are illustrative.
| Week | Activity | Evidence |
|---|---|---|
| 1 | Two internal admins confirmed; ownership search finds 23 scripts, 6 workflows and 3 integration users tied to partner employees | Ownership list signed by the controller |
| 2 | Source repository, credentials and open defect list received | Repository access confirmed; credentials stored in the company vault |
| 3 | New partner reviews account and reproduces the pricing defect | Assessment report with risks ranked |
| 4 | Scripts and integrations reassigned to company-owned users; credentials rotated | EDI, 3PL and pricing tested after each change |
| 5 to 6 | Overlap: outgoing partner answers questions; new partner handles new tickets | Handover log of open items |
| 7 | Outgoing access removed | All jobs ran successfully for two weeks |
The distributor defines the new partner's first outcome as "the pricing defect fixed and verified on 50 sample orders". That gives both sides an early, testable result.
An overlap lets you ask the outgoing partner questions while the new partner learns the account. Keep it short and specific: who handles new tickets, who answers questions about past work, and how both partners record what they hand over. Agree any fee for the outgoing partner's time in writing.
End the overlap when every item on the ownership list has been moved and has run successfully for an agreed period. Then remove the outgoing partner's access and confirm their employee records are inactive.
A first outcome gives the new relationship a test. Pick something that matters and can be verified, such as a long-open defect, a failing integration or a month-end bottleneck. Agree the acceptance criteria before work starts.
If the inherited account is in poor shape, treat it as a rescue. The approach in NetSuite implementation rescue in Singapore works the same way for US accounts. It also helps to agree a commercial model early. Our explanation of outcome-based NetSuite pricing shows how a fixed fee for a defined result can replace an open-ended support bank.
Before you remove the outgoing partner's access, check each of these:
Our NetSuite managed support includes a structured intake for inherited accounts, and our page for US companies on NetSuite describes how we work with US teams. If you are deciding which work to keep in-house during the change, see NetSuite Partner Support and Internal Administration Responsibilities.
Related reading: Why Knowledge Transfer Is Critical to Long-Term Application Support
Usually, subject to your agreement's notice and termination terms. Read them before you start and plan the timing around renewals.
They can, if scripts or integrations run under partner-owned users. Reassign and test each item before access is removed.
Check your contract. Many agreements give the customer ownership of deliverables, but you still need the files handed over.
It depends on account complexity. A planned handover with a short overlap often takes several weeks.
Only if an assessment shows it is needed. Start with a defined fix and decide on larger changes with evidence.