When we tell a client they’re ready to go live, we mean something very specific:
- You can pay your people.
- You can pay your vendors.
- You can send an invoice and recognize revenue.
- You can print a basic financial report.
- You can reconcile the bank and close the period.
With these five, you are live.
You may need to hand-write a check on a Tuesday because something is off in the bank file. You may not love your invoice template. The CFO's monthly reporting package may still require some massaging in Excel. None of that disqualifies you. The system is doing its job and the business is operating.
It's a much lower bar than most companies expect. They walk into implementation expecting the system to be polished on day one, every report pixel-perfect, every workflow optimized.
So if "live" is that minimal, the obvious next question is when are we actually going to be done?
Never.
You're never done. The project will end, but the work is never done. That goes for the original implementation, for phase 2, for the optimization sprint two years in, and for any other engagement we'll ever have together. They all finish. The system itself, though, the thing your business runs on every day, never does. It can't, because your business doesn't either.
Rough and Ready Is the Right Play
The go-live bar is set where it is on purpose. Until you've been operating in the system for a while, you don't actually know what you need. You have a configuration built on your best guesses about how the business will run in NetSuite. Some of those guesses will hold up. Others won't.
Some of the requirements you fought hardest for during implementation will turn out to be irrelevant in the new context, and you'll quietly stop using them. Other things you dismissed as unimportant will turn out to be critical. You can't know which is which from inside an implementation project. You learn it by transacting in the system.
So get live. Get using it. Pay attention to what's actually rough versus what just feels rough because it's new. Don’t fix anything right away. Start a backlog and add to it as your team finds friction. Phase 2 takes its shape from inside the running system, with real users and real data showing you what actually matters.
And of course, when you finish phase 2, you’ll let that burn in, and start thinking about how it could be better. It starts a never-ending cycle of continuous improvement.
The Comfort and the Risk of Calling It All Done
Declaring the system itself "done" is comforting. It suggests finality, it signals cost containment, it gives the organization permission to move on to other priorities.
It also introduces a quiet risk that doesn't show up on a balance sheet right away, because the moment you treat your ERP system as finished, you've effectively decided your business is finished evolving.
Most finance leaders would never say that out loud, but operationally that's exactly what happens. The system becomes static, workarounds creep in around it, Excel quietly regains its foothold, reporting lags the questions leadership is actually asking, and headcount grows to absorb friction the system could have handled. What was meant to be a platform for scale becomes one more thing to manage.
A Different Way to Think About It
Thomas Jefferson wrote, in 1816, that “laws and institutions must go hand in hand with the progress of the human mind.” He wasn't talking about ERP systems. The principle still holds. Institutions, in his view, were not fixed artifacts; they evolved with the people they served, or they failed those people. He used the metaphor of a child's coat. A constitution, like a child's coat, must be made to fit the wearer.
Each coat is finished when it's made. The kid keeps growing, so eventually you make another one. Outgrowing a coat isn't a failure. The kid grew.
A NetSuite instance implemented for a $50M company is not the system that company will need at $150M, or when it expands into three new states, or introduces subscription billing alongside its existing project work, or faces a new compliance regime, or acquires another business and inherits a different chart of accounts. Outgrowing the original implementation isn't a failure either. The business grew.
What Happens Next, Whether You Plan for It or Not
Over the life of a NetSuite environment, certain kinds of work recur. They aren't continuous, they don't all run at the same time, and they don't always come in the same order, but most healthy systems see all of them, often more than once.
The first is stabilization, usually right after go-live. You're closing books, fixing edge cases, cleaning up data that didn't migrate cleanly, and adjusting workflows that didn't behave the way you expected. This is when you discover what you actually built versus what you thought you built. When the books are closing cleanly two or three months in a row and the workaround list isn't growing, stabilization is finished.
Then there's optimization, when the team starts asking sharper questions. Why does this process take this long? Why are we still touching this manually every month? Why does this report require so much reconciliation in Excel? This is where teams begin to use capabilities they already own, like SuiteAnalytics, saved searches, and role-based dashboards. The system starts to do more of the work it was always capable of doing. This work has scope and a finish line too, though it tends to come back around as the business asks new questions.
Then there's automation, the practical kind that removes hours from someone's week. Vendor bill capture replaces manual AP entry, Advanced Revenue Management handles rev rec, Avalara takes over tax calculation across jurisdictions, and Celigo or another iPaaS connects systems that were previously bridged by someone copy-pasting between tabs. Each of these is its own project, with a beginning and an end. Together, they're how you grow the business without proportionally growing the back office.
And then there's adaptation, because the business doesn't end. New products, new geographies, new compliance frameworks, new investor expectations after a recap or a sale. The system has to keep pace, or it becomes an anchor.
Where It Goes Wrong
We've seen this play out enough times that the pattern is familiar. Two organizations go live in roughly the same shape, both clear the five-question bar, both have a functioning system, a clean first close, and a reasonably trained team.
In the first organization, somebody owns the backlog of process improvements, and the company commissions work when it makes sense to. Six months in they tighten ARM. A year later they put in vendor bill automation. After the next round of growth they rebuild the management reporting package because the company has grown into different questions. Each of those is its own project, with its own scope and its own ending. None of them runs forever. Three years later, the system is doing more work than it did at go-live, and the finance team is leaner relative to revenue.
In the second organization, the implementation was declared complete and that was the end of the investment. There were no more projects, because the system was "done." Manual processes crept back in because nobody was tasked with removing them. The reporting that worked at $50M started to fall behind at $90M. Spreadsheets multiplied, and the team grew to fill the gap. The business hadn't gotten more complex in ways the system couldn't handle. Nobody was teaching the system to handle the new complexity, so people did.
Both started in the same place. They ended very differently.
Stay Fit
There's another way to think about this, simpler than the rest of what I've written here.
Stay fit.
If you run two or three miles every day, the day you need to run five isn't a crisis. It's a longer version of something you're already prepared for, and your body knows what to do.
ERP works the same way. A system that gets ongoing attention, incremental improvement, and the occasional bigger project when the business calls for one doesn't fear change. It expects it. The business pivots, and the system pivots with it, because the muscles are already there.
A system that's been treated as finished is the opposite. Every change feels like an event, every new requirement turns into a bigger lift than it should be, every adaptation feels like a risk. The organization becomes cautious about what it can ask of its own infrastructure, which means it becomes cautious about what it can ask of itself.
A More Useful Definition of Success
If "done" isn't the right goal for the system as a whole, what is?
For us, success is never being afraid of your system's ability to keep up with your business. It's going to sleep without worrying that the next strategic shift, a new pricing model, a new market, a new compliance requirement, is going to expose the limits of your infrastructure. It's knowing that your finance team can answer the next question, whatever it turns out to be.
That requires more than a single completed project. It requires the willingness to do more of them when the business calls for it.
If you're a CFO or finance leader who has felt the need to keep investing in your ERP environment, and has had to defend that investment to peers or a board, you're not imagining things. The value of these systems shows up over time, through deliberate effort to keep the system aligned with the business it supports.
Or, to give Jefferson the last word: “as new discoveries are made, new truths discovered and manners and opinions change with the change of circumstances, institutions must advance also, and keep pace with the times.”
Your ERP system is one of those institutions. Keep it fit.
