Step into the world of NetSuite with our step-by-step guide on its implementation. Learn how to streamline your business operations effectively.
Every NetSuite implementation follows roughly the same sequence, and knowing the sequence is not the same as knowing what actually happens at each stage. The phase names are published everywhere. What is less commonly written down is where the effort really lands, which decisions are irreversible, and what your business has to supply rather than receive.
This article walks through the journey from the perspective of the business rather than the partner, because your side of the project is the half that determines whether it works and the half that is usually planned least carefully.
The most consequential work happens before anybody signs anything, and it is work only you can do.
Be specific about what you want the system to make possible that is impossible now. Better visibility is not a requirement. Knowing margin by customer within three days of month end is a requirement, and it is testable at the end.
Decide whether you intend to redesign your processes or replicate them, because that single decision drives the approach, the timeline, the budget and the amount of change management required. A project without an explicit position on this defaults to replication, since replication is what everybody describes when asked what they need.
And work out honestly how much of your key people's time is genuinely available. Not how much you would like to give, how much you can actually free by taking something else off them. Projects built on capacity that was never real are the most common failure we see.
Partner selection deserves more scrutiny than software selection, because the platforms are all capable and the delivery varies enormously.
Ask who specifically will be on your project, how much of their time, and what they have done before. Proposals that name senior people who then appear only at steering meetings are common enough to be worth naming as a concern up front.
Ask what they would expect to be hardest about your project. A partner who has understood your business will have a view. One who has not will answer generically.
And ask about a project that went badly. Experienced partners answer readily and specifically, and the answer tells you how they behave under pressure, which is what you are actually buying.
Discovery is where the partner learns your business, and its quality determines everything downstream.
Expect to spend real time in it. The people who should be in the room are the ones who do the work daily rather than the ones who manage it, because managers describe the process as it is supposed to run and the exceptions are where the design decisions live.
A good discovery surfaces the things nobody thought to mention. The customer who is invoiced differently for historical reasons. The approval that technically exists and never happens. The report somebody builds manually every month that nobody has ever mentioned.
What it should produce is a documented understanding of current state, an agreed view of what changes, and an explicit list of what is out of scope. That last item prevents most of the arguments that occur later.
Design is the phase that most determines whether the system fits, and it is the one businesses most often rush because it produces no visible software.
The dimensional structure is the single most important decision, and it looks administrative. Subsidiary, department, class and location determine the entire universe of questions the system can answer without a special exercise, for the life of the system, and changing it later means recoding history.
The chart of accounts matters similarly. Too granular and everybody codes things inconsistently. Too coarse and the reporting cannot answer anything. The right level is the level at which somebody actually makes decisions.
Approval design should reflect how decisions genuinely get made rather than how an organisation chart suggests they should. Where the two differ, the system gets bypassed within a month and the audit trail becomes fiction.
Configuration is where the partner does most of their visible work and where your involvement drops, which makes it the phase where problems become invisible.
Ask to see working configuration regularly rather than waiting for a formal demonstration. People react usefully to something they can click through and abstractly to a document describing it.
Where customisation is proposed, ask what problem it solves and whether configuration would do. Every script is a permanent obligation, tested twice a year against releases and eventually explained to somebody who was not there.
And keep the decision log current. In six months somebody will ask why a field is set the way it is, and the answer being written down is the difference between a two minute conversation and a two day investigation.
Data is the most consistently underestimated part of any implementation and the most common cause of a moved go live date.
Decide how much history you actually need, and challenge the first answer. More history means more effort, more cleansing and more reconciliation, and the requirement is frequently satisfied by keeping the old system available in read only form for a period.
Master data cleansing is business work rather than partner work. Deciding whether two customer records are the same customer requires knowing the business, and no external party can do it for you.
Allow real time for reconciliation after loading. Data that loaded without errors is not the same as data that is correct, and the difference is discovered by checking rather than by assuming. Our data migration checklist covers the detail.
Most businesses have systems that will remain after go live, and the connections between them need designing rather than assuming.
Establish early what talks to what, in which direction, how often, and what happens when one side is unavailable. That last question is the one most often skipped and the one that causes the most trouble later.
Decide what the source of truth is for each shared record. Where two systems can both create a customer, they will diverge, and reconciling them becomes somebody's permanent job.
And be honest about ongoing ownership. Integrations fail, they fail quietly, and somebody has to notice. A connection with no named owner is a future incident.
Testing is where the business does its most valuable work in the project, and it is frequently treated as a formality.
Test with real data and real people rather than with prepared scripts, because prepared scripts only find the problems somebody already anticipated.
Test end to end rather than by module, since the interesting failures happen at handoffs. A sales order that works and a fulfilment that works can still fail together.
Test the exceptions deliberately. The credit note, the partial delivery, the customer with unusual terms, the transaction that spans period end. Routine transactions rarely reveal anything.
And test with the permissions people will actually have, because a process that works as an administrator can fail entirely for the person who has to run it.
Training is scoped inside most projects and therefore absorbs the slippage from everything upstream, which is why it so reliably ends up crammed into the final fortnight.
Give it separate dates and a separate budget so it cannot be quietly consumed.
Build it around processes rather than modules, so that it maps onto what somebody actually does rather than onto how the software is divided.
Schedule it against first use rather than against go live. Core daily processes belong immediately before cutover. Month end belongs before the first month end. Year end belongs many months later, and it is the training most often skipped entirely.
Our training service is built around this rather than around a block of sessions.
Cutover is a short window with a lot happening and it rewards planning in a way few other phases do.
Write the sequence down hour by hour, including who does what, what has to finish before the next thing starts, and who confirms each step.
Decide the point of no return explicitly, and decide in advance what would cause you to roll back. Making that decision under pressure at two in the morning is how bad calls get made.
Freeze changes in the legacy system at a defined time, and communicate that widely, because somebody entering a transaction after the extract creates a discrepancy nobody finds for weeks.
And plan the first working day as carefully as the cutover itself, because that is when the volume of questions peaks.
The period immediately after go live sets the attitude that persists for years, and it is routinely under supported.
People need help within minutes rather than within days. A question unanswered for two days gets solved with a workaround, and that workaround becomes permanent.
Have experienced people available in the working area, physically or virtually, rather than behind a ticketing system. The questions people will not raise formally are frequently the important ones.
Expect a productivity dip and say so in advance, because a dip people were warned about is normal and a dip they were not warned about reads as evidence the system does not work.
And triage quickly, distinguishing configuration problems from training gaps, since conflating them wastes effort in both directions.
The first close is the real test of an implementation and it deserves to be treated as an event rather than as routine.
Plan it in advance, walk through the sequence, and make sure the people involved have done it in the sandbox rather than reading about it.
Expect it to take longer than it eventually will. The first close is where the reconciliations nobody thought about get discovered and where the opening balances get genuinely validated for the first time.
Have the partner available during it rather than on call, because the questions are urgent and specific.
And debrief honestly afterwards. What took longest, what was manual that should not have been, what nobody knew how to do. That list is the most useful improvement backlog you will ever have and it will never be this clear again.
The temptation after go live is to start improving immediately, and the first quarter has a different job.
Get the system running reliably and the people using it confidently before changing anything that is not broken.
Keep a log of everything raised, including the small things, because the pattern in that log is the best planning input available for the following year.
Resist scope that was deferred creeping back in during this period, since a business still learning the system is not well placed to absorb more of it.
Three months is a reasonable point to shift from stabilisation to improvement, and the shift should be deliberate rather than gradual.
Partners get blamed for a lot of project failures and a meaningful proportion originate on the client side, in ways that are entirely fixable.
A named internal owner with real authority and real time, rather than a title given to somebody already at capacity.
Decisions made when they are asked for, since projects stall on decisions far more often than on work.
Availability of the people who understand the processes, protected rather than assumed.
And honesty about the awkward parts of the business, because the exception nobody mentioned during discovery is the one that surfaces during testing at the worst possible time.
Problems are visible earlier than they are usually acknowledged, and the signals are consistent.
Status reporting that stays green while the team is visibly under pressure.
Decisions being deferred rather than made, with the deferred list growing week on week.
Testing that keeps being rescheduled, which is almost always because the configuration is not ready and nobody wants to say so.
Data migration that has not started in earnest by the midpoint of the project.
And a training plan that has no dates. Any one of these warrants a direct conversation rather than a note in the risk register.
The journey is more predictable than it looks, and almost all of the variation comes from decisions made in the first two phases and from how much internal capacity was genuinely protected.
If you are at the beginning, spend your effort on being specific about what you want the system to make possible, deciding how much your processes should change, and working out what your people can actually give.
If you are already underway and something feels wrong, the signals above are worth checking honestly, because these problems are considerably cheaper to fix in week eight than in week twenty four.
Our pieces on partnering and planning and implementation timelines cover the two decisions and the shape of the schedule, and whether your implementation needs rescuing covers what to do when it has already gone wrong.
If you would like to talk through your own project, get in touch.
