If You Think of Upgrading, You Should Re-Think Your Customizations

If you’ve ever had to move before, you’ve probably got the stress-induced grey hairs from all the packing, unpacking, coordinating, and transporting of your bubble-wrapped baubles and knick-knacks to prove it! You’ll undoubtedly also be intimately familiar with the unavoidable temptation to throw everything away and not have to deal with any cardboard box-packing tape assemblies ever again! Speak to anyone who’s gone through a move and they’ll tell you the key is to purge as much as possible before even starting the packing process.

The same catharsis applies to the world of systems – if migrating/reimplementing/upgrading is in the tarot cards for you, now is the perfect time to take stock of what you’ve done, what you’re doing, what you want to do, and why. Unless you’re using a purely off-the-shelf product, part of that process will lead you to the ‘custom stuff’ – the assortment of tweaks and tinkering that you’ve done to the base product to accomplish something that the core product either didn’t accomplish or didn’t quite do exactly the way you wanted it to.

There is perhaps no greater community than the Microsoft Dynamics NAV universe where this is prevalent – in all my years of working with NAV clients, I have maybe seen one or two where the client was using the base product with no customizations whatsoever. NAV’s customizability can be considered one of its strongest differentiators in the ERP space… but any partner will vouch that it can also be its biggest long-term headache as well.

So if you’re planning to head to Business Central – take a beat and brew some chamomile because you’ll definitely want to re-assess your customizations!

Customizations in and of themselves are neither bad nor good. If done right, they can add tremendous business value to an organization and can go a long way to solution adoption and happy end-users. However, at its core it also carries costs – not all of which are entirely evident to the untrained eye. The cost of customization, in my mind at least, has three facets:

Upfront costs (typically the effort to license, develop, test, and deploy it);
Ongoing costs (to maintain, support, and upkeep the functionality);
Future costs (to port over/upgrade/retool it);

In an ideal universe you’d have perfect insight into all of the above costs and will be able to come up with a cost/benefit or net present value determination of the customization in mind. But we seldom, if ever, operate under ideal circumstances (as evidenced by the fact that I’m not typing this while soaking up sunshine on a beach in Maui.)

Naturally not all customizations are created equally – some are less invasive and/or take future scalability and upgradeability in mind, while others are, perhaps, less elegant, were worked into very specific outcomes that ignored these considerations, or inherently have a bigger base code-modification footprint. I’m intentionally leaving out the category of complete nightmare customizations that genuinely make you question what on earth the developer was thinking – every Microsoft partner has seen at least one of these during their lifetime.

In my estimation, the most dangerous situation to be in, when operating a customized solution, is to have no idea what’s been done to your system and why. Your implementation partner should have provided you, at some point along the way, with a design document of some sort around customizations.

There are many flavours of these documents in the industry – functional requirements, functional design, technical design, solution blueprint – but the key is to have some form of documentation for you to understand what you’re having built and why.

If you do not have this, it’d be well worth the money to engage with your Microsoft partner to do a bit of analysis and – if even just at a high-level – take stock of what’s been altered in the system and what the alterations are doing.

Once you know where you stand in terms of custom functionality, boil each down to its true business need. Find out where it fits in your processes and, if applicable, find out where it might impact your data or reporting. Is it a custom field you’re tracking that winds up in a report somewhere? Is it an import utility that takes structured data and maps it to some other data for posting to the system? Get intimately aware of what it does and what it results in – it will be important to be able to articulate and conceptualize that with confidence and understanding.

Armed with the knowledge of what your customizations are doing, find out about what the base product does now. Play with the new version (you can spin up a Business Central demo faster than you can make doppio espresso), watch a demo/webinar or two, talk about the product with your Microsoft partner. There is a chance that the functionality you got tailor-made for you a few versions ago might be an out-of-the-box feature now!

Another important thing to do is check the feature roadmap and the Microsoft Ideas forums – if it doesn’t do what your customization does today, is it on Microsoft’s radar? Is there a lot of traction from other people around the functionality? If you can ‘get by’ without your customization in the short-term, some of the identified features in upcoming releases may eventually meet your need – remember that with Business Central you’re now always up-to-date on the latest version!

In addition to that there might be other ideas for features that you might need/like in the future — if so, upvote them!

If after all the above there are still gaps between the base product (and identified future features) and your business needs, retool your customization. By this I mean take a step back, forget how the customization was designed yesterday, have the outcome in mind, and think about how it makes the most sense in the application today.

Did you have a magic button that you’d click to automatically post a batch of unposted sales invoices and then update your hard-coded forecast G/L Budget? Well, since batch posting is out of the box now, maybe strip that portion away. Maybe have a routine you can run where you specify the G/L Budget Name and have a filter for which posted sales invoices to use for the forecast adjustment. Maybe it’s something you want to set on a User Task and assign to your Assistant Controller.

With a fresh understanding of what the new capabilities of the system are, you can better-design and rethink the customization. The example above was a ‘tweak’ to a basic customization, but there might have been a custom function you had to just notify you when someone, for example, changes the Vendor Bank Accounts. Maybe instead of having it be a standalone customization that invisibly runs in the background, you ask for a workflow trigger to be developed and exposed for the Vendor Bank Account so that you can then leverage the workflow engine. Or maybe you utilize Flow for that same purpose. Or maybe you simply activate the change log and have a Power BI report filter for specific changes.

There’s no ‘right’ answer for how to address theses, but chances are that simply ‘porting over’ the customization as-is without thinking it through is the wrong one!

Microsoft has gone a long way to somehow make Business Central both standard enough that there are best practices and methodologies to using the software and flexible enough to be contorted to fit more snowflake-y uses of the system. Where that bend does not suffice, they’ve allowed for the augmentation of functionality in the system, vis-à-vis Extensions, as a versatile and viable option.

However, as with anything that involves building out net-new features, it is important to have a strong design ethic with current and future needs and costs in mind. Historically this has entirely been left to the discretion of the Microsoft partners, however that does not need to be the case. Take an active approach to talking through the design – with a posture of understanding about how the customization dovetails with everything we discussed above. You wouldn’t let your contractor pick out the backsplash would you? Why should a change to your enterprise software be any different?

And just like with the analogy we started out with – don’t be afraid to ask for help from your team and colleagues before and during the move. All it takes is careful planning, determination, and a strong back – and maybe a slice or two of pizza for all the help after the move!