The nine phases
- 1
1. Discovery
Working sessions with finance, operations, sales and IT to understand how the business runs today, where it hurts and which dates cannot move.
- 2
2. Fit-gap and written scope
Each requirement is matched to standard features, an AppSource app, configuration or custom work. The result becomes the scope both sides sign.
- 3
3. Solution design
Chart of accounts, dimensions, posting groups, approval flows, integration mappings and security roles are designed on paper before anything is built.
- 4
4. Build and configure
We set up the environment, configure the design, write any extensions and connect integrations in a sandbox you can log into and explore.
- 5
5. Data migration
Master data, open items and balances are extracted, cleansed and loaded in trial runs, each one reconciled against the old system.
- 6
6. Testing and UAT
We test the build ourselves, then your key users run their own end-to-end scenarios, from order to cash and purchase to pay.
- 7
7. Training
Role-based sessions, recorded where useful, plus short written guides for the tasks each team does every day.
- 8
8. Go-live
A cutover checklist covers the final data load, opening balances, integrations switched on and the old system set to read-only.
- 9
9. Support
Close attention through the first month end, then an optional ongoing support arrangement for questions, updates and small changes.
What you receive at the end of each phase
Where projects usually slip, and how we guard against it
Most delays we see on other projects trace back to three things: data that turned out dirtier than expected, key users who were too busy to test, and scope that grew in conversation without anyone writing it down. None of those are software problems.
We tackle data early by running the first trial load while the build is still in progress, so cleansing work surfaces while there is room for it. We agree named key users and their availability in the scope, and we treat user acceptance as a gate, not a formality. Any new request goes through a written change, with its effect on effort stated before anyone starts.
Go-live is a decision, not a date on a chart. If acceptance testing or the final reconciliation is not clean, we recommend holding, and we explain why.
What the process needs from your side
- βA sponsor who can make decisions when departments disagree
- βNamed key users with protected time for workshops and testing
- βSomeone who owns the data and can answer questions about it
- βAccess to current systems for extraction and comparison
- βTimely sign-off at each phase gate so the next phase can start
- βHonest feedback when something in the design does not match reality
Questions about how we run projects
Do you use waterfall or agile?
A mix, chosen for what ERP work actually needs. Scope and design are agreed up front because finance structures are expensive to change later. Within the build, we work in short cycles and show configured features to key users early, so feedback arrives while it is cheap to act on.
Is the process the same for a small project?
The phases are the same, but their depth scales. A finance-only Business Central setup might combine design and build into a few focused sessions, while a multi-company rollout with warehouse and integrations needs each phase in full. Skipping a phase entirely is where problems start, so we keep all of them.
How many trial data loads do you run?
As many as it takes for the reconciliation to come out clean. Typically there are several, with the final one being the cutover load itself. Each trial is compared against the old system's balances and open items, and your team signs off before we move on.
What happens if UAT fails?
We fix the issues and test again before go-live. Failing items are logged, prioritized with you, and resolved or explicitly deferred with your agreement. We do not recommend going live on a system your own users have not accepted.
Can we run some phases ourselves?
Yes, particularly data cleansing, training delivery and parts of testing. The written scope states who owns each task. We will give an honest view on which phases are safe to take in-house given your team's experience.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.
