The go-live moved twice. The consultants have gone quiet, or worse, they’re still emailing but nothing is changing. Nobody in your building can tell you, with confidence, what’s actually configured versus what’s still a promise in a scope document.
Before you can decide whether to restart, replace the vendor, or repair what’s there, you need to know what’s actually there. That’s an inventory problem before it’s a technical one, and most people skip straight to “let’s just start over” because nobody’s done the inventory.
Here’s the order to work in. Don’t skip ahead to the decision until you’ve done the first four.
1. Get access, and get it in writing
Before anything else: does someone on your side have full administrator access to production and every sandbox? Not “can log a ticket with the consultant,” actual admin login.
If the answer is no, that’s the first fix, and it’s not a technical one. Get it from whoever holds it, in writing, today. A stalled implementation where you can’t get into your own account isn’t a technical problem yet. It’s a contract problem, and it should be treated as urgent regardless of what else is going on.
2. Inventory what’s actually built
Not what the SOW says should be built. What’s actually there. Go through:
- Scripts and workflows — what’s deployed, and separately, what’s deployed but not active. A script sitting deployed-but-not-running is easy to mistake for “done.”
- Saved searches and reports — are the ones the business actually needs to close the books or ship an order built, or are they still on a list somewhere?
- Bundles and third-party SuiteApps — what’s installed, and is anything installed that depends on something else that isn’t?
- Custom records and fields — do they match what the design doc describes, or has scope drifted without anyone updating the document?
This step alone usually takes longer than people expect, because “what’s built” and “what the last status update said was built” are frequently two different lists.
A few specific questions cut through that faster than a general audit:
- Was data migration ever its own workstream, or did it get folded into whoever was doing configuration? When migration gets dumped on the same consultants building the module setup, one of two things happens: configuration slips while someone scrambles on data, or migration gets rushed in the final two weeks before go-live and never gets fixed after. Either failure mode leaves fingerprints, and asking this one question often locates the real breakdown faster than asking who’s at fault.
- Was there a second load of master data after the initial batch, or does the account only reflect a snapshot from whenever the first load ran? Anything created in the legacy system after that point, and never carried over, is invisible in NetSuite until someone notices it’s missing.
- If this is a NetSuite-to-NetSuite move, was the old internal ID carried over as the new external ID on migrated records? If not, cross-referencing what’s in the new account against the old one is manual reconciliation instead of a lookup, which is a common reason nobody can say with confidence what matches what.
- Do open sales orders have their related purchase orders, work orders, or customer deposits intact? Those relationships can’t be recreated by a standard CSV import. An open order sitting with no linked PO or deposit when the legacy system shows one should exist is a specific sign of what got skipped under time pressure.
One more question worth asking before you move to step 3, because it changes how you read everything else: is this the first rescue attempt, or has this account already been through this once before? A team on its second or third go-live is not just evaluating technical facts anymore. They’re exhausted and skeptical of any promise or timeline, and that’s a real cost that belongs in the decision in step 6, not just a mood in the room.
3. Check whether the financial foundation is sound
This is the step a lot of technical reviews skip, and it’s the one that decides whether repair is even on the table. If you have a finance background, this is where it pays off; if you don’t, it’s worth having someone who does look at this specifically, separate from the SuiteScript review.
- Is the chart of accounts structured the way the business actually needs to report, or was it built generically and never revisited?
- If this is OneWorld, is the subsidiary structure correct? A wrong subsidiary hierarchy is one of the harder things to unwind after data has started flowing through it, and it usually traces back to one root cause: subsidiary data that was tracked in a field the legacy system never designed to control legal entities. Once you know to check for it, it’s a fast thing to confirm.
- Are opening balances loaded and do they tie out? “We’ll true it up after go-live” is a sentence that should worry you.
- Was opening inventory loaded with a real cost, or at zero? Zero-cost inventory posts zero-dollar COGS on every fulfillment from that point forward, which quietly wrecks gross margin and inventory valuation until someone traces it back.
- Does the AR or AP aging report show a permanent “No Customer” or “No Vendor” line? That’s a specific, visible symptom of journal entries that hit a subledger account without a customer or vendor attached, and it’s exactly the kind of thing that gets waved off as a rounding issue instead of investigated.
- Does retained earnings actually tie between the old system and NetSuite? If it doesn’t, the most common cause is that the legacy chart of accounts had no dedicated retained earnings account, or someone had renamed or repurposed it, so the two systems closed the year to different places. It’s a specific, checkable mismatch, not a mystery.
- Are there open transactions sitting in a state that doesn’t match reality — orders that shipped in the old system but were never closed here, for instance?
If subsidiaries are involved, three constraints are worth checking by name rather than taking on faith: bank and credit card accounts can only belong to a single subsidiary, one subsidiary can’t pay another subsidiary’s vendor bills directly, and intercompany activity has to flow through proper due-to and due-from postings. NetSuite will reject a journal entry that doesn’t balance by legal entity, so if entries were forced to post anyway, something was worked around to make that happen, and it’s worth finding out what.
A configuration with sloppy scripting but a sound financial structure is repairable. A configuration with clean scripting sitting on top of a wrong chart of accounts or the wrong subsidiary model is a different conversation entirely.
The single fastest test of all of this: try to run the first bank reconciliation. If historical financials were loaded, the first bank reconciliation is the closest thing to an honest, mechanical test of whether the migration actually worked, because it either ties to zero or it doesn’t. If it won’t tie, the problem is almost never the reconciliation screen. It’s proof that something upstream in the migration is broken. The usual suspects, in order of how often they turn out to be the cause: uncleared foreign-currency realized gain and loss entries that were never handled correctly, credit card accounts that need reconciling individually but were set up as if a parent-level reconciliation would cover them, a bank feed that was turned on too early and auto-matched things it shouldn’t have, and a summary-level historical load where the clearing entries were never fully worked out. A stalled account that has never once produced a clean bank reconciliation is telling you something specific, not something vague.
4. Reconstruct what was actually promised
Pull the original SOW, the design document if one exists, and the email or project-management history. You’re not looking for who’s at fault. You’re building a single list: what was scoped, what’s delivered, what’s in progress, and what’s just gone quiet.
Cross-reference this against what you found in step 2. The gap between “promised” and “built” is usually smaller than it feels from the inside, and knowing exactly how small (or large) it is changes the decision in step 6.
If there’s a support-ticket or case history with NetSuite itself, pull that too. It often shows what the previous team was actually struggling with in the weeks before they went quiet, which tells you something a status email won’t.
5. Separate “broken,” “unfinished,” and “wrong”
Three different categories, and they call for three different responses:
- Broken — built, but not working. Usually the fastest to fix, because the intent is at least documented in the code or the workflow.
- Unfinished — not built yet, sitting on the original scope. This is just work that hasn’t happened.
- Wrong — built, working as configured, but configured against a misunderstanding of how the business actually operates. This is the expensive category, because it looks done until someone tries to use it.
Most stalled implementations are a mix of all three, and the mix is what determines the next step.
6. Decide: restart, replace, or repair
With steps 1 through 5 done, this decision usually makes itself.
Repair fits when the financial foundation from step 3 is sound and most of what’s wrong falls into “broken” or “unfinished” rather than “wrong.” Bring in someone to finish what was scoped and fix what’s broken. The existing vendor relationship may or may not survive this, but the configuration does.
Replace the vendor, keep the work fits when the configuration itself is largely sound but the relationship is dead — unresponsive, unwilling, or simply not the right fit going forward. You need a new set of hands, not a new NetSuite account.
Restart fits when step 3 turns up a wrong subsidiary structure, a chart of accounts that doesn’t match the business, or when “wrong” is the majority of what you found in step 5. Restarting a NetSuite implementation is expensive and demoralizing, and it’s still cheaper than running a business on a financial structure that was wrong from the foundation up.
If restart is the answer, it helps to know this isn’t a rare or unusual outcome. A NetSuite-to-NetSuite re-implementation, moving from one account into a new one, is a common enough project type that it has its own well-worn migration pattern, not a one-off crisis response.
One thing worth weighing that isn’t purely technical: if this account has already been through a failed or half-finished attempt before, factor in what that history has done to the team, not just to the data. A group on its second or third go-live is going to be skeptical of any new timeline, and rebuilding trust in the process is part of the job, whichever path you choose. Proof and small, verifiable wins matter more than a confident plan at this stage.
None of these decisions should be made from the outside without steps 1 through 5. A rescue quote based only on a demo call and a look at the scope document is a guess, not a diagnosis.
Stalled go-live, and you can’t get a straight answer about the account’s real state? We’ve been doing this since 2003, and the first thing we do is exactly the inventory above, not a sales pitch for a rebuild. Get in touch and send us what you have. We’ll tell you what we actually see.