Discover the best NetSuite Implementation Approach for your business. Evaluate and compare options to find your tailored solution in Australia.
The way an ERP implementation is run matters at least as much as which system you chose. The same software, delivered two different ways, produces two different outcomes, and the choice of approach is usually made by default rather than deliberately.
This article sets out the main approaches, what each is actually good for, where each fails, and how to work out which fits your business. There is no universally correct answer, and there are answers that are clearly wrong for particular situations.
The starting point for many NetSuite projects is a preconfigured baseline, built around leading practice for a business type, which you adopt and then adjust.
The logic is sound. Most businesses of a given type need broadly the same things, and starting from something that already works is faster than starting from nothing.
The benefit is speed and predictability. Timelines are shorter, costs are more contained, and the configuration decisions have already been made by people who have made them many times.
The cost is fit. Where your business genuinely differs from the model, you either change your process or you customise, and the second option erodes the advantage you started with.
It suits businesses whose processes are fairly conventional, who are willing to adapt, and who value a defined timeline over a bespoke result.
The conventional method runs discovery, then design, then build, then test, then train, then go live, in sequence, with defined sign offs between phases.
Its strength is thoroughness. Requirements are understood before anything is built, decisions are documented, and there is a clear record of what was agreed.
Its weakness is the feedback delay. People sign off on a design document describing a system they have never used, and discover what they actually needed during testing, at which point changing it is expensive.
It also concentrates risk at the end. Everything arrives at once, and if the design was wrong the discovery happens late.
It suits complex businesses with genuinely unusual requirements, regulated environments where documentation is required, and organisations that need certainty about scope before committing.
An iterative approach builds in short cycles, showing working configuration to the business frequently and adjusting based on what they say.
The benefit is that feedback arrives early, when changing something is cheap, and that people react to a working system rather than to a description of one.
The cost is that scope is harder to fix, budgets are harder to predict, and the approach depends on genuine business availability throughout rather than at defined points.
It also requires discipline. Iteration without a defined end becomes a project that never finishes, and the failure mode is a system that is continuously improved and never used.
It suits businesses with engaged internal stakeholders, uncertain requirements, and a tolerance for a less precise upfront number.
Separate from how you build is how you go live, and the two decisions are frequently conflated.
A big bang cutover moves everything at once. It is cleaner conceptually, there is no period of running two systems, and the pain is concentrated into a short window.
A phased rollout moves functions or entities in sequence. Risk is lower per event, the team learns from each phase, and problems affect a smaller population.
The cost of phasing is that you run two systems for a period, which means interfaces between them, reconciliation between them, and a team supporting both.
That temporary complexity is genuinely difficult and it is routinely underestimated. Where the phases are short and few, it is worth it. Where the rollout stretches over a year, the interim state becomes its own project.
For groups, there is a third dimension, which is whether to move entities one at a time or all together.
Entity by entity lets you prove the model in one place before repeating it, which materially reduces risk and lets the second entity benefit from the first one's lessons.
It also delays the consolidation benefit, since group reporting only works properly once everybody is on the platform, and that is frequently the main reason for the project.
The usual compromise is to start with an entity that is representative rather than easy, since proving the model on the simplest entity proves very little.
And to keep the gap between entities short, because a group half on the new system and half on the old carries the interim complexity for as long as the gap lasts.
Underneath all of these choices is one question that determines more than any other, which is how much your processes should change.
Businesses that treat the implementation as an opportunity to redesign how they work get more out of it, and the project is harder, longer and more disruptive.
Businesses that replicate their existing processes in a new system get a faster project and, frequently, a system that carries forward every inefficiency the old one had.
Neither is wrong. The mistake is not deciding, because a project without an explicit position on this defaults to replication, since replication is what everybody asks for when asked what they need.
Deciding early also determines the approach. Redesign favours iteration and phasing. Replication favours preconfiguration and a shorter timeline.
Data is the most consistently underestimated part of any implementation and it constrains the approach more than people expect.
How much history you migrate is a decision with real consequences. More history means more effort, more cleansing and more reconciliation, and it is frequently justified by a reporting requirement that could be met by keeping the old system available in read only form.
Master data quality determines the timeline more than transaction volume does. Customers, suppliers and items with years of accumulated duplication and inconsistency take real time to sort out.
And the cleansing has to be done by people who know the business, not by the implementation partner, which means it competes with everything else those people do.
A phased approach spreads that load, which is frequently the deciding argument for businesses with messy legacy data. Our data migration checklist covers this in detail.
The approach you can actually run depends on how much of your people's time you can genuinely protect.
Iterative approaches need continuous availability from the people who understand the processes, and those are usually the busiest people in the business.
Phased approaches spread the load over a longer period, which suits businesses that cannot free anybody for an intense block.
Preconfigured approaches need the least internal time, which is precisely why they appeal to businesses without capacity, and also why they produce the least tailored result.
Being honest about this at the start prevents the most common project failure, which is a plan that assumed availability nobody could actually provide.
The approaches differ in what they cost and, more usefully, in how predictable that cost is.
A preconfigured approach produces the most predictable number, because the scope is largely defined by the baseline and the variation is limited to what you change.
A traditional phased approach produces a firm number after design and a soft one before it, which is why the honest partners quote design separately and the rest quote a total that moves.
An iterative approach is the hardest to price and the most likely to deliver what you actually needed, which is a genuine trade off rather than a flaw.
The cost most affected by the choice is not the partner's fee but your own internal effort, which is largest for iterative and smallest for preconfigured, and which almost never appears in the comparison.
The calendar constrains the choice in ways that are easy to overlook until they bite.
Start of financial year cutovers are administratively cleaner, particularly for payroll and for anything with year to date balances.
Period end is the worst possible time for a go live, and yet projects routinely land there because the original timeline slipped and nobody re examined the date.
Peak trading periods should be avoided for obvious reasons, and the definition of peak differs by business in ways an implementation partner may not know unless told.
And the availability of key people matters. A go live scheduled while the person who understands your costing is on leave is a decision somebody made without thinking.
Different approaches need different testing and applying the wrong pattern wastes effort.
A phased build with a big bang cutover needs heavy integrated testing, because everything meets for the first time at the end and that is the only opportunity to find the interactions.
An iterative build tests continuously, and still needs an integrated pass, because components tested individually can fail together.
A phased rollout needs the interim state tested explicitly, including the interfaces between the new system and whatever is still running, which is the part most often skipped.
In all cases, testing with real data and real users beats testing with prepared scripts, because prepared scripts only find the problems somebody already anticipated.
Some failures are independent of approach and worth guarding against regardless.
Training compressed into the final weeks, because it is scoped inside the project rather than separately protected, and it absorbs the slippage from everything upstream.
The dimensional structure decided quickly, because it seems administrative, when it actually determines what the business can report on for the life of the system.
Customisation accepted rather than challenged, so that a system which would have upgraded cleanly becomes one that requires attention twice a year.
And go live treated as the finish, so that the improvement work which produces most of the return never happens.
In practice very few projects are purely one approach, and the useful skill is combining them deliberately rather than by accident.
A common and effective shape is a preconfigured baseline, adjusted iteratively during design with frequent business review, delivered as a big bang for a single entity or phased across entities.
Another is a phased build for the complex areas and a preconfigured approach for the conventional ones, since not every part of a business needs the same treatment.
What matters is that the combination is chosen rather than drifted into, and that everybody understands which parts are fixed and which are still open.
Projects that drift between approaches without saying so are where scope disputes originate.
The last question is the one most often left unanswered, and projects without a named and resourced internal owner struggle regardless of which approach they use.
The right approach follows from the answers above rather than from a general preference, and the exercise of answering them is more valuable than the label you end up with.
If your processes are conventional, your capacity is limited and your timeline matters, a preconfigured approach with a single cutover is usually right.
If your requirements are genuinely unusual, your data is messy and you have engaged people available, a more iterative and phased approach will produce a better result and take longer.
Our pieces on the implementation journey and implementation timelines cover what each looks like in practice, and partnering and planning covers the two decisions that sit above this one.
If you would like help choosing the approach for your own project, get in touch.
