Updated October 2026
By Louis Balla, Chief Revenue Officer, Nuage
ERP deployment best practices start with a rollout strategy that fits your risk tolerance, big bang or phased. Then configure standard features before writing custom code, migrate clean master data and only open transactions, rehearse the cutover, and staff go-live support through the first month-end close, because that close is the first full test of the new system.
The core practices, in the order a project meets them:
- Name an executive sponsor who makes decisions and clears roadblocks for the length of the project.
- Give key users protected time for the project, and backfill their day jobs during testing and cutover.
- Document requirements and measurable objectives before configuration starts.
- Choose a rollout strategy and a hosting model that match your risk tolerance and IT resources.
- Use standard configuration first, and approve each customization against a stated business need.
- Clean and validate data before migration, and run more than one mock load.
- Test in layers, finishing with day-in-the-life sessions run by the people who will use the system.
- Set the go-live date by readiness criteria and review it as testing progresses.
- Keep support in place through the first month-end close.
The rest of this guide explains each practice. The examples come from recent NetSuite projects our team has worked on, and the practices apply to any ERP.
ERP deployment vs. ERP implementation
ERP implementation covers the whole project, from software selection through configuration, data migration, testing, training and go-live. ERP deployment is the part that gets the system into your users’ hands. Its two big decisions are the rollout strategy and the hosting model, and its main event is cutover, the day transactions move from the old system to the new one. The weeks after cutover are the stabilization period, when the new system runs its first full cycles with support close at hand.
The two terms get used interchangeably in project meetings. The distinction matters because deployment choices set much of the project’s risk: a single cutover for the whole company carries different risks from a rollout that moves one subsidiary at a time. For a full walk-through of a NetSuite project, see our NetSuite ERP implementation guide.
ERP deployment strategy: choosing a rollout approach
Your rollout strategy decides how much of the business changes systems on the same day. There are two main approaches, big bang and phased, and a parallel run can be added to either.
| Big bang | Phased | Parallel run | |
|---|---|---|---|
| What goes live | Every module and location on one date | Stages, by module (finance first, then inventory and manufacturing) or by business unit (headquarters first, then each site or subsidiary) | The old and new systems run side by side for a set period |
| Main advantage | A single cutover with no temporary interface, and one set of numbers for the whole company from the first day | Each phase is smaller, and the team carries what it learned into the next phase | A check on critical numbers such as the trial balance and open receivables |
| Main trade-off | Risk is concentrated: a gap in data or configuration shows up across the company at once | A longer overall timeline, and temporary interfaces between the two systems while both are in use | Every transaction in scope is entered twice |
| Best fit | A company that runs as one entity and can rehearse its cutover end to end | A group whose subsidiaries, sites or modules can go live independently, or a team that wants to learn on a smaller scope first | The processes where an error would be expensive |
With a big bang rollout, testing and cutover rehearsal carry more weight than in a phased plan, because every process changes on the same day. If you add a parallel run, limit it to the processes that need it and set the end date before it starts.
ERP deployment options: cloud, on-premise, hybrid and two-tier
The hosting model decides who runs the infrastructure and who controls upgrades.
| Option | Who runs the infrastructure | Upgrade timing | Where the deployment effort goes |
|---|---|---|---|
| Cloud (SaaS) | The vendor, for a subscription | The vendor’s release schedule | Configuration and data, plus testing each release in a sandbox |
| On-premise | Your IT team, on your own servers | Your decision | Hardware, installation and ongoing maintenance, as well as configuration and data |
| Private cloud | Your team or a hosting provider, on dedicated infrastructure | Mostly your decision, as with on-premise | Configuration and data, with less hardware to look after directly |
| Hybrid | Split, for example a cloud CRM connected to an on-premise finance system | Different for each part | The integration between the cloud and on-premise parts |
| Two-tier | Headquarters runs one ERP and subsidiaries or plants run another | Set separately for each system | The integration and the consolidation of results at the parent |
NetSuite is delivered as cloud software, so on a NetSuite deployment the effort goes into configuration, data and release testing. Two-tier fits groups with recent acquisitions or subsidiaries that operate very differently from headquarters.
ERP implementation best practices, phase by phase
Three practices run through the whole project, whichever rollout strategy you pick. An executive sponsor has to stay involved for the whole project and make the decisions that would otherwise stall the project team. Key users need protected time on their calendars, with their day-to-day work covered during the heaviest weeks of testing and cutover. Change management starts at kickoff, with an explanation of why the company is changing systems, and continues through go-live.
Planning and discovery
Form a cross-functional team with someone from every department the system touches, including the people who will enter transactions every day. Map current processes in workshops and record where they break down. Agree the future-state process before anyone configures a screen.
Set objectives you can measure against today’s baseline, such as the number of days it takes to close the books or the share of orders shipped complete. Write down how decisions get made, with a RACI matrix (who is responsible, accountable, consulted and informed) and a risk log that gives each risk an owner and a mitigation.
Set the go-live date against readiness criteria, such as passed test scripts and a reconciled mock data load, and review it at fixed checkpoints. When the date moves without criteria, the team loses the fixed point it plans training and data loads around.
Design and build
Start with a fit-gap analysis that shows where standard functionality meets each requirement and where you would need a process change or a customization. Prefer configuration. Each customization adds build and maintenance cost, and custom code has to be retested when the platform upgrades. For every proposed customization, ask whether the business could adopt the standard process, and record the answer.
Give the data model careful attention. The chart of accounts and the item master structure shape reporting for years, and they are expensive to change after go-live. Define roles and permissions from job functions early, with segregation of duties built in, and document each configuration decision so training and later support start from a written record. Our NetSuite implementation best practices cover the NetSuite-specific setup choices.
Data migration and testing
Clean data in the source system before it moves: remove duplicates and retire outdated records. Map each source field to its target field, with written transformation rules where the structures differ. Load master data first (customers, vendors and items), then open transactions. Leave closed history in the old system or a read-only archive unless there is a reporting or audit reason to bring it across.
Plan for several mock loads, and reconcile each one against the source before the next. Much of the data work depends on your own team. In our client work, data migration, imports and mass cleanup made up 139 of 3,241 requests (4.3%), and 93 of their root-cause tags pointed to data quality. The 69 of those requests that have closed took a median of 27 days, and the usual first dependency was the client supplying the files or confirming the numbers. Name an owner on your side for each data set before the first mock load.
Test in layers:
- Unit testing of individual configurations
- Integration testing of end-to-end processes, such as order to cash and procure to pay
- User acceptance testing with real business scenarios
- A conference room pilot, where users run a scripted day in their own jobs on the new system
- Performance testing at expected transaction volumes
The conference room pilot tends to surface the process gaps that design workshops missed, because users are working through their actual tasks.
Cutover and go-live
Write a cutover runbook with each step, its owner and its timing, and rehearse it. Freeze configuration changes for a defined period before cutover so the system you tested is the system that goes live. Decide in advance which processes, if any, need a parallel run.
Plan support for the days after go-live before cutover starts. Nuage classified 3,241 of its own client requests by what triggered them. Most named no trigger at all, and among the ones that did, a go-live or new-module rollout was the most common, at 151 requests (4.7%), ahead of month-end close (120) and audits (54). If you are moving from QuickBooks, our QuickBooks vs. NetSuite comparison covers the decision.
Integrations need their own launch plan. Before a food and beverage company’s order integration went into production, our team wrote a launch and support plan that included on-call coverage for critical issues, with after-hours availability. In the five weeks after launch the client opened five follow-up requests on the integration scripts, and every one was closed.
NetSuite also publishes its own overview of ERP implementation steps and phases.
Stabilization through the first month-end close
Go-live starts a stabilization period. The first month-end close is the first time every process runs together on the new system, from billing and payables through bank reconciliation and reporting, so plan support around it.
When an equipment rental company went live with a heavily customized integration from its rental system, we agreed with them to treat the first month-end close as the test and to move into ongoing managed services only after that close succeeded. The hand-off includes a formal knowledge transfer, written documentation, and the implementation developer staying available to the Stratus team. Give each stabilization task its own owner and track it as separate work.
During stabilization, run a help desk with a clear escalation path so users know where to take a problem, and keep an issue log that becomes the knowledge base for later support. Watch system performance and fix slow points quickly, because they affect whether people keep using the system. Collect user feedback and act on it, and record lessons learned for the next phase. Our article on post-implementation NetSuite support covers what happens after the project team leaves.
After go-live: measuring results and keeping the system current
Measure against the objectives and baselines you set during planning, such as days to close or inventory accuracy. Track adoption as well: which tasks still happen in spreadsheets, and where users have built workarounds.
Once the first quarter-end close is behind you, run a post-implementation review. It identifies quick fixes and the larger improvements worth planning.
Keep the system current. Cloud ERP vendors ship upgrades on a set schedule, so test each release in a sandbox before it reaches production, and check custom scripts and integrations first. Route changes through a release process where each change is tested and communicated before it reaches users, and work through improvement requests in short, focused cycles. Review user access on a schedule, and train new hires on the processes as they are actually configured.
How Nuage approaches ERP deployment
In the two recent NetSuite projects described above, our team planned the deployment around these steps:
- Write a launch and support plan before an integration goes into production. It covers on-call support for critical issues, with after-hours availability.
- Treat the first month-end close as the test. The move into ongoing managed services waits until that close succeeds.
- Hand off with a formal knowledge transfer. Written documentation goes with it, and the implementation developer stays available to the Stratus team.
After go-live, our team provides ongoing NetSuite optimization and managed services.
Frequently asked questions about ERP deployment
What is ERP deployment?
ERP deployment is the part of an ERP implementation that puts the system into users’ hands. Its two main decisions are the rollout strategy (big bang or phased) and the hosting model (cloud, on-premise, hybrid or two-tier), and it ends with the cutover from the old system to the new one. Implementation is the wider project, which also includes software selection, configuration, data migration, testing and training.
What is the best ERP rollout strategy?
It depends on how your company is organized. A big bang rollout suits a single-entity company that can rehearse its cutover end to end, because everyone moves to one set of numbers on one date. A phased rollout suits a group whose subsidiaries, sites or modules can go live independently, at the cost of a longer timeline and temporary interfaces between the old and new systems.
Should we run the old system in parallel after go-live?
Only for the processes where an error would be expensive, such as cash and payroll. A parallel run lets you compare outputs between the two systems, but every transaction gets entered twice, which strains the team during the busiest weeks. If you run one, set the end date and the comparison checks before it starts, and stop when the numbers match.
What is the safest way to migrate historical data?
Clean and validate data in the source system first, then map each field and write transformation rules where structures differ. Load master data before transactions, and run several mock loads, reconciling each against the source. Consider migrating only open transactions, such as open receivables and payables with their due dates, and keeping closed history in the old system or an archive for reference.
How much time should our team commit to an ERP deployment?
Key users need protected time every week, first for design workshops and later for testing and training, and the project manager and process owners carry a heavier load than other users. Plan to cover part of their day-to-day work during testing and cutover, because those weeks overlap with normal operations, and the first month-end close on the new system needs your finance team’s full attention.
About the author
Louis Balla is Chief Revenue Officer and a partner at Nuage, a NetSuite partner founded in 2011 that has served more than 250 clients. Nuage holds a 4.9 out of 5 rating on Clutch. The client work described in this article was delivered by our team.
