THE BRAINTREE APPROACH
Assess, Map, Migrate, Extend.
Your NAV environment contains years of business knowledge. The assessment decides which parts still fit and whether an upgrade or a fresh Business Central implementation is the better route. The existing system is evidence, not a reason to start again automatically.
01
Assess
Review the NAV version, customisations, add-ons, integrations and data quality. Establish the migration scope and the decisions that affect cost, continuity and the go-live window.
02
Map
Match each report, workflow and extension to its Business Central equivalent. Review C/AL customisations for supported AL extensions and identify what standard functionality can replace.
03
Migrate
Build, test and reconcile the agreed scope. Business users validate their work before cutover, with a documented recovery plan and a transition sequence the organisation can support.
04
Extend
Once the core is established, assess Copilot, Microsoft Fabric and Power Platform against specific needs. Add capability where it earns its place in the operating plan.
SERVICE SCOPE
What’s in scope.
01
NAV estate assessment
Inventory the NAV version, companies, customisations, integrations, add-ons and reports. Identify the business purpose behind each component, its technical condition and the people who can confirm whether it is still needed.
02
Customisation and extension review
Assess how existing C/AL changes should be treated in Business Central. Some requirements can use standard functionality, others may suit supported extensions or AL development, and unused changes can be retired rather than carried into the new environment.
03
Data and process migration
Map the financial and operational records required in the target system. Define cleansing, reconciliation and acceptance, together with the process changes that affect how finance, inventory, sales, service or project teams will work.
04
Reporting and connected tools
Review Business Central’s relationship with Power BI, Microsoft Fabric, Power Platform and Teams where those tools support a defined requirement. Separate the core ERP transition from optional reporting or automation work so dependencies remain clear.
05
Cutover and continued operation
Build the transition around the organisation’s working cycle, testing and user readiness. Agree the cutover, rollback and support responsibilities, then establish how extensions, platform updates and further improvements will be reviewed.
Upgrade or reimplement: let the assessment decide.
Business Central follows the NAV product lineage, but each installation carries its own data, code and process history. An upgrade route can preserve appropriate design choices. Reimplementation can suit a business whose old configuration no longer reflects its operating model.
✓
A NAV inventory with owners and technical dependencies.
✓
A keep, replace, rebuild or retire decision for customisations.
✓
A recommended route with data and integration boundaries.
✓
A test, migration and acceptance approach.
✓
A TCO model and a delivery scope with assumptions stated.
Use the transition to make deliberate choices.
A migration should not copy every old workaround by default. Review whether each report, integration and extension still serves the business, then decide how it belongs in the target environment. The published Controlgear Instramac story concerns a Great Plains migration completed through a six-month project and a final weekend cutover; it illustrates planning discipline rather than a NAV-specific technical path.
01
Understand the NAV installation you actually run
Two organisations on the same NAV version can have very different migration effort because their custom code, integrations and data history differ. Start with the operating processes and technical changes that distinguish this installation. An old report may be essential to a closing process, while a large customisation may have become redundant as the business changed.
Microsoft documents supported migration paths that depend on source version and target environment. NAV transitions can require intermediate upgrade work and treatment of older custom development. Braintree’s assessment should identify those dependencies from the actual system; product lineage alone is not evidence that a database and all its modifications can move unchanged.
02
Prepare a customisation and data decision register
Bring the exact NAV version and build, object or extension inventory, integration details, add-on licences and current reporting requirements. Include the people who understand rarely used year-end or exception processes. Record which external vendors must confirm that their components support the proposed route.
For each customisation, agree whether to retain its purpose, replace it with standard functionality, rebuild it as supported development or retire it. Define the data and historical-access requirements before choosing migration mechanics. The customer’s finance and process owners should approve reconciliations and critical scenarios. The delivery scope should cover test environments, integration validation, transition preparation and the future maintenance responsibility for extensions that remain.
03
NAV decisions with long-term implications
Decision
Evidence to examine
What to agree
Upgrade or reimplementation
Current process fit, technical route and quality of the existing design.
Which configuration and data choices should continue into Business Central.
Customisation treatment
Business purpose, standard alternatives and supported extension options.
A named decision for each material modification and dependent report.
Historical access
Audit, operational and analytical needs for previous transactions.
The migration boundary and usable access to information left behind.
BEFORE YOU DECIDE
Practical questions.
▸
Does moving to Business Central always mean starting again?
▸
Will every customisation migrate unchanged?
▸
Which support deadline applies?
▸
Can NAV data move directly to the current cloud service?
▸
What happens to C/AL customisations?
▸
Will third-party add-ons keep working?
▸
Can we test migration before the final transition?
BUILD YOUR BUSINESS CASE
Make the next ERP decision with the current business in view.
The problem to solve.
A NAV or GP migration is more than moving balances. Existing reports, customisations and integrations often carry decisions that nobody has documented.
What success should look like.
Agree what to retain, simplify or replace, with tested data migration and a cutover plan that protects the work customers depend on.
Bring these into the discussion.
A useful starting point for your team and the people approving the investment.
Useful reading for your proposal.
Evidence, examples and questions to take into the decision.
Customer story
14 May 2025
Customer story
ControlGear Instramac: planning the move from GP
Follow the preparation and final cutover as separate stages in a real migration.
Read the customer story
Insight
19 August 2026
Migration governance
Govern the risks of leaving GP
Structure the investment case around continuity, ownership and migration readiness.
Read the insight
Insight
3 August 2026
Practical scoping
Decide which GP reports to rebuild
Challenge the report backlog before it becomes migration scope.
Read the insight
LET’S GROW.
Work through the next step with Braintree.
Bring a view of the current estate. We can help identify the decisions that should precede a migration quotation.
