Experience smooth transition to NetSuite with our comprehensive ERP migration plan. Discover the key steps, potential challenges and their solutions, to ensure a successful ERP implementation. Maximize your NetSuite investment today with a structured and proven migration strategy.
Choosing the system is the decision everybody focuses on and it is usually the least consequential of the major ones. What happens next, meaning how the migration is planned and who does what, determines whether you get the system you selected or an expensive version of what you already had.
This article covers what belongs in a migration plan, in the order the decisions need making, and where the effort actually lands rather than where people expect it.
Before any planning, be specific about what the new system should make possible that is impossible now.
Better visibility is not a requirement, it is an aspiration. Knowing margin by customer within three days of month end is a requirement, and it is testable at the end.
Write down three to five of these, agreed by the leadership team, and keep them visible throughout the project. They are what scope decisions get tested against when the inevitable trade offs arrive.
Without them, scope gets decided by whoever argues most persistently, which produces a system that reflects internal politics rather than business need.
This is the single decision that shapes the project most and it is frequently never made explicitly.
Redesigning processes produces more value and a harder, longer, more disruptive project. Replicating existing processes produces a faster project that frequently carries forward every inefficiency the old system had.
Neither is wrong. Not deciding is, because a project without a stated position defaults to replication. Replication is what people describe when asked what they need, since they describe what they do now.
The decision also drives everything downstream. Redesign favours more discovery, more iteration and more change management. Replication favours a preconfigured approach and a shorter timeline.
Make it at leadership level and communicate it, because the design team will otherwise make it by default.
The most common planning failure is assuming that internal capacity will be found rather than allocated.
ERP migrations require substantial time from the people who understand the processes, and those are always the busiest people in the business.
Work out how many hours per week each person needs, being specific about which phases are heaviest, since discovery, testing and cutover demand considerably more than the middle of the build.
Then decide what each of them will stop doing to create that time, and write it down. Capacity that is assumed rather than freed does not materialise, and the project discovers this in week six.
Appoint an internal owner with real authority and real time, because projects without one struggle regardless of how good the partner is.
Data condition determines the timeline more than transaction volume does, and most plans are built on an optimistic assumption about it.
Profile the actual data early. How many customer records, how many duplicates, how many inactive, how many with incomplete details.
Do the same for suppliers, items and employees, and look for the structural problems too. Fields used for something other than their purpose, free text where a code should be, information encoded in naming conventions.
This is a few days of work and it converts the largest assumption in your plan into an estimate.
It also tells you how much cleansing effort to allocate, which is the number most projects get wrong.
How much historical data you migrate is the largest single driver of migration effort and it deserves a proper challenge.
Ask what specific question needs historical data, and how often it is asked. Vague answers about wanting history available usually indicate comfort rather than requirement.
Consider keeping the legacy system available in read only form for a defined period, which is frequently cheaper, faster and lower risk than migrating.
Consider whether summarised history would do, since monthly balances by account and dimension satisfy most reporting needs at a fraction of the effort.
And recognise that migrated history carries the old dimensional structure, so it may not give you the comparability you imagined anyway.
The dimensional model is the most consequential design decision and it looks administrative, which is why it gets rushed.
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.
Changing it later means recoding history, which is expensive enough that most businesses live with whatever they chose.
Design it against the questions your leadership team actually asks rather than against your current reporting, since your current reporting reflects what the old system could produce.
And resist the temptation to add every dimension that might be useful, since dimensions that are not populated consistently produce reporting nobody trusts.
Most businesses have systems that will remain after go live, and the connections between them need designing rather than assuming.
Establish what talks to what, in which direction, how often, and what happens when one side is unavailable. That last question is skipped most often and causes the most trouble.
Decide the source of truth for each shared record, because where two systems can both create a customer they will diverge, and reconciling them becomes somebody's permanent job.
Be honest about ongoing ownership, since integrations fail quietly and a connection with no named owner is a future incident.
And question whether each integration is necessary, because some connections exist to support a system the new platform could replace.
Migration budgets are frequently built from the visible costs and then overrun on the ones nobody listed.
Licensing is the easiest number to obtain and usually not the largest, since it scales predictably with users and modules.
Implementation is larger and more variable, driven mostly by process complexity and data condition rather than by the size of the business.
Internal time is the cost most consistently omitted, and it is real even though it does not appear on an invoice. Somebody is being paid to attend design sessions and cleanse data rather than to do their normal job.
And there is a post go live allowance that almost nobody budgets, covering the support intensity of the first quarter and the improvements the first month end will identify. Leaving that out is how a project that delivered technically ends up judged a disappointment.
Training that sits as a line inside the project absorbs the slippage from everything upstream, which is why it reliably gets compressed into the final fortnight.
Give it its own budget and its own dates, protected from the rest of the plan.
Involve whoever will deliver it during design, so they understand why decisions were made and can explain rather than describe.
Schedule it against first use rather than against go live, so month end training happens before the first month end and periodic activities are trained before their first occurrence.
And build reusable material during the project, because within a year a meaningful proportion of the people you trained will have moved on.
Testing is where the business does its most valuable work and where schedules most reliably overrun.
The overrun is usually not the testing but the fixing, retesting and re fixing cycle that follows, and plans allocating time for the first pass and none for the iterations are the ones that slip.
Allow for at least two full cycles, with the expectation that the first finds more than anticipated if the testing is any good.
Test end to end rather than by module, since the interesting failures happen at handoffs, and test the exceptions deliberately because routine transactions rarely reveal anything.
And test with the permissions people will actually have, since a process that works as an administrator can fail entirely for the person who has to run it.
The date constrains everything and it is frequently chosen for the wrong reasons.
The start of a financial year is administratively cleanest, particularly for payroll and anything with year to date balances.
The start of a period is the minimum acceptable alternative, since a mid period cutover creates a reconciliation exercise nobody wants.
Avoid peak trading periods, and be specific about when yours is because a partner may not know.
Avoid periods when key people are unavailable, which sounds obvious and is routinely overlooked because the date was set months earlier and nobody re examined it against the leave calendar.
Cutover is short, intense and it rewards planning more than any other phase.
Write the sequence hour by hour, with who does what, what must finish before the next step, and who confirms each one.
Freeze the legacy system at a defined time and communicate it widely, because a transaction entered after the extract creates a discrepancy nobody finds for weeks.
Build in a verification step after the load and before opening the system to users, with enough time to actually check rather than glance.
And define the rollback position, including the point after which rollback is no longer practical, because deciding that at three in the morning produces bad calls.
Most migration plans end at cutover, which is where the real problems appear.
Plan for the first two weeks explicitly, with help available within minutes rather than within days, because a question unanswered for two days becomes a permanent workaround.
Plan the first month end as an event with its own preparation, since that is the real test and where the reconciliations nobody thought about get discovered.
Plan a stabilisation quarter before attempting any improvement, because a business still learning the system cannot absorb more of it.
And name who owns the system afterwards, because a system nobody owns drifts within a year.
Scope creep on ERP projects happens through accumulation rather than through any single decision.
Each request is individually reasonable. Collectively they move the date and consume the contingency.
Keep a deferred list rather than saying no, since most requests are legitimate and simply not now. A visible deferred list is also the beginning of your post go live improvement plan.
Test every in scope request against the three to five outcomes you wrote down at the start, because that is what they are for.
And make sure somebody has both the authority and the willingness to defend scope, since a project where everybody defers to whoever asks most persistently has no scope control at all.
Project governance on mid sized migrations is frequently either absent or theatrical, and neither helps.
A short weekly operational meeting deals with issues and decisions. A monthly steering conversation deals with scope, budget and risk.
The steering group needs somebody who can decide in the room, since a forum that refers everything onward adds delay rather than control.
Track decision latency as a measure, because projects stall on decisions more often than on work and a rising trend is an early warning.
And insist on honest reporting rather than green, since a project that reports green until two weeks before go live has a reporting problem in addition to whatever else is wrong.
A good migration plan is built from an honest assessment of your data, your process complexity and your genuinely available capacity, and it is defended against the accumulation of individually reasonable requests.
The two highest value things you can do before the project starts are profiling your actual data and working out, person by person, what they will stop doing to make room for this.
Both are unglamorous and both prevent the failures that most commonly move dates.
Our pieces on the data migration checklist and implementation timelines cover the detail, and partnering and planning covers the two decisions that sit above this one.
If you would like help building a plan for your own migration, get in touch.
