Continuity and modernization · Microsoft Dynamics GP, NAV and AX
Your previous ERP does not have to be a risk while you decide the next step
Thousands of companies still run on Microsoft Dynamics GP, NAV or AX because they work and because migrating badly costs more than waiting. BETABOX sustains that operation, keeps it secure and, when you decide, designs the migration to Dynamics 365 Business Central without stopping the business.
Who it is for
Who this is for
For companies running on Microsoft Dynamics GP, NAV or AX that face one of two situations: they were left without a partner to support them, or they need to decide whether and when to migrate. The decision involves the CEO, the CFO and the technology lead, and there is usually a deadline attached.
Signs you need it
- Your previous partner stopped providing support, changed business or no longer responds in reasonable time.
- Nobody inside the company knows in detail the customizations that hold your operation together today.
- The system runs on servers or database versions that no longer receive updates.
- You need to bring the board a well-founded decision on whether to migrate or maintain.
- You are concerned that a failure could stop invoicing and that no tested recovery procedure exists.
- You want to take advantage of the cloud, Power BI or Copilot, but your current ERP connects to nothing.
- You received an end-of-support date and do not know exactly what it means for your operation.
Problems it solves
- A critical operation with no support
- An ERP that invoices, pays and controls inventory cannot depend on someone remembering how it was configured. Without a partner who answers, every incident becomes a business emergency.
- Undocumented customizations
- Years of adjustments made by different providers leave business logic inside the system that nobody can explain. It is the main obstacle to migrating and the main risk if something fails.
- Infrastructure and versions out of support
- Servers, operating systems or databases without security patches turn the ERP into the most likely entry point for an incident — precisely where the most sensitive information sits.
- Technological isolation
- The system does not connect to the cloud, to analytics tools or to digital channels. Every new integration requires development, and information moves by hand.
- A migration decision that keeps getting postponed
- Without a technical and functional assessment, the conversation about migrating repeats every year without moving. The cost of not deciding never appears in a budget, but it is paid in accumulated risk.
- Well-founded fear of a badly executed migration
- Plenty of executives have seen ERP replacement projects that left the operation at a standstill. That fear is reasonable, and it is managed with scope, data and stages — not with promises.
Capabilities by process
Support and continuity
- Incident handling for Dynamics GP, NAV and AX
- Functional support for finance, purchasing, sales and inventory users
- Hands-on support through financial closes and period-end processes
- Backup review and recovery testing
- An escalation procedure with named owners
Maintenance and modernization
- Fixing errors in existing processes and customizations
- Functional adjustments and new requirements on the current system
- Version updates and application of available fixes
- Performance tuning of the database and of heavy processes
- Documenting what is not documented today
Technical and functional assessment
- Inventory of modules, customizations, integrations and reports in use
- Identifying what is genuinely used versus what was inherited
- Review of security, infrastructure and lifecycle risks
- Fit-gap analysis between your current operation and standard Business Central functionality
- A report with the options, the risks and the consequences of each path
Integrations and reporting
- Integration of the current ERP with other systems through controlled interfaces
- Publishing indicators in Power BI over legacy system data
- Automation of peripheral tasks without touching the ERP core
- New financial and operational reports
Migration preparation
- A documented decision on which customizations get rebuilt, replaced by standard functionality or retired
- A data strategy: what gets migrated, what stays available for lookup and what gets archived
- A phased plan with a pilot company or unit
- Parallel operation and tie-out criteria before the cutover
- Definition of the point of no return and the contingency plan
Data and history
- Migration of master data and balances with accounting and inventory tie-out
- Keeping history in a lookup environment when migrating it is not worthwhile
- Data cleanup and normalization before loading
- Traceability between the old record and the new one
Outcomes and KPIs
Continuity sustained while you decide
The operation stops depending on undocumented knowledge. There is a team that answers, an escalation procedure and a tested recovery.
Suggested indicators
- Critical incidents and handling time
- Unplanned ERP outages
- Restore tests performed
- Critical processes documented
Technical risk identified and bounded
The assessment turns a vague concern into a list of concrete risks with their consequence and their mitigation cost. That is what makes a decision possible.
Suggested indicators
- Components out of vendor support
- Vulnerabilities pending remediation
- Customizations without documentation
- Dependencies on a single person
A migration decision backed by evidence
Leadership compares the cost of maintaining against the cost of migrating, with evidence of how the system is actually used and where the concrete gaps are. It stops being a debate about preferences.
Suggested indicators
- Annual cost of maintaining the current system
- Modules and customizations genuinely in use
- Functional gaps against standard Business Central
Migration without stopping the business
A phased plan, with a pilot, balance tie-out and agreed cutover criteria, brings the risk down to something manageable. The goal is not to migrate fast: it is not to stop invoicing.
Suggested indicators
- Days of affected operation during the cutover
- Differences found during the balance tie-out
- Critical processes validated before go-live
- Issues in the first financial close afterward
How BETABOX works
Stabilize first
Before talking about migrating, we make sure the operation is held up: incidents handled, backups verified, access in order and critical processes documented. The initial assessment is 100% free.
Assess the current environment
We document modules, customizations, integrations, reports, infrastructure and actual usage. The point is to know what holds your operation up today and what was inherited and nobody uses.
Present the options with their consequences
We deliver a report with the possible paths — maintain, update the version or migrate to Business Central — each with its risk, its effort and what it means for the operation. The decision is yours, and you make it with information.
Design the migration when the time comes
We define which customizations get rebuilt, which ones standard functionality replaces and which ones are retired; which data gets migrated and which stays available for lookup; and which unit or company serves as the pilot.
Execute in stages and tie out
We migrate in stages, with parallel operation where necessary, accounting and inventory balance tie-out, and cutover criteria agreed before moving forward. The point of no return is decided on evidence.
Stay with you after the change
We train by role, stay through the first closes and maintain 24/7 support with a response time under 1 hour. The migration ends when the first close goes well, not when the system turns on.
Integrations
- Dynamics 365 Business Central as the migration destination
- Power BI for indicators over your current system’s data
- Power Automate and Power Apps for peripheral processes without touching the ERP core
- Microsoft 365 for documents, approvals and communication
- Microsoft Azure to host the current environment or the historical lookup environment
- Third-party systems through controlled, documented interfaces
Security, governance and local adaptation
- Product lifecycle
- Dynamics GP, NAV and AX versions have end-of-support dates defined by Microsoft. We review with you, against the current official documentation, which one applies to your version and what it means in practice for security and compliance.
- Security of the legacy environment
- We review access, privileged accounts, internet exposure, the patch status of the infrastructure and backups. An ERP without support does not have to be an unprotected one.
- Retention of historical information
- We define with you which history must stay accessible and for how long, and how it is kept queryable if it is not migrated. Legal retention periods are validated with your accounting and legal counsel.
- Documentation as a deliverable
- Everything we learn about the environment is documented and stays with your company. Dependence on a provider is itself a risk, and we work to reduce it.
FAQ
Frequently asked questions
- Do you support Dynamics GP, NAV and AX even if we did not implement with you?
- Yes. A good share of this work starts with companies whose previous partner stopped providing support. The first stage is always to document the environment, because without that it is not possible to sustain the operation seriously.
- Do we have to migrate to Business Central?
- No. For some companies, maintaining and securing the current system is the right decision for a while. What we do recommend is making that decision with an assessment behind it and with the product lifecycle dates in view, rather than by inertia.
- What happens to the customizations we have today?
- They are classified one by one: those already covered by standard Business Central, those rebuilt as extensions, those solved with Power Platform, and those simply retired because nobody uses them. In practice, that last category is usually larger than expected.
- Do we lose our history if we migrate?
- Not necessarily, but migrating all of it is not advisable either. Master data and balances are migrated with an accounting tie-out, and the earlier history is kept accessible for lookup and audit. We decide together what you genuinely need inside the new system.
- How long does a migration from GP, NAV or AX take?
- It depends on the number of companies, on the volume and condition of the data, on how many customizations exist and on your team’s availability to validate. We do not commit to a date before the assessment: doing so is the fastest way to make a migration project go wrong.
- Can we run both systems at once during the transition?
- In many scenarios yes, and it is advisable when there are several companies or units. One is migrated as a pilot, the full close is validated, and then the rest follow, with defined cutover criteria.
- What does end of support for a version mean?
- It stops receiving fixes and security updates from the vendor, which raises the risk and can affect compliance in regulated industries. We review Microsoft’s current official documentation for your specific version with you, and what the consequences are in your case.
- Can you help us present the decision to the board?
- Yes. The assessment ends in a report with options, risks, effort and implications for the operation, written to support a committee decision, not to justify a sale.
Who answers today if your Dynamics GP, NAV or AX goes down?
Request an assessment of your current Dynamics. We document your environment, identify risks and hand you the options with their consequences — including not migrating yet. The initial assessment is 100% free.
Contact
Request a complimentary assessment
Tell us what your company needs and a BETABOX advisor will get in touch to schedule a call at your convenience. The initial assessment is 100% free of charge.
- +1 (754) 209-2071
- Bookings
- Book directly on the calendar