- Agree the business outcomes before discussing customizations.
- Give every data set and critical process a named owner.
- Approve go-live against evidence, not just a target date.
1. Start with the decisions your business needs to make
A legacy ERP rarely becomes a problem overnight. Teams gradually build spreadsheets around it, approvals move to email, and one experienced employee becomes the only person who knows how a process works. Replacing the application without understanding those workarounds can move the same problems into a newer system.
Before a Dynamics 365 Business Central implementation, ask each business owner to describe the outcome they need. Faster month-end closing is an outcome. A particular screen layout is a design preference. Separating the two helps your team agree what matters when time and budget are limited.
2. Define phase one around complete business processes
Document a transaction from beginning to end: quotation to collection, purchase request to supplier payment, or production demand to finished stock. Include approvals, exceptions, reporting and the people who make decisions along the way.
Then agree what must work at launch and what can follow. A phase-one scope should let a team complete its essential work without leaving an unplanned gap between departments. Record the reason for every retained customization. Some may still be necessary; others may exist only because the old system lacked a suitable standard process.
3. Treat data preparation as a business responsibility
Assign owners for customers, vendors, items, accounts, units of measure and opening balances. Decide which historical records need to move, which can remain in an accessible archive, and how users will find them. Migration volume is only one consideration; consistency and reconciliation are just as important.
For example, two item codes may describe the same material while using different units. Loading both without resolving the difference can affect purchasing, inventory and reporting. Agree a cleansing rule with the business owner, document the decision and test the result before the final migration.
4. Test exceptions as well as the happy path
Build user acceptance testing around actual scenarios. Include a partial receipt, a sales return, an incorrect invoice, an approval rejection and a period-end adjustment where these apply to your business. Test access rights and integrations using the roles that will use them after launch.
Capture expected results, actual results, defects and sign-off. When a defect is corrected, retest the affected process and any connected flow. A successful demonstration is useful, but it is not a substitute for key users completing their own work in the system.
5. Make go-live a readiness decision
A cutover plan needs named owners, a sequence of activities, a communication plan and a decision point for proceeding or postponing. Define the checks for opening balances, outstanding transactions, stock and critical interfaces. Decide what happens if a required check fails.
After launch, provide a clear support route and prioritize issues by business impact. Track whether users can complete their work, whether reconciliations agree and whether temporary workarounds are being closed. Training should continue where real transactions expose a gap in understanding.
Your next project meeting: five questions to ask
- Which measurable business outcomes justify this migration?
- Who owns each critical process and data set?
- Which integrations and exceptions must work on day one?
- What evidence will key users provide before signing off?
- Who makes the final go-live decision, and against which criteria?
Tripearltech can help turn these answers into a discovery scope, migration plan and implementation roadmap. The starting point is understanding your operations and the responsibilities on both sides.
