Beyond the implementation: Navigating the hard realities of Microsoft Business Central

Moving to Microsoft Business Central (BC) Cloud is a significant transformation that promises modernised operations, streamlined workflows, and an “evergreen” technology landscape. However, what we consistently hear from organisations using BC across New Zealand is that the journey to the cloud is rarely without its hurdles.

Whether your organisation is seeking to improve user adoption, streamline processes, or support the next stage of business growth, the challenges encountered along the BC journey are often remarkably consistent. Through our years of quality assurance (QA) consulting on ERP and CRM transformations, we repeatedly see organisations stumble not on the technology itself, but on the processes surrounding its implementation.

If you are embarking on a BC implementation or struggling to maintain one, it’s time to take a critical look at how you operate. Here are the core challenges you must navigate, the hard truths of cloud ERPs, and a checklist to safeguard your investment.

1. The agile illusion: Vague design, abdicated ownership, and late QA

A recurring issue in ERP projects is starting with a vague solution design. Teams often rely too heavily on refining the solution during agile sprints, believing they will naturally figure it out by the end of their iterations. In reality, this pushes the definition of crucial end-to-end business processes to the very last minute, causing significant project delays.

To succeed, the business itself must rise to the challenge of the transformation program. If the business abdicates the ownership of process design to the System Implementer (SI), driving user adoption down the track becomes incredibly difficult.

Compounding this issue is the tendency to bring QA into the process at the eleventh hour. Detecting defects late inevitably leads to an increase in the cost and effort required to fix, retest, and re-develop solutions. When QA is an afterthought, project timelines slip and financial pressures mount.

The expert view: An IT Manager at a prominent retail and design business shared a valuable perspective on this dynamic. To complement their implementation partner’s technical expertise, they brought on a dedicated project manager to deeply document and map out their internal business processes ahead of the upgrade. By taking proactive ownership of their operational scenarios, they could collaborate more effectively with the SI and execute internal testing with a much higher success rate.

However, for many mid-market organisations, dedicating a full-time resource to lead this is a luxury. In these cases, engaging an independent partner to “co-pilot” the process ensures business scenarios are clearly documented and aligned with the implementation, keeping the project moving smoothly without overextending internal budgets.

2. The collaborative approach: Partnering for quality

Organisations frequently over-rely on their System Implementers (SIs) to perform testing. While your SI partners are undoubtedly the technical experts in the room, asking them to test their own configurations creates a fundamental conflict of interest. SIs are generally incentivised to deliver on specific milestone dates to unlock payments. Relying on them to also act as the primary quality gatekeeper is akin to asking them to mark their own homework.

The expert view: True quality assurance requires independence. When SIs are forced to juggle milestone payments against rigorous testing, quality naturally suffers. Leveraging an independent quality assurance partner ensures that the solution is delivered with the necessary quality measures in place, removing the dissonance between hitting a deadline and delivering a robust system. In the tight-knit New Zealand tech ecosystem, independent QA shouldn’t be adversarial; rather, it is a way to help your SI partner succeed by removing the testing burden so they can focus on delivering brilliant configurations.

3. The evergreen tax: Customisation vs configuration

The reality of a cloud-based ERP like Business Central is continuous change. Microsoft pushes major updates twice a year, alongside frequent minor patches, all of which you must seamlessly absorb. Furthermore, third-party marketplace extensions update independently of Microsoft’s schedule, requiring constant vigilance. A Business Systems Manager for a diverse holdings group, managing hundreds of users across multiple sectors, highlighted the very real struggle of simply keeping up with the constant barrage of new releases and features.

This evergreen environment heavily penalises over-customisation. Organisations often trip themselves up by trying to force their legacy, current-state business processes into the new system, resulting in highly customised solutions rather than utilising out-of-the-box functionality. High customisation dramatically increases the maintenance effort required for test automation and makes navigating continuous updates incredibly painful.

The expert view: Instead of custom-coding every gap, savvy organisations are leveraging the wider Microsoft ecosystem. One retail company replaced clunky on-prem custom code with off-the-shelf AppSource solutions to handle complex printing requirements. Similarly, a regional telecommunications provider noted that the BC Cloud environment allows them to spin up sandboxes and test AppSource extensions safely, avoiding the fixed development costs of their old on-prem days. Others are stepping outside of BC entirely for complex workflows, utilising Power Automate to scrape vendor invoices or Microsoft Fabric to ingest and report on complex data tables.

4. Pragmatic QA: Smarter, risk-based testing

For a SaaS solution, exhaustive testing is impossible. To survive the implementation and subsequent update cycles without burning out your team or resorting to a costly army of manual testers every month, you need a smarter approach to User Acceptance Testing (UAT) and regression testing (the process of verifying that a recent change or update hasn’t broken your existing, working functionality).

We have seen organisations realise post-implementation that they have zero automated test scenarios, forcing them to deploy a team of five to ten manual testers for a full month just to safely accept a routine update. That approach becomes very expensive, very quickly. You need to automate your core regression testing, but remember that test automation requires maintenance – effort that skyrockets if your solution is highly customised.

You cannot set and forget your testing strategy. You must actively assess exactly what each update changes and understand the specific risks to your organisation. This is where specialised solutions like AutomationFlex become invaluable. By leveraging a robust, scalable framework, you can build maintainable automated test suites that easily adapt to BC’s continuous update cycle without the heavy maintenance burden of highly customised, brittle code.

The expert view: The aforementioned retail company took a pragmatic, risk-based approach. They stripped their regression testing back to just the absolute essentials. If those core processes pass, they go live with the update and handle the minor bugs later. It’s all about limiting the “blast radius”, ensuring that if something does break, the impact is minimal and critical operations keep running smoothly.

The BC implementation survival checklist

To help you stay grounded and ensure your BC investment actually delivers the promised value, we have compiled a checklist based on the hardest-learned lessons in the industry:

• Own your business processes: Have you mapped your future-state end-to-end business scenarios internally, or are you relying entirely on your SI to tell you how your business should run?
• Establish independent QA early: Is your QA team engaged during the solution design phase, or are they waiting at the end of the line to catch defects when they are most expensive to fix?
• Prioritise independent validation: It’s easy to let your implementation partner test the systems they’ve built, but relying on them as your sole quality gatekeeper can leave you with blind spots. To really protect your investment, ensure you have an independent team setting the acceptance criteria and running the tests. This ensures the system is actually delivering for your business, not just confirming the technical configuration.
• Analyse before building custom code: Before committing to a bespoke build, carry out rigorous analysis to see if your internal processes could adapt to fit the system’s out-of-the-box functionality instead. Every customisation adds a layer of maintenance and complexity you’ll have to manage later. It is almost always worth exploring whether a pre-built AppSource solution, a Power Automate flow, or a Fabric integration can do the heavy lifting without the ongoing overhead of custom code.
• Define your “blast radius”: Do you know exactly which 3-5 core business processes (e.g., paying suppliers) absolutely cannot fail during a bi-annual Microsoft update?
• Automate the core: Have you automated the regression testing for your most critical business flows to survive the evergreen update cycle without manual burnout?

Transformation is about evolving your business, not just changing your software. By taking ownership of your processes, minimising customisation, and implementing targeted, independent quality assurance, you can unlock the true power of Microsoft BC.

At Assurity, our independent Quality Assurance and testing services help organisations de-risk their Microsoft Dynamics 365 and BC implementations. We partner with you to ensure your enterprise cloud solutions deliver the business value you expect. Learn more about our Microsoft D365 capabilities.