You didn't build this instance. Someone else did, over years, and they are not in the room to explain it. That's the actual job description for most new NetSuite admins: not building, inheriting.
Think of it like buying a house sight unseen. The listing photos show a clean kitchen and a finished basement. What you actually own is whatever is behind the walls: the wiring nobody re-permitted, the load-bearing beam someone "simplified," the room that's locked because nobody kept the key. You find out what you own by inspecting it, not by trusting the listing.
Get access before you get curious
Confirm your administrator role actually has what it needs: full access to scripts, workflows, saved searches, and the deployment records that show what's live versus retired. A surprising number of handoffs leave the new admin with a role that looks like Administrator but is missing a permission somewhere, usually one nobody notices until a script they can't see fails silently.
Don't fix anything yet. You can't tell a genuine bug from an intentional, load-bearing workaround until you've seen the whole house. A "broken" workflow might be the only thing keeping a downstream integration from double-posting.
Take inventory
An inventory is not a summary. It's a full room-by-room walkthrough: every custom record type, every script and its deployments, every workflow, every saved search that feeds a dashboard or a scheduled email, every role, every integration. You are not judging any of it yet. You're just writing down what's actually in the house.
This step is where most handoffs fail. Don't skim the account and work from that impression for the next two years, be intentional about getting a full understanding. The impression is never the whole house.
Find out what's load-bearing
Deployed does not mean alive. Check the Script Execution Log and Scheduled Script Status for real, recent activity instead of trusting a script's deployment status on its own. A script can sit deployed and untouched for years. A saved search can look abandoned while a workflow depends on it every night.
The question that matters isn't "what does this do." It's "what happens if I remove it." Those are different questions, and only the second one tells you what's load-bearing.
Look for the rooms with no owner
Every inherited instance has a few customizations nobody can explain: built by an agency that's gone, a developer who left, a consultant engagement that ended. They keep running because nothing has broken yet, not because anyone understands them.
- Check the script and record notes fields. Even a sparse comment from three years ago is a real clue.
- Check who last modified each customization, and whether that person still has an account.
- Check bundle installations for third-party code you didn't know was there.
An orphaned customization isn't automatically a problem. It's a fact you didn't have yesterday. Write it down and move on.
Set a baseline before you change anything
Once you have the inventory, the next task is establishing what "normal" looks like right now, today, before your first change. Record what runs, when, and roughly how often it fails already. This is the only way to answer the question you'll get asked in a month: did my change break that, or was it already broken?
Without a baseline, every failure after your first week looks like your fault. With one, you can point to the exact log entry that shows the problem predates you.
Related guides
- Finding unused scripts and technical debt in NetSuite
- Diagnosing NetSuite script and integration failures
- SuiteScript deprecation: the NetSuite timeline every admin needs
See the whole house, documented.
Turbobase inventories every script, workflow, and customization in your NetSuite environment and explains what each one does, so the inventory that normally takes weeks takes hours. You approve everything; it just does the walkthrough.
Frequently asked questions
What's the first thing to do when you inherit a NetSuite instance?
Get administrator access confirmed, then get a full inventory of what exists before you change anything: custom records, scripts, workflows, saved searches, roles, and integrations. You cannot tell what's safe to touch until you know what's there.
How do I find out what's actually running versus what's just sitting in the account?
Check the Script Execution Log and Scheduled Script Status for real, recent activity rather than trusting a script's deployment status alone. A script can be deployed and still be effectively dead, and a saved search can look unused while a workflow depends on it silently.
How long should a NetSuite handoff audit take?
It depends on the instance's age and customization depth, but the goal is a baseline, not perfection: enough of an inventory that you can tell, a month from now, whether something broke because of your change or was already broken. That's achievable in days for most instances, not months.
What if the person who built the instance is gone and there's no documentation?
Treat the instance itself as the documentation. Scripts, workflows, and saved searches all carry names, notes, and execution history you can read even without the person who wrote them. It's slower than a handoff document, but it's a real source, not a guess.