Discover powerful post implementation strategies to unlock the full potential of your NetSuite investment. Read TBS's expert guide now!
Go live is where most NetSuite projects stop being managed, and it is where the value actually starts. The system is configured, the data is in, the people are trained, and the project team disbands. What happens next determines whether the investment returns anything.
The pattern we see is consistent. Organisations that treat go live as the finish line get a system that does roughly what the old one did, more expensively. Organisations that treat it as the starting line compound value for years.
This article covers what to do in the months and years after go live, in what order, and what separates the businesses that get a return from those that do not.
Resist the temptation to improve anything immediately. The first quarter after go live has one job, which is to get the system running reliably and the people using it confidently.
Expect a period where things take longer than they used to. That is normal and it is not evidence that the implementation failed. People are learning, exceptions are appearing for the first time, and the process is being tested against reality rather than against a test script.
What matters is triaging quickly. Distinguish between a configuration problem, a data problem and a training problem, because they need different responses and conflating them wastes effort.
Keep a log of everything raised, even the small things. The pattern in that log is the most useful planning input you will have for the following year, and organisations that do not keep one end up guessing at what to fix.
The first month end is the real test and it deserves to be treated as an event rather than a routine.
Plan it in advance. Walk through the sequence, identify who does what, and make sure the people involved have done it in the sandbox before doing it for real.
Expect it to take longer than it eventually will. The first close is where the reconciliations that nobody thought about get discovered, and where the opening balances get properly validated for the first time.
Debrief afterwards, honestly. What took longest, what was manual that should not have been, what nobody knew how to do. That list is your automation backlog and it will not be as obvious again as it is in that first week.
Once things are stable, the useful next step is to find out how the system is genuinely being used, which is rarely how it was designed to be used.
Look at where manual journals are being posted, because each one usually indicates a process that is not working as intended.
Look at what people are exporting to spreadsheets, because each export is a report that does not exist or is not trusted.
Look at where approvals are being bypassed or rubber stamped, which tells you the approval design does not match the reality of the business.
Look at which functionality you paid for and nobody uses. That is either a training gap or a scoping error, and it is worth knowing which.
Reporting is usually the least complete part of an implementation, because it is the last thing built and the first thing compressed, and because people do not know what they want until they have live data.
Three months after go live is the right moment to revisit it. The data is real, the questions are concrete, and people have discovered what they actually need rather than what they thought they would.
Build for the audience rather than for completeness. Executives need a small set of measures with trend. Managers need operational lists they can act on. Finance needs the reconciliations and the close support. Different outputs, not one report that serves nobody well.
And build it in the system rather than in a spreadsheet layer, because a report that refreshes is used and a report that has to be rebuilt monthly quietly stops being produced. Our report writing service exists because this is the gap that most consistently survives an implementation.
Every implementation leaves manual work behind, usually because it was descoped to hit a date and never revisited.
The candidates are recognisable. Journals that are the same every period. Data that gets rekeyed between screens. Reconciliations that follow a rule a person applies by hand. Approvals routed by email rather than by workflow.
Work through them in order of hours saved rather than in order of technical interest. The unglamorous one that takes somebody four hours every month is worth more than the sophisticated one that saves an hour a quarter.
And prefer configuration and workflow over scripting where either will do, because configuration survives releases and upgrades with less attention than code does.
The dimensional structure decided during implementation was set before anybody had used the system, which means it is usually approximately right rather than right.
After two or three quarters of real reporting, the gaps become obvious. A department structure that does not match how the business is actually managed. A class dimension that was set up and never populated. A missing dimension that would answer the question everybody keeps asking.
Changing this is easier earlier than later, because the volume of historical transactions carrying the old structure only grows.
It is also one of the highest value changes available, since the dimensional model determines the entire universe of questions the system can answer without a special exercise.
NetSuite releases twice a year and organisations respond in one of two ways. Either they ignore it and occasionally get surprised, or they treat it as a routine with a small standing effort.
The routine is not large. Read the release notes for the areas you use. Test your customisations and integrations in the release preview account. Identify the new functionality that is relevant and decide whether to adopt it.
The last part is where the value is and it is the part most often skipped. Functionality arrives that would replace a customisation you are maintaining, or solve a problem you have been working around, and nobody notices because nobody read the notes.
Assign it to someone as a defined responsibility twice a year. Two days of effort prevents the drift that otherwise turns a current system into a legacy one.
The training delivered before go live addressed the people present then, on the processes as designed then, at a point when nobody had context for it.
Refresher training three to six months after go live lands very differently, because people now have real questions and real frustrations, and an hour spent then is worth several spent before.
New starters need something more structured than sitting next to somebody. Where onboarding is informal, each new person inherits the previous person's workarounds, and the organisation's competence degrades quietly.
And each significant change needs its own training, delivered to the people affected. Our training service is built around this ongoing rhythm rather than one off delivery.
The single largest determinant of your cost of ownership over a decade is whether you have somebody internal who understands the system.
That person does not need to be a developer. They need to understand your configuration, be able to make routine changes safely, build a saved search, add a field, adjust a workflow, and know enough to judge when something needs outside help.
Where that capability exists, small changes happen in days rather than being batched into a quarterly engagement, and the business stops experiencing the system as fixed.
Where it does not, every request goes outside, small improvements are not worth the administrative overhead, and the system slowly stops fitting the business. Our guidance for system administrators covers what the role needs to cover.
Customisations accumulate. Each one was justified individually and collectively they become the largest constraint on your ability to change anything.
Keep a register of what exists, what it does, why it was built and who asked for it. Most organisations cannot produce this after two years, which is itself the problem.
Review it annually against two questions. Is this still needed, since business processes change and some customisations outlive their purpose. And has standard functionality caught up, since NetSuite adds capability twice a year and some customisations become redundant.
Retiring a customisation is one of the few changes that reduces ongoing cost permanently, and it is almost never on anybody's list.
Most implementations cover finance thoroughly and adjacent operational processes lightly, which is a reasonable scoping decision and leaves value on the table.
The natural extensions depend on the business. Procurement and approvals for businesses with meaningful spend. Project costing for services businesses. Inventory depth for anybody holding stock. Payroll onto the platform for businesses tired of reconciling it.
Each of these is a smaller project than the original implementation, because the foundation, the security model and the reporting layer already exist.
Sequence them by the size of the manual burden they remove rather than by the enthusiasm of whoever is asking, and do them one at a time so each is properly embedded before the next.
Somewhere there is a business case that justified the investment, and it is worth returning to it rather than leaving it as a procurement artefact.
Which benefits have been realised. Which have not, and why. Which turned out to be irrelevant because the business changed.
This is uncomfortable when the answer is mixed, which it usually is, and it is the most useful planning exercise available, because it distinguishes between benefits that need more work and benefits that were never achievable.
It also protects the next investment. A business that can show what it got from the last system change has a much easier conversation about the next one.
Systems degrade in fit rather than in function, and the signals are recognisable well before it becomes a problem.
Spreadsheets reappearing around the edges, doing things the system was supposed to do.
Manual journal volume rising over time rather than falling.
People asking for reports rather than producing them, which usually means the reporting no longer matches how the business is managed.
Process documentation that no longer describes what people do.
And nobody able to explain why a particular configuration exists, which means the institutional knowledge has left.
Each of these is fixable when caught early and expensive when left, which is the argument for a periodic health check rather than waiting for a crisis.
The support relationship after go live matters more than most organisations expect, and the shape of it varies.
Reactive support answers questions and fixes problems. Every business needs it and it is not sufficient on its own, because it only ever addresses what somebody noticed.
Proactive support brings the release cycle, the health checks and the improvement suggestions, which is the part that prevents drift.
Continuity matters. Support from people who know why your system was built the way it was is materially better than support from people reading your configuration for the first time each time.
And the commercial structure should not discourage you from asking. Arrangements where every question feels expensive produce businesses that stop asking, which is the opposite of what support is for. Our support and managed services arrangements are built around that distinction.
Rather than a programme, the practical answer is a modest recurring cadence that fits alongside normal work.
Monthly, review the issue log and the manual journal volume, and pick one thing to fix.
Quarterly, review the improvement backlog, deliver the highest value item, and refresh training on whatever changed.
Twice a year, work the release cycle properly, testing customisations and assessing new functionality.
Annually, review the customisation register, revisit the business case, and run a health check against the drift signals above.
That is a few days a quarter, and it is the difference between a system that improves and one that slowly stops fitting.
The organisations that get the most from NetSuite are not the ones with the largest implementations. They are the ones that kept going afterwards, in small increments, with somebody accountable for it.
If your implementation is complete and nothing has changed since, the highest value thing you can do is find out how the system is actually being used and fix the largest source of manual work.
Our pieces on advanced modules worth considering after go live and features you probably are not using cover specific opportunities, and the signs that a reimplementation is warranted covers what happens when drift has gone too far.
If you would like a review of where your NetSuite investment currently stands, get in touch.
