Best Practice

Anatomy of a NetSuite rescue: the first ten days

Chandramohan "MS" Sharma · Principal18 July 2026SuiteGyan Insights

You have inherited a NetSuite account. Maybe the implementation partner has gone, maybe the person who understood it has left, and maybe something is already failing at month-end. The pressure is to start fixing. The most valuable thing you can do in the first ten days is not fix anything.

A rescue that begins with repairs is how you turn one problem into three. You are changing a system you do not yet understand, on top of decisions you cannot yet see. The first stretch of a rescue is forensic, not remedial. Here is the sequence I run, and why each step earns its place before a single fix goes in.

The account is the source of truth, not the handover

The first rule is uncomfortable: do not trust the documentation you were given. Not because anyone lied, but because documents drift from reality the moment they are written and nobody updates them after. Worse, I have audited an account where the versioned source showed a workflow with no record-locking and passed it as clean, then found the real behaviour only by checking the live system: a lock step had been added by hand in the interface and never written back to the source. The source-only view gave a false all-clear on the exact control that mattered. So the audit runs against the account, not the paperwork. Where the two disagree, the account wins, every time.

Reconstruct before you remediate

Before fixing, you rebuild the map. I run a reduced version of the delivery pipeline for this: frame the scope, analyse the current state, and document it, using the deployed code and configuration as the source of truth. The design and build stages are skipped, because you are not building anything yet, you are recording what exists. The output is a reconstructed documentation pack issued at a fresh version one. Not a revision of the stale pack you inherited, which carries errors you cannot yet tell apart from fact. A clean baseline that says: this is what the account contains, verified against the live system, as of today.

Separate finding from fixing

You will find broken things during reconstruction. The discipline is to write them down, not fix them. Every defect goes into a separate remediation register: what it is, where, how bad, and how sure you are. Nothing gets repaired on sight. This is the step people skip, and it is the one that keeps a rescue from becoming a second incident. A fix applied mid-discovery, before you understand the dependencies around it, is how you break the close while mending a script. Discovery and remediation are two phases, and the register is the wall between them.

Decide rebuild or patch, per component

Only once the estate is mapped and the defects catalogued do you decide what to do with each. Some components are worth patching in place. Some are cheaper and safer to rebuild than to keep repairing. That call is made per component, against risk and cost, not as a blanket policy. A small, well-understood defect gets a patch. A tangle nobody can safely modify gets rebuilt to a standard. Sequencing follows risk, not noise: the thing most likely to fail at the next close comes before the thing that merely offends good taste.

What the first ten days actually buy

At the end of the forensic stretch you do not have fixes. You have something more valuable: a documented estate at a clean baseline, a prioritised register of everything wrong, and a decision on each item. You have turned an opaque account you were afraid to touch into a known system with a plan. That is the point of going slowly at the start. The first ten days buy the right to change things safely. Every rescue that skipped them spent the time later, at a worse moment, with an audience.

If you have inherited an account you cannot fully explain, the NetSuite Estate Health Check is the compressed version of exactly this forensic sequence: a fixed-fee, five-day review that hands you the map and the prioritised register before anything is touched.