If your company has been running Dynamics GP for years, there’s a good chance you’ve invested in more than just the software itself. You’ve also invested in custom reports, specialized workflows, integrations, unique data structures, and other modifications designed to support the way your business operates.
That naturally leads to one of the most common questions organizations ask when considering an ERP migration:
“What happens to all our Dynamics GP customizations?”
It’s a fair concern. Many of those customizations represent years of accumulated business knowledge. Some support critical processes. Others have become so ingrained in daily operations that employees can hardly imagine working without them.
The good news is that moving to a new ERP doesn’t automatically mean losing the capabilities those customizations provide. But it creates an opportunity to take a fresh look at why those customizations exist and whether they still make sense.
Standard functionality in the new ERP may replace some customizations. Your implementation team may recreate others differently. You may still need to rebuild some. And you may no longer need others at all.
Understanding the difference can help you avoid unnecessary costs, simplify your future environment, and get more value from your ERP investment.
In this article, we’ll look at what typically happens to Dynamics GP customizations during a migration, how to evaluate what should move forward, and how to avoid carrying unnecessary complexity into your next ERP system.
The short answer: You’re usually not moving the customization. You’re preserving the capability.
Let’s start with the direct answer.
Most Dynamics GP customizations do not transfer to a new ERP unchanged.
That’s true whether you’re moving to Acumatica, Business Central, or another modern ERP platform.
Developers built many Dynamics GP customizations specifically for GP’s architecture, database structure, and development framework. As a result, they typically cannot simply move the original code into a replacement system.
The more important question isn’t whether the customization itself survives. It’s whether the business need behind it still exists.
For example, a company may have created a customization because it needed a more efficient approval process. When moving to a new ERP, the goal shouldn’t be to recreate that customization exactly as it exists today. The goal should be to make sure the approval process still works effectively in the new system.
A modern ERP may provide that capability through standard functionality, configurable workflows, automation tools, or a different process entirely.
This distinction is important because many organizations begin a migration assuming they need to reproduce everything they have today. In reality, a migration is an opportunity to evaluate which customizations still create value and which ones have become unnecessary.
Some Dynamics GP customizations will still deserve a place in the new environment. Standard functionality or a simpler process may replace others.
The organizations that get the most value from ERP modernization focus on preserving business outcomes rather than recreating every technical detail of their old system.
Before deciding what should happen to a customization, you need to understand why the company created it.
Why Dynamics GP customizations exist
Most companies don’t customize an ERP system because they want something unique. They customize it because they’re trying to solve a business problem.
Over time, those solutions accumulate. A company may customize Dynamics GP to support a process that the standard system doesn’t handle well, reduce manual effort, or accommodate the way the business operates. Years later, those customizations can become such a normal part of daily operations that nobody remembers why they exist.
In our experience, most Dynamics GP customizations fall into one of four categories.
Filling functional gaps
No ERP system is perfect for every business.
Companies created many Dynamics GP customizations because they needed additional functionality, more detailed controls, industry-specific capabilities, or processes that standard GP couldn’t handle.
In these situations, customization allowed the business to adapt the software to its requirements instead of adapting the business to the software.
Eliminating manual work
Another common reason for customization is efficiency.
Organizations often develop custom workflows, automation, and data-entry enhancements to reduce repetitive work, eliminate duplicate effort, and improve accuracy.
These customizations frequently provide real value because they help employees spend less time managing transactions and more time focusing on high-value work.
Supporting unique business processes
Every business develops its own way of getting work done.
Sometimes those processes create a genuine advantage. Other times, they reflect industry requirements, operational constraints, or customer expectations that standard ERP functionality doesn’t address.
In these cases, customizations often become deeply embedded in daily operations because they support the processes that make the business run.
Temporary workarounds that became permanent
This is perhaps the most interesting category.
Many customizations begin as temporary fixes. A business encounters a problem, creates a workaround, and plans to revisit it later.
But later never comes.
Employees get used to the process. Teams update the documentation and train new hires. Eventually, the workaround becomes the accepted way of doing things.
Years later, those temporary fixes can look just as important as the customizations that support critical business functions.
Not every customization deserves the same treatment
Before deciding whether a customization should be rebuilt, replaced, reconfigured, or retired, it’s important to understand what problem it was originally created to solve.
Only then can you determine whether that problem still exists and whether the customization deserves a place in your future ERP environment.
The four possible outcomes for every customization
Once you’ve identified why a customization exists and what problem it solves, the next step is determining what should happen to it during the migration.
Many organizations assume they have only two options: keep a customization or lose it.
In reality, most Dynamics GP customizations fall into one of four categories.
1. Replace it
This is often the best-case scenario.
Many Dynamics GP customizations were created because GP lacked functionality that modern ERP systems now provide as standard.
For example, a company may have built custom approval routing, document management processes, dashboards, or workflow automation because GP couldn’t handle those requirements natively.
When evaluating a new ERP, you may discover that the functionality already exists as part of the standard product.
In that situation, rebuilding the customization usually makes little sense. The business need still exists, but the customization does not.
For many organizations, this is one of the biggest benefits of ERP modernization. Functionality that once required custom development is now often included in the platform.
2. Reconfigure it
Sometimes the business requirement still exists, but the new ERP handles it differently.
Rather than rebuilding a customization from scratch, the implementation team can recreate the capability through settings, workflows, automation tools, or standard integrations available within the new platform.
The screens may look different. The steps may occur in a different order. But the business outcome remains the same.
This approach often provides the best balance between meeting business requirements and maintaining a system that is easier to support.
3. Rebuild it
Not every customization should disappear.
Some organizations have processes that are genuinely unique, industry-specific, or closely tied to the way they deliver value to customers.
In those situations, rebuilding functionality may be the right decision.
This category is typically reserved for customizations that:
- Support a unique business process
- Address industry-specific requirements
- Provide a competitive advantage
- Cannot be addressed through standard functionality or configuration
The key is being selective. Business value, not familiarity, should drive the decision to rebuild.
4. Retire it
This is often the category that surprises organizations the most.
Over the years, businesses accumulate temporary fixes, special reports, manual procedures, and custom features that seemed important at one point but gradually lost relevance.
Yet, because they still exist in the system, many people assume they must be preserved.
A migration creates an opportunity to challenge that assumption.
Ask questions such as:
- Is anyone actively using this customization?
- Does it solve a problem that still exists?
- Has the business process changed since it was created?
- Would anyone miss it if it disappeared?
Sometimes the honest answer is that the customization has outlived its usefulness.
Retiring unnecessary customizations can simplify the new environment, reduce maintenance costs, improve usability, and make future upgrades easier.
A framework for better decisions
The goal of this exercise is not to determine whether a customization survives.
The goal is to determine which of these four outcomes makes the most sense.
Standard functionality will replace some customizations. Teams will reconfigure some and may need to rebuild a few. They should retire the rest.
Understanding those possibilities helps organizations approach ERP migration strategically rather than assuming every customization deserves the same treatment.
Don’t confuse familiar with necessary
One of the biggest mistakes companies make during an ERP migration has nothing to do with technology.
It happens when people assume that because a process is familiar, it must also be necessary.
After years of using Dynamics GP, employees become accustomed to specific screens, reports, workflows, and procedures. Over time, those customizations stop feeling like modifications and start feeling like part of the business itself.
That can make it difficult to evaluate them objectively.
Every customization solved a problem. But does that problem still exist?
Companies created most Dynamics GP customizations for a legitimate reason. The customizations solved a business problem, supported a process, or worked around a system limitation.
The challenge is that businesses change.
Processes evolve. Responsibilities shift. New technology becomes available.
A customization that was essential ten years ago may not be essential today.
That’s why one of the most valuable questions you can ask is:
“If we were implementing a new ERP today, would we build this again?”
Sometimes the answer is yes.
Sometimes the answer is no.
Complexity is not the same as value
Another common mistake is assuming that a complicated process must be an important one.
In reality, some of the most complex customizations exist because developers designed them to compensate for limitations in older technology.
The underlying business requirement may still be important. The complexity built around it may not be.
A migration provides an opportunity to separate the two.
Rather than asking whether you should preserve a customization exactly as it exists today, ask whether there is a simpler way to achieve the same result.
Beware the “we’ve always done it this way” trap
This is where many organizations struggle.
For example, imagine a company that had built project costing directly into an extremely complex chart of accounts. A simpler approach was available, but the organization resisted making the change because they had always operated that way.
That example highlights a challenge that appears in many ERP projects: people become attached to the solution rather than the outcome the solution was created to achieve.
When that happens, modernization becomes harder than it needs to be.
Instead of asking:
“How can we recreate this exact process?”
A better question is:
“What’s the simplest and most effective way to accomplish this goal today?”
Improvement should be the goal
A successful ERP migration should preserve the capabilities that help the business succeed while creating opportunities to simplify what no longer adds value.
Some Dynamics GP customizations will absolutely deserve a place in the new environment.
Teams may replace, reconfigure, or retire others.
The challenge is determining which customizations support a genuine business requirement and which ones have simply become familiar over the years.
Because one of the greatest benefits of ERP modernization isn’t recreating the past.
It’s leaving behind complexity that no longer serves the business.
Reports, integrations, and add-ons deserve special attention
When organizations think about Dynamics GP customizations, they often focus on changes made directly inside GP.
However, some of the most important pieces of a GP environment exist outside the ERP itself. Over the years, companies build reports, integrations, third-party applications, and spreadsheets that become part of how the business operates.
Those components deserve their own review during a migration.
Reports
One of the most common concerns during an ERP migration is whether custom reports will survive.
The better question is whether the information those reports provide will still be available.
Buyers sometimes place too much emphasis on recreating specific reports instead of focusing on the information they need to do their jobs. Modern ERP systems often provide multiple ways to access and analyze the same data.
Before rebuilding a report, determine what decisions it supports and whether the new ERP already provides that information in another way.
Integrations and add-ons
Many GP environments exchange data with other systems such as CRM software, payroll applications, ecommerce platforms, manufacturing solutions, and banking tools.
Likewise, many companies rely on third-party applications that extend GP’s functionality.
Before assuming you need to recreate these components, identify the business requirement they support. Some may still be essential. Functionality already available in the new ERP or a simpler integration approach may replace others.
The goal is to preserve the capability, not necessarily the exact solution.
Don’t forget the spreadsheets
Some of the most important “customizations” in a Dynamics GP environment may actually live in Excel.
Over time, spreadsheets often become reporting tools, workflow trackers, and workarounds for limitations in the ERP. We frequently see organizations relying on combinations of systems, spreadsheets, and manual processes to fill operational gaps.
During migration planning, identify spreadsheets that are critical to daily operations. Some may remain useful. Others may represent opportunities to automate manual work and simplify processes.
The important thing is understanding how people actually get their work done, not just what exists inside Dynamics GP.
Why change management matters more than most companies expect
Evaluating Dynamics GP customizations isn’t just a technology exercise. It’s also a people exercise.
Even when a new ERP provides the same capability, employees may need to learn a new process, use different screens, or access information in a new way. That’s why change management should be part of the customization discussion from the beginning.
Training is often a bigger concern than technology
It’s understandable that concerns about training frequently surface during ERP evaluations. Many organizations worry about the time required to train employees, the impact on productivity, and whether long-time users will be comfortable learning a new system.
These concerns are valid.
Employees who have spent years working in Dynamics GP often have deeply rooted routines. Even when a new ERP improves the process, there is still a learning curve.
Don’t rebuild a customization just to avoid training
When organizations encounter user concerns, it can be tempting to recreate existing customizations simply because employees are familiar with them.
However, familiarity alone is rarely a good reason to carry complexity into a new system.
If a modern ERP can accomplish the same business objective through standard functionality, rebuilding a customization solely to preserve an old process may increase future maintenance costs without providing meaningful business value.
Instead, focus on helping users understand how the new process works and why the organization is making the change.
Start the conversation early
As you review customizations, identify the people who use them most and consider how the migration will change their work.
Questions such as these can help uncover potential adoption challenges early:
- Who relies on this customization today?
- How often do they use it?
- What will change in the new ERP?
- What training or communication will be needed?
Addressing these questions during planning is usually far easier than addressing them after go-live.
Technology doesn’t drive adoption. People do.
A successful ERP migration requires more than good software decisions. It requires helping employees understand and embrace new ways of working.
The organizations that achieve the best results don’t try to preserve every familiar process. They focus on preserving the capabilities the business needs while giving employees the training and support needed to succeed in the new environment.
Questions to ask before deciding a customization’s fate
Once you’ve identified your Dynamics GP customizations, the next step is deciding which ones deserve a place in your future ERP environment.
That evaluation doesn’t have to start with technical questions. In most cases, the most important questions are business questions.
Use the following framework to assess each customization before deciding whether to replace, reconfigure, rebuild, or retire it.
Who uses it?
Start by identifying who relies on the customization and how often they use it.
A customization used every day by multiple departments deserves a different level of attention than one used occasionally by a single employee.
What problem does it solve?
Every customization was created for a reason.
Ask yourself:
- What business challenge prompted this customization?
- What would happen if it disappeared?
If no one can clearly explain the problem it solves, that’s often a sign it deserves closer examination.
Is the problem still relevant?
Businesses change over time.
A customization that was essential when the company implemented it may no longer address a current need.
Ask: If we were implementing GP today, would we build this again?
The answer can be surprisingly revealing.
Does the new ERP already solve it?
Before investing time and money into rebuilding a customization, determine whether the new ERP already provides the capability through standard functionality, configuration, or workflow tools.
Remember, the goal is to meet the business requirement, not necessarily recreate the existing solution.
Is it creating business value or just preserving familiarity?
Some customizations improve efficiency, reduce risk, support decision-making, or provide a competitive advantage.
Others continue to exist simply because people are accustomed to them.
Familiarity alone is rarely a strong justification for rebuilding a customization.
Is it worth supporting long term?
Every customization creates ongoing maintenance obligations.
Before carrying it forward, ask:
If this customization didn’t exist today, would we be willing to invest money to build and maintain it?
That question often separates essential functionality from unnecessary complexity.
What happens if we remove it?
Finally, consider the impact of eliminating the customization altogether.
- Would business operations suffer?
- Would compliance be affected?
- Would employees lose a critical capability?
Or would people simply need to adapt to a different process?
Understanding the consequences helps distinguish between true business requirements and preferences.
A simple assessment checklist
For every Dynamics GP customization, ask:
- Who uses it?
- What problem does it solve?
- Is that problem still relevant?
- Does the new ERP already solve it?
- Is it creating business value or preserving familiarity?
- Is it worth supporting long term?
- What happens if we remove it?
The answers will usually point toward one of the four outcomes discussed earlier: replace it, reconfigure it, rebuild it, or retire it.
More importantly, they help ensure decisions are based on business value rather than assumptions.
Wrapping up
The real question isn’t whether you can keep your Dynamics GP customizations.
It’s whether the business capabilities behind those customizations still deserve a place in your future ERP.
Functionality built into a modern ERP will replace some customizations. Teams can reconfigure some through workflows, automation, or integrations. They may need to rebuild a few. Others may have outlived their usefulness altogether.
The organizations that get the most value from ERP modernization don’t start by asking how to recreate everything they have today. They start by understanding which processes create real business value and then determine the best way to support those processes moving forward.
If you’re evaluating a move away from Dynamics GP, don’t assume every customization needs to survive unchanged. A thoughtful assessment can often simplify your environment, reduce future maintenance costs, and help you take advantage of capabilities that didn’t exist when developers created many of those customizations.
Need help evaluating your options?
Our team has helped organizations assess their Dynamics GP environments, identify which customizations still add value, and develop practical migration strategies that balance business requirements, user adoption, and long-term maintainability.
Whether you’re considering Acumatica, another modern ERP platform, or simply trying to understand what a migration would involve, we’re happy to help.
Schedule a discovery call to discuss your Dynamics GP environment, review your customizations, and get expert guidance on the best path forward for your business.
Frequently Asked Questions About Dynamics GP Customizations and ERP Migration
Can Dynamics GP customizations be migrated to a new ERP?
Sometimes, but not usually in their original form.
Most Dynamics GP customizations were built specifically for GP’s architecture and development framework. During an ERP migration, the focus should be on preserving the business capability the customization provides rather than transferring the underlying code. Depending on the requirement, a customization may be replaced, reconfigured, rebuilt, or retired.
Will I lose my Dynamics GP customizations if I move to Acumatica?
Not necessarily.
Many business requirements currently supported by Dynamics GP customizations can be handled through Acumatica’s standard functionality, configurable workflows, integrations, or reporting tools. Some highly specialized customizations may still require additional development, but many organizations discover that fewer customizations are needed in a modern ERP.
Should every Dynamics GP customization be rebuilt after migration?
No.
Rebuilding every customization can add unnecessary cost, complexity, and future maintenance requirements. A better approach is to evaluate each customization individually and determine whether it still provides business value or whether a simpler solution is available in the new ERP.
How do I know which Dynamics GP customizations are still necessary?
Start by asking:
- Who uses the customization?
- What problem does it solve?
- Does that problem still exist?
- Does the new ERP already provide the same capability?
If a customization no longer supports a meaningful business requirement, it may not be worth carrying forward into the new system.
What happens to custom Dynamics GP reports during migration?
The reports themselves may not transfer directly, but the information they provide can usually be recreated.
Many modern ERP systems offer dashboards, ad hoc reporting tools, inquiries, and analytics that provide the same information in different ways. When evaluating reports, focus on the business decisions they support rather than the exact format of the report.
What happens to Dynamics GP integrations and third-party add-ons?
Every integration and add-on should be evaluated individually.
Some may still be required in the new environment. Others may be replaced by native ERP functionality, updated integration tools, or alternative solutions. The key is understanding the business purpose behind each integration before deciding how it should be handled.
Can a modern ERP replace Dynamics GP workarounds?
Often, yes.
Many organizations have developed workarounds in Dynamics GP to compensate for limitations, manual processes, or reporting challenges. Modern ERP platforms frequently provide capabilities that eliminate the need for those workarounds, reducing complexity and improving efficiency.
Why is customization assessment important before a Dynamics GP migration?
Customization assessment helps organizations avoid blindly carrying old processes into a new system.
By reviewing customizations before migration, businesses can identify which ones still provide value, reduce unnecessary development costs, simplify future maintenance, and take better advantage of modern ERP capabilities.
How do customizations affect ERP migration costs?
Customizations are often one of the biggest factors influencing migration scope and cost.
The more custom functionality that must be rebuilt or redesigned, the more time and effort the project may require. That’s why organizations should evaluate whether a customization still delivers meaningful business value before investing in recreating it.
What is the first step in evaluating Dynamics GP customizations?
Create an inventory of your customizations, reports, integrations, add-ons, and spreadsheet-based processes.
Then review each item using a simple framework:
- What problem does it solve?
- Who uses it?
- Does the problem still exist?
- Does the new ERP already provide the capability?
This helps establish whether the customization should be replaced, reconfigured, rebuilt, or retired.
Do I need to recreate my Dynamics GP system exactly in a new ERP?
Usually not.
One of the most common ERP migration mistakes is assuming the new system must work exactly like Dynamics GP. Modern ERP platforms often provide different ways to accomplish the same business objectives. The goal is to preserve the capabilities your organization needs, not necessarily recreate every workflow, report, or customization exactly as it exists today.
