Why you shouldn't heavily customize an ERP
Modifying standard software to accommodate legacy workarounds or unique department habits makes end-user support a nightmare. Every system upgrade ends up taking months of testing to fix broken customizations, which completely halts all new development. You will spend far less time on maintenance if you adapt your internal processes to the software's native workflows instead.
What people tried
Every workaround mentioned in the threads below. We haven’t tested any of them — and nobody here is claiming they worked.
Found another way around this?
Share your steps and trade-offs so fellow engineers don't have to reinvent the wheel. No account required.
- 1Adapting internal business processes to conform to native software flowsDid this help you?
- 2Relying strictly on built-in configuration and no-code optionsDid this help you?
- 3Leaving the core software default and building independent microservices around itDid this help you?
- 4Fixing broken business processes before touching the new systemDid this help you?
- 5Customizing as little as possible to go live, then making iterative enhancements laterDid this help you?
- 6Adopting standard built-in workflows for generic processes like purchasing and AP.Did this help you?
- 7Restricting heavy customisation to processes that provide a unique business advantage.Did this help you?
In their words
Unedited, grouped by where they were said, most upvoted first within each place, each linked to the thread it came from.
“Asking because I keep running into the same thing on requirements lists. A bunch of the "must haves" turn out to be workarounds for stuff the old system couldn't do”source ↗
“Rebuilt a custom PO approval queue because the old system's routing was nonexistent. Spent weeks on scripts and a custom record, then watched a standard workflow do the same thing with a tenth of the maintenance.”source ↗
“I'd rather adapt some internal processes to conform to the native ERP flows, than overly customize and spend so much time figuring out why things broke during upgrades.”source ↗
“We are in this boat, have been for years. We use about 30% of the base functionality of our ERP software, the rest is all customized by 3 of our own developers. To make it worse every company site in the country works on a different database because they work slightly different making end user support a nightmare. It's impossible to keep track of how every department in every one of our offices works slightly differently. And every time we want to move to a newer version it takes about 2-3 months to make sure all customization works in the new version and we also have to halt all new development during that period.”source ↗
“We have a heavily customized D365 FinOps implementation. It is a lot of work. If you can, don’t do it.”source ↗
“My entire ERP is customized. I just do whatever the idiots in charge want. I just try to make it work without my having to fix things everyday.”source ↗
Where this came up
People with this problem also raised
- 2How to customize the UI of software that blocks CSS
- 4How do solo sysadmins handle endless ad-hoc software and system requests?
- 3How to audit unused CRM customizations when the original builder leaves
- 3Why can't accountants open Apple Numbers files?
- 13Why is keeping up with software updates so exhausting?
- 6Why does running a small business feel like drowning in software tools?