We’re building a custom maintenance management module in D365 F&O 10.0.41 and I’m concerned about our model structure causing upgrade problems down the line. Currently using the CUS layer for our custom objects, but we’ve already hit conflicts with overlayering during our last platform update.
Our model contains custom tables for equipment tracking, maintenance schedules, and work order workflows. We’re modifying some standard maintenance management forms and added new menu items. The team is split on whether to use publisher prefixes consistently - some objects have our company prefix, others don’t.
We’re also not sure about the best approach for extending vs. overlaying standard objects, and our source control setup in Azure DevOps feels fragile. What’s the recommended structure to avoid upgrade conflicts while keeping our customizations maintainable?
You don’t have to rebuild from scratch, but you do need to refactor. Export your custom objects, create the new model with proper publisher prefix, then recreate objects as extensions where possible. For custom tables and classes, you can copy the code but rename with your prefix.
Direct modification should only exist in your custom objects, never in standard ones. Use extensions and CoC patterns exclusively for standard object modifications. The refactoring typically takes 2-3 weeks for 45 objects depending on complexity. Document your dependencies carefully during migration.
Thanks for the responses. So if I understand correctly, we need to create a completely new model outside the CUS layer? What happens to our existing customizations - do we have to rebuild everything from scratch? We have about 45 custom objects including tables, forms, and classes. Is there a migration path or do we start over?
First red flag - you’re still using the CUS layer. Microsoft deprecated overlayering in favor of extensions starting with version 8.0. For 10.0.41, you should absolutely be using extension-based customization. The CUS layer will continue causing upgrade conflicts because you’re directly modifying metadata.
Create a new model in your own model layer (not CUS/USR/VAR). Use a publisher prefix consistently across ALL objects - tables, forms, classes, everything. This prevents naming conflicts and makes your customizations easily identifiable.
I went through this exact scenario last year. We had to refactor our entire maintenance module from overlayering to extensions. The effort was significant but worth it - our last three platform updates went smoothly with zero conflicts.
Key lesson: Never modify standard forms directly. Use form extensions, event handlers, and Chain of Command for business logic. Our equipment tracking now uses pure extensions with augmented data sources. Took longer initially but maintenance is much easier.