Hi Allen,
For most legacy ERP → Business Central projects, the
best modernization roadmap is usually a phased, disciplined migration program with one decisive cutover, not a “big bang with surprises” and not an endless parallel run.
My short recommendation
- Phase the project, but cut over cleanly once data, integrations, and users are ready.
- Start with discovery + fit/gap + data cleanup, then move to iterative test migrations, UAT, dress rehearsal, and finally a controlled production cutover with hypercare. That pattern is the most repeatable way to reduce downtime, clean up technical debt, and improve adoption quickly. customizations: keep, replace with standard BC, rebuild as extension, or retire. That “keep vs retire” exercise is one of the highest-value activities in a BC modernization.
1) Is a phaan a full cutover?
Best practical answer: phased program, controlled cutover
For Business Central, the most successful pattern is usually:
- Discovery and planning
- Data preparation and cleansing
- Development and mapping
- Repeated test migrations
- UAT and dress rehearsal
- Production cutover in a low-usage window
- Hypercare and closeout
That is effectively a
phased rollout of the work, followed by a
single production go-live. It minimizes business risk better than a purely big-bang project because each rehearsal improves mappings, reconciliations, and runbooks before real users are affected.
When I would avoid a long parallel r often look safe, but in ERP they can create:
- duplicate effort,
- conflicting master data,
- user confusion,
- and delayed decision-making.
A short transition period with the legacy system left
read-only for reference is usually much cleaner than trying to operate two ERPs for too long. Keeping the old system read-only during the first support window is explicitly recommended in migration best practices.
2) How do you decide which legacy customizations to retire?
Use a formal
Fit/Gap and keep-vs-retire review for every meaningful customization. The BC migration guidance is very clear: review each customization and decide whether to:
- keep it,
- replace it with standard BC capability,
- rebuild it as an extension,
- or retire it.
My practical decision filter
Rebuild only if the customization:
- supports a vantage** or legal/compliance need,
- is used frequently enough to justify lifecycle cost,
- cannot be handled well by standard BC + workflow + Power Automate + reporting.
Replace/retire if it:
- exists only because the legacy ERP was weak,
- duplicates standard BC capability,
- is rarely used,
- or makes upgrades harder without clear business value.
Rule of thumb
If a legacy customization mainly compensates for an old process, fix the
process first.
If it supports a core control or differentiator, rebuild it
lightly as an AL extension.
That approach also reduces future upgrade pain, because heavy custom code is one of the main drivers of technical debt and support cost in BC.
3) What is the best data migration strategy, especially for historical records?
Best practneed to operate, not everything you can copy
The biggest hidden risk in ERP modernization is usually
data quality, not the migration tool. Common issues include duplicate customers/items, missing dimensions, invalid master records, and bad inventory/costing setup. These problems are repeatedly identified as major hurdles in NAV/legacy-to-BC projects.
What works best
- Clean master data first
- customers
- vendors
- items
- chart of accounts
- dimensie historical scope early**
Typical successful approaches are:
- master data + opening balances + recent transactions, or
- selegacy system retained read-only.
Full historical migration is possible, but it is slower, riskier, and creates more reconciliation work.
- Run iterative test migrations
Do not do one big cutover. Rehearse:
- dev
- test
- UAT
- dress rehearsal
- production
Each run improves mation.
- Automate reconciliation
Prepare formal reconciliation checks for:
- G/L balances
- inventory valuation
- open AR/AP
- ledgers
My recommendation on history
ict audit or operational requirement, I usually recommend:
- migrate master data + opening balances + 12–24 months of operational history,
- keep the* for deep historical lookup.
That gets you faster ROI and less cutover risk.
4) How do you reduce user resistance and training time?
The most effective levers are:
- Standardize processes before go-live
- Train by role, not by module
- Use real transactions in UAT
- Keep the new design simpler than the old one
- Provide hypercare immediately after cutover
The source guidance explicitly recommends UAT with power users from finance, warehouse, and operations using
real-world transactions and exceptions, plus user training before go-live to reduce support load.
Practical training model
- Power users first
- then short role-based sessions for:
- finance
- sales/customer service
- purchasing
- warehouse/operations
- then quick-reference guides and hypercare support during t### Best adoption trick
Don’t teach “here are all BC menus.”
Teach “here is how your daily work is now done.”
That is much faster and creates less resistance.
5) How to minimize disruption and downtime
A good cutover plan should include:
- pre-cutover backups
- transaction freeze in the legacy ERP
- last-mile data migration
- smoke tests
- rollback plan
- read-only access to legacy
- hypercare ticket triage
All of these are called out as practical migration controls in the BC migration guidance.
Also important
Fast modernization is possible without stopping the business, but only when scope is disciplined and the operating model is clear. The broader Dynamics modernization patterns in your file set reinforce that faster deployments work btion knows exactly what it is fixing and avoids trying to boil the ocean.
6) How to handle integrations during modernization
For your goals, I’d avoid rebuilding every integration exactly as-is.
Recommended approach
- Inventory all integrations:
- CRM
- eCommerce
- payroll
- WMS
- BI
- banking
- For each one, decide:
- keep,
- simplify,
- replace,
- or retire.
A good BC modernization should reduce integration complexity where possible. The integration guidance in your file set supports using:
- Power Platform for lighter workflow automation,
- and API / queue / event-driven patterns for higher-volume or more business-critical integrations.
Key lesson
Don’t migrate old integration chaos into a new ERP.
7) A practical modernization roadmap
Phase 0 – Strategy and discovery
- define business goals and success metrics
- inventory processes, customizations, ISVs, reports, and integrations
- choose SaaS target model and partner
- create the keep/replace/rebuild/retire matrix
Phase 1 – Process and data cleanup
- simplify workflows
- clean master data
- archive or purge obsolete records
- define historical scope
Phase 2 – Solution design
- configure standard BC first
- rebuild only essential customizations as extensions
- redesign integrations where needed
- prepare reporting and security model
igration and testing
- test migrations repeatedly
- run reconciliation scripts
- UAT with real scenarios
- conduct dress rehearsal
Phase 4egacy transactions
- run final migration
- validate smoke tests
- switch users
- keep legacy read-only
Phase 5 – Hypercare and optimization
- 1–4 week hypercare window
- prioritized support backlog
- daily reconciliation during stabilization
- training follow-up and adoption measurement
My strongest lessons learned
- Data clea than system setup.
- Rebuilding every customization is a mistake.
- Repeated dress rehearsals are worth the time.
- Users acce process is simpler, not just newer.
- Hypercare is not optional.
If you want, I can turn this into a
1-page migration runbook with:
- phases,
- owners,
- go/no-go checks,
- and a n matrix for Business Central.
