NetSuite Go-Live:
What Actually Goes Wrong (Documented From a Real Implementation)

The Timeline — Day by Day

A NetSuite admin posted their go-live experience on Reddit recently. It's worth reading in full if you haven't — not because it's unusual, but because it documents so precisely what most post-implementation retrospectives quietly bury. The timeline below is a close summary. The words in quotes are theirs.

With 8 days of ERP-side post-go-live support remaining, and FSM support now expired, they are still missing features that were working correctly in sandbox.

The post ends with: "Wish us luck."

Five Failure Modes This Story Reveals

If you've worked in NetSuite implementation for any length of time, you won't be surprised by this story. You'll recognise it. The specific failures here are not random — they are the same failures that appear in almost every large partner-led go-live that goes badly. Understanding them structurally is how you avoid them.

1. The Sandbox-to-Production Transfer Is Almost Never What You Think

All dev work done in sandbox, production sitting vanilla until migration day — this is the most common implementation pattern for large NetSuite deployments, and it is the single biggest source of go-live disasters.

Sandbox and production are not identical environments. Account-specific configurations, bundle versions, feature flags, role permissions, and SuiteApp states diverge over the course of an implementation. A "stare and compare" done by an implementation partner who is under deadline pressure, working across dozens of concurrent engagements, and reading from a checklist rather than testing against real usage scenarios will miss things. Not occasionally — routinely.

In this case, the corruption event at T−15 meant the production environment was rebuilt from scratch at T−9 and declared matching. It wasn't. The admin who actually uses the system found the differences in two days that a professional implementation team missed entirely. That delta — between what a checklist approves and what a real user discovers — is where go-live disasters live.

2. Data Migration Validation Was Not Done

Three thousand parts imported without prices. All items missing the "show in field service" flag. The items list capped at 500 for a business with 3,000+ parts.

None of these are edge cases. They are the exact things a data migration validation checklist is supposed to catch. Prices, item flags, and record counts are row-one items on any serious validation run. The fact that all three were missed is not a sign of bad luck — it is a sign that post-migration validation was either not done or was not done by anyone who understood how the data would actually be used.

The "null cost items won't post" bug is particularly painful. This isn't a complex edge case — it's a hard constraint baked into how FSM processes parts usage. Anyone who has worked with FSM knows this. The fix (setting prices to zero temporarily) is a workaround, not a resolution. The underlying issue is that no one with domain knowledge reviewed the imported dataset before go-live.

3. The Implementation Team Did Not Own the System

Read through that timeline and notice who is actually doing the work: the admin. Not the NetSuite team. Not the FSM team. The admin.

The admin rebuilds the customisations over the weekend. The admin runs the map reduce to fix item flags. The admin writes a script to set prices to zero. The admin cleans up the FSM config. The admin rebuilds the project task reassignment script after NetSuite removes theirs. The admin reinstates 5 deleted tabs after support expires.

At every point where the implementation team created a problem, the resolution was handed back to the client. This is not an implementation engagement — it is the client implementing the system with periodic, inconsistent involvement from a vendor who declares the work done.

4. No One Owned the Configuration

The Day 11 event is the clearest example: the FSM team's edits to the work order list view broke FSM mobile, and their rollback to fix it wiped out the morning's work and reinstated broken field references. Then they removed 5 tabs two hours after the support window ended.

This is what happens when configuration changes are made without a review process, without a change log, and without anyone whose job it is to understand the cumulative state of the system before touching it. The config became a shared object that multiple parties were modifying independently, without coordination, under time pressure.

In a well-run engagement, every config change goes through a single point of authority — either the client's admin or a designated consultant — and is tested in a non-production environment first. That didn't happen here at any stage.

5. Support Windows Don't Match Reality

14 days of post-go-live support is standard in most mid-market NetSuite implementation contracts. The logic is: we go live, we handle any immediate issues, support ends.

The problem is that NetSuite FSM implementations are not stable at 14 days post-launch. They're still being used for the first time by people in the field. Edge cases in parts ordering, field technician workflows, work order reassignment, and mobile sync don't surface during a one-week pre-launch smoke test — they surface over the first month of real production load.

The lead rep being on PTO on the last day of support is a symptom of the same structural issue: the timeline is the client's problem, not the implementation team's. The engagement clock runs independently of the client's readiness.

Why This Is a Structural Problem, Not Bad Luck

It's tempting to read this story and conclude that this particular NetSuite partner was incompetent, or that this business was somehow unlucky. Neither is accurate. This pattern repeats because the incentive structures of large ERP implementations produce it reliably.

Large implementation partners are staffed with consultants who work across many concurrent accounts. Knowledge of any individual system is shallow and ephemeral — the consultant who was with you in month one is not the consultant on your go-live call in month six, who is not the new rep chairing your final support meeting. The system is never understood by a single person with full context, because that's not how the engagement is staffed.

The support window model exists because it benefits the partner, not the client. 14 days post-go-live is long enough to handle the obvious fires; it is not long enough to discover everything that was misconfigured. When the window expires, the partner closes the engagement. What the client is left with is whatever state the system is in at that moment — including the five deleted tabs, the broken assignment script, and the 3,000 parts that still can't post.

The "stare and compare completed, environment matches sandbox" sign-off is a checkbox exercise. It protects the partner's documentation, not the client's system. A real environment validation would involve running actual workflows against real data and failing loudly. That takes domain expertise, time, and a willingness to delay go-live — none of which a partner running behind schedule and managing margin is incentivised to do.

This isn't a criticism of NetSuite as a platform. NetSuite is a powerful, mature ERP. When implemented correctly — with a single owner who understands the full system, proper data validation, and support that doesn't evaporate two weeks after launch — it runs extremely well. The product is not the problem.

What a Better Go-Live Actually Looks Like

Our clients don't experience the timeline above. The reason isn't that we're luckier or that their projects are simpler — it's that the structural failure modes described above are avoidable, and avoiding them requires a different approach from day one.

One person owns the system, start to finish

The person who specs the customisations, writes the scripts, configures the roles, and maps the data import is the same person who runs the go-live and handles post-launch issues. There's no knowledge gap between implementation and support because there's no handoff. The context is continuous.

This matters most at go-live. When a bug appears at 11am on launch day, the person fixing it already knows the system — because they built it. They don't need to read documentation, spin up on context, or escalate to a second tier. They already know which script touches which field and what the edge case was when they built it three months ago.

Production is touched early and often

We don't let production sit vanilla until two weeks before go-live. Customisations go into production as they're completed in sandbox — tested, validated, and locked. When you have a working production environment six weeks before launch rather than six days before, the "stare and compare" phase becomes a formality rather than a crisis.

The T−9 scenario described above — rebuilding an entire customisation layer from scratch in a weekend — happens when production is treated as something you migrate to rather than something you build in parallel. We build in parallel.

Data migration is validated against real workflows

Before any import is called done, we run it through the actual workflows that depend on it. For FSM implementations, that means importing a representative subset of items, assigning them to a test work order, sending the work order to a mobile device, and confirming parts usage posts. Not reading a row count. Not checking a schema. Actually running the workflow.

If parts won't post because they're missing prices, that surfaces in a sandbox test at week eight — not on day five of live operations when field technicians have been unable to log parts usage for half a week.

Config changes are reviewed, not unilaterally applied

Any change to a live system goes through a review step before it touches production. If a column needs cleaning up on a work order list, we look at the full config dependency chain for that list before touching it. We test the change in a non-production context if one is available. And we have a rollback path prepared before we apply it.

The Day 11 event — two hours of mobile downtime followed by a two-day config rollback — is a change management failure. It is prevented by a simple rule: don't modify a live config without reviewing what references the fields you're touching.

Support doesn't have a two-week expiry

We work on retainer. When an issue surfaces at day 22 post-launch, the response is the same as at day 2: review the logs, identify the root cause, fix it. There's no support window expiry. There's no PTO conflict on a critical day. There's no new rep attending a meeting with zero context on a system they've never seen before.

NetSuite FSM implementations in particular need ongoing support for at least 60–90 days post-launch. The field use cases that surface in week three are different from the ones that surface in week one. A fixed two-week window assumes all the complexity appears immediately. It doesn't.

Go-Live Readiness Checklist

If you're approaching a NetSuite go-live — whether with a partner, a freelance consultant, or your own internal team — these are the questions that separate a smooth launch from the timeline above.

These aren't hypothetical questions. Every item in that checklist maps directly to a specific failure in the timeline above. If you're working with an implementation partner, ask them these questions before you sign — and ask for documented evidence, not verbal assurances.

Frequently Asked Questions