The workarounds that run your plant made sense when you built them. An extension model lets you keep the ones that matter and still take every update.
There's a custom report that only runs on one person's machine. There's a scheduling tweak someone coded years ago, and a spreadsheet that carries data from the ERP to the floor every morning. Each one solved a real problem. Together, they now decide how fast your plant can change.
Most custom code in a plant starts the same way. The ERP didn't fit how you build, so a sharp person on your team made it fit. That's a sign of a team that solves problems, and you're far from alone. IDC research reported by CIO.com found that 51% of organizations still prefer a customized ERP approach.
The catch shows up later. Each fix adds a dependency. The person who wrote it moves on. The workaround becomes the process, and new hires learn the workaround instead of the system.
From an operations seat, it looks like waiting. You want to add a work center, change a routing, or bring on a new product line. Instead of a configuration change, you get a ticket, a quote from a developer, and a test cycle. The plant adapts to the code instead of the other way around.
The same pattern shows up when companies replace the system. The most common reason projects run over budget is an unexpected need for additional technology, which links to fit gaps found late and the custom builds that follow. Knowing what your custom code does, before you move, is how you avoid that.
Older ERP platforms let developers change the base application directly. That's called overlayering. It works until the vendor ships an update, and then every modified object has to be compared, merged, and retested. So the upgrade gets pushed to next year. Then the year after. That's upgrade paralysis, and it's why so many plants run versions several releases behind.
Dynamics 365 handles this differently. In Dynamics 365 Business Central, customizations are built as AL extensions that sit alongside the base application instead of rewriting it. Microsoft can update the core without touching your code. Dynamics 365 Finance & Supply Chain Management uses an extension-only model with the standard application sealed, and delivers One Version continuous service updates that are built to stay backward compatible.
Extensions still need testing. A good partner runs your extensions against each update before it reaches production. The difference is that testing becomes routine maintenance, not a multi-month project.
Microsoft now builds AI directly into its ERP, including Copilot in Dynamics 365 Finance & Supply Chain Management and Copilot features in Dynamics 365 Business Central. Those capabilities arrive through updates. If your system is three versions behind, so is your access to them.
Old code also makes AI harder to adopt once you get there. IBM research cited by CIO.com found that unaddressed technical debt can consume 18% to 29% of AI implementation costs. Clean extensions and current software give your team a much shorter path to using AI on real plant data. Western Computer is a member of Microsoft's Inner Circle for AI Business Solutions, and the pattern we see is simple: plants that stay current get to AI first.
You don't have to give up the custom work that makes your plant competitive. You do have to know what you have. A practical first step is to list every customization, report, and bridging spreadsheet, then put each one in one of three bins:
National Guard Products, a manufacturer with more than 20,000 configurable products, used to run critical bill-of-material and inventory work in spreadsheets and people's heads. On Dynamics 365 Business Central with an integrated product configurator, that work now runs inside the system on live data.
The sort also tells you which product fits. If most of your custom work is about configuration and a single plant, Dynamics 365 Business Central is often the right size. If it's about multi-site planning, complex costing, or enterprise scale, Dynamics 365 Finance & Supply Chain Management tends to handle it with less custom code. Our guide to right-sizing Dynamics 365 for manufacturing walks through the tradeoffs.
Yes, the ones you still need. They get rebuilt as extensions, which keeps them separate from the base application, so they survive updates. Many older customizations turn out to be covered by standard features and can be retired.
Overlayering changes the vendor's code directly, so every update has to be merged by hand. Extensions add behavior next to the vendor's code, so updates can apply without rewriting your changes.
No. Extensions should still be tested against each update. The work is smaller and predictable, so it fits into normal maintenance instead of becoming a major project.
Over nearly 40 years and 1,750+ implementations, we've helped manufacturers sort the custom work worth keeping from the work that's holding them back. If you'd like a clear view of your own system, start with a Dynamics 365 assessment.