Preparing for Your NetSuite Implementation from Day One - A Step-by-Step Project Timeline for a Successful ERP Software Selection Process
Most advice about NetSuite implementations begins at kick off, which skips the period where a good deal of the outcome is actually determined. The weeks before a project starts are the cheapest time to make decisions, because nothing has been built yet and changing your mind costs nothing.
Businesses that arrive at kick off prepared move faster, spend less and end up with a better fit, and the preparation is not complicated. It is mostly a matter of knowing what will be asked of you and having answers ready rather than assembling them under time pressure while the project meter runs.
This is a practical timeline of what to do before day one, roughly in order, with the reasoning for each.
Start with the problem rather than the solution, and be specific enough that somebody could later check whether it was solved.
"Our current system is old" is not something anyone can build against. "We cannot see stock across three warehouses, our month end takes eleven working days, and we cannot report profitability by project" is. The second version gives the partner something to design toward and gives you something to measure against.
Rank them, because you will not get everything and knowing what matters most changes decisions throughout the project. When a trade off arrives in month three, the ranked list is what resolves it.
Keep the list visible for the whole project. It is the reference point every time somebody proposes an addition, and the question of whether a request serves one of these objectives settles a surprising number of scope conversations.
This is the most consequential decision made before a project starts, and it is frequently made casually.
The project needs someone from the business with authority to make decisions and enough time to make them properly. Not a sponsor who attends monthly, an owner who is involved continuously. An implementation generates a stream of questions that only the business can answer, and the speed of those answers largely determines the timeline.
Be honest about the time commitment. For most mid sized implementations this approaches a full time role during the middle phases. Appointing someone and taking nothing off them is a decision to have a slower project, and it is better to know that now than to discover it in month three.
Also decide what they can approve alone and what needs escalation, and how quickly escalation can happen. A project where every decision goes to a monthly steering group runs at the pace of that group.
You need process owners from each function NetSuite will touch, and choosing them well matters.
Pick people who do the work rather than only manage it. A finance manager describes the process as designed, and the person who actually processes the invoices knows the exceptions. The exceptions are where implementations come unstuck.
Confirm availability with their managers explicitly rather than assuming. A nominated process owner who cannot attend workshops is worse than no nomination, because their absence is not noticed until decisions have been made without them.
Include at least one person who is sceptical about the project. Enthusiasts tell you it is going well. Sceptics tell you what is wrong, which is what you actually need.
The partner will do this during discovery, and doing a first pass yourself beforehand makes discovery faster, cheaper and considerably more accurate.
Work through your main flows end to end. Quote to cash, purchase to pay, the month end close, inventory movement, payroll. For each, write down what happens, who does it, in what system, and what triggers the next step.
Include the workarounds honestly. The spreadsheet somebody maintains, the informal approval that happens by conversation, the step that exists because of something that went wrong three years ago. These are the most valuable part of the documentation, because they are what a generic implementation will fail to accommodate.
Note the exceptions too. What happens with a part shipment, a customer on credit hold, a return, a supplier who invoices differently. Exceptions are where the real configuration decisions sit.
Data is the most reliable source of delay in an implementation, and the delay is largely avoidable by starting early.
Find out what you actually have. How many customer records, how many suppliers, how many items, how much transactional history and across how many systems. Numbers rather than impressions.
Then assess condition. How many duplicates, how many incomplete records, how many items nobody has sold in three years, how many customers who are no longer customers. This is usually worse than expected, and finding out now is far better than finding out during a trial load.
Start cleansing before the project begins. Every duplicate removed now is one you do not migrate, do not reconcile and do not have to explain later. This is work only your business can do, and it is the single most useful thing you can be doing while waiting for a project to start.
This decision drives a meaningful part of the migration effort, and it is worth making deliberately rather than defaulting to everything.
The instinct is to bring all history across in case it is needed. In practice, open balances plus a limited period of transactional history covers the overwhelming majority of real requirements, and the old system remains available in read only form for anything older.
Ask what you genuinely need to do in the new system. Comparative reporting for a year or two is a legitimate requirement. Being able to look up a transaction from 2016 is a lookup requirement, and lookups can be served by the old system.
Less history means faster migration, cleaner data, less reconciliation and lower cost. It is one of the few decisions where the cheaper option is also the better one.
Make an inventory of every system that will need to exchange data with NetSuite, and be thorough, because the ones that get forgotten are usually departmental tools nobody at the centre knows about.
For each, note what data moves, in which direction, how often, and how it happens today. Whether the system has an API, and whether anyone has ever used it. Who the vendor contact is.
That last item matters more than it appears. Integration timelines frequently depend on a third party vendor's responsiveness, and establishing that contact before the project starts removes a common source of delay.
Also decide which integrations are genuinely required at go live and which could follow. Deferring one is often the cheapest way to protect a date.
The chart of accounts and dimensional structure is among the most expensive things to change after go live, which makes it worth thinking about before anyone else does.
Review what you have now and ask what is actually used. Most charts accumulate accounts that exist for historical reasons and are never posted to, and an implementation is the natural moment to remove them.
More importantly, think about how you want to report. NetSuite's dimensional structure, meaning subsidiaries, departments, classes and locations, is what makes reporting flexible without proliferating accounts. Businesses that push reporting dimensions into the account code end up with an unwieldy chart and limited flexibility.
Arriving with a clear view of how you want to analyse the business is one of the most useful things you can bring to a design workshop.
Collect the reports people actually use, meaning the real ones rather than the ones that exist officially.
Ask each function what they produce, what they receive, and what they wish they had. Pay particular attention to anything produced in a spreadsheet, because that is a direct statement of a reporting need the current system does not meet.
Distinguish between reports that are genuinely needed and reports that are produced out of habit. Some will not survive the question of who reads them and what decision it informs.
Bringing this to the project matters because reporting is the requirement most often under specified at design time and most often disappointing at go live. Our piece on maximising the value of a NetSuite investment covers why that gap opens.
Anything with a legal or regulatory dimension is worth establishing before design rather than discovering during testing.
On the payroll side, that means which modern awards apply to which roles, how allowances are treated, what the superannuation earnings base is for each payment type, and whether any annualised salary arrangements exist and are properly documented. If any of this is uncertain, resolve it before it is configured, because the configuration will encode whatever assumption is made.
On the tax side, GST treatment for your transaction types, business activity statement requirements, and anything unusual about how you invoice or are invoiced.
And on the reporting side, any statutory or lender reporting the system will need to support, along with audit requirements about retention and traceability.
Implementation budgets that only cover the partner's fee are incomplete in predictable ways.
Include internal time, which is real cost even though it does not appear as an invoice. Include data cleansing effort. Include training, both at go live and afterwards. Include the post go live support arrangement. Include a contingency, because something will vary from plan.
Also budget for the twelve months after go live rather than only the project. Reporting gets built out, deferred modules get enabled, refinements get made. Businesses that treat go live as the end of spending are the ones that end up using half of what they bought.
Go live timing has real consequences, and the good windows are contested.
The start of a financial year is cleanest for a financials cutover, because it avoids splitting a year across two systems. It is also the busiest period for partners, so it needs booking early.
The start of a quarter or month is the workable alternative. Mid month cutovers create reconciliation work that nobody enjoys.
Payroll has its own consideration. Moving at the end of the payroll year removes the year to date migration almost entirely, which is a meaningful simplification.
And avoid your own peak. A new system arriving when the business has least capacity to absorb it is a predictable and avoidable difficulty.
Communication before the project starts costs nothing and prevents a category of resistance.
Tell people a change is coming, why, and roughly when. In the absence of information people assume the worst version, and that assumption is harder to correct later than to prevent now.
Be specific about reasoning in terms that matter to them rather than to the board. Nobody is motivated by improved data visibility. People are motivated by no longer rekeying orders between two systems.
And acknowledge what will be harder as well as what will be better, because every change has both and admitting it buys credibility for the rest.
All of the above makes partner selection considerably better, because you can have a specific conversation rather than a general one.
Prepare a brief covering your objectives, your scope, your entity structure, your rough data volumes, your integration list and your timing constraints. Partners quoting against that produce comparable proposals rather than proposals built on different assumptions.
Then evaluate on discovery depth, relevant experience, named people and what happens after go live rather than on headline price. Our piece on choosing a NetSuite Alliance Partner covers what to look for in more detail.
If you are starting from nothing, a workable sequence is to define objectives and appoint an owner first, then assemble the team and begin process documentation, then take stock of data and start cleansing, then work through the chart of accounts, reporting and compliance requirements, then prepare the brief and select a partner, and keep cleansing data throughout because it is never finished.
None of it is difficult. It is simply work that has to happen at some point, and doing it before the project starts means doing it without the clock running.
Our approach to NetSuite implementation sets out what happens once the project begins, and the implementation journey guide covers each phase from the client's side.
If you are preparing for a project and would like a view on what to prioritise, get in touch.
